Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

posix definitions should be used on Solaris #522

Closed
binarycrusader opened this issue Feb 16, 2017 · 2 comments
Closed

posix definitions should be used on Solaris #522

binarycrusader opened this issue Feb 16, 2017 · 2 comments

Comments

@binarycrusader
Copy link
Contributor

For compatibility reasons, Solaris historically had its header files setup so that, unless specifically requested through specific header defines, either the old pre-POSIX interfaces or POSIX.1c Draft 6 interfaces were used. However, in the case of rust, since these symbols are linked directly instead of via system header files, the underlying posix symbol name can be used directly instead.

Therefore, in the case of readdir_r and sigwait, rust should explicitly link to __posix_readdir_r and __posix_sigwait respectively.

Secondly, the definitions of getpwnam_r and getpwuid_r are also based on the historical interfaces provided for backwards compatibility by Solaris instead of the POSIX interfaces. There is no reason to use these historical interfaces and in fact, the respective man pages heavily discourage such use.

These definitions should be corrected to match what they do on almost every other platform.

Changing these definitions as proposed is compatible with both commercial releases of Solaris and older opensource-based derivatives.

I will provide a pull request shortly. Be aware this is a breaking change in terms of interface for any crates / consumers of these interfaces for Solaris.

@binarycrusader
Copy link
Contributor Author

I will also file an issue for the changes to libstd and provide the appropriate pull request.

@binarycrusader
Copy link
Contributor Author

As an example, these symbols are documented both here for Oracle Solaris:

https://docs.oracle.com/cd/E53394_01/html/E54772/libc-3lib.html

...and here for Illumos:

https://illumos.org/man/3lib/libc

binarycrusader added a commit to binarycrusader/libc that referenced this issue Feb 16, 2017
For compatibility reasons, Solaris historically had its header files
setup so that, unless specifically requested through specific header
defines, either the old pre-POSIX interfaces or POSIX.1c Draft 6
interfaces were used. However, in the case of rust, since these symbols
are linked directly instead of via system header files, the underlying
posix symbol name can be used directly instead.

These definitions should be corrected to match what they do on almost
every other platform.

Be aware this is a breaking change in terms of interface for any crates
/ consumers of these interfaces for Solaris.

Fixes rust-lang#522
bors added a commit that referenced this issue Feb 16, 2017
posix definitions should be used on Solaris

For compatibility reasons, Solaris historically had its header files
setup so that, unless specifically requested through specific header
defines, either the old pre-POSIX interfaces or POSIX.1c Draft 6
interfaces were used. However, in the case of rust, since these symbols
are linked directly instead of via system header files, the underlying
posix symbol name can be used directly instead.

These definitions should be corrected to match what they do on almost
every other platform.

Be aware this is a breaking change in terms of interface for any crates
/ consumers of these interfaces for Solaris.

Fixes #522
@bors bors closed this as completed in #523 Feb 16, 2017
Susurrus pushed a commit to Susurrus/libc that referenced this issue Mar 26, 2017
Specify Rust minimum version requirements

I think this is important for 2 reasons:

1) Users know if they can use this library
2) Developers know what Rust features they can use in merge requests

What this doesn't do is establish any kind of policy for raising the Rust requirements, which is something  worth addressing in the near-future.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant