Openbsd cleanup #110
Merged
Openbsd cleanup #110
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- under openbsd and bitrig: dli_saddr member is *mut ::c_void - under netbsd: it is *const ::c_void
- IPV6_{ADD,DROP}_MEMBERSHIP
- HW_AVAILCPU
- same prototype on bitrig and openbsd - for netbsd, I did found it at all (?)
- sysctl: *mut -> *const - mprotect: *const -> *mut - remove sysctlbyname() that don't exists under openbsd
arguments `hostlen' and `servlen' are `socklen_t' or `size_t' depending the platform - apple: I don't known, so I don't change the original definition (socklen_t) - netbsd: socklen_t - freebsd: size_t - dragonfly: size_t - openbsd: size_t - bitrig: size_t
- openbsd - bitrig - netbsd
under openbsd it is a `caddr_t` which expand to `char *`. as the size of the type change, adjust the padding too.
- under openbsd/bitrig it is 256 - change type to `size_t` where system have `getnameinfo()` with `hostlen` as `size_t`
SYS_entropy is internal and may more easily change than getentropy(2).
semarie
force-pushed
the
openbsd-cleanup
branch
from
b456542
to
6b84742
Compare
| @@ -200,6 +213,9 @@ fn main() { | |||
| let target2 = target.clone(); | |||
| cfg.field_name(move |struct_, field| { | |||
| match field { | |||
| "d_namelen" if openbsd && struct_ == "dirent" => "d_namlen".to_string(), | |||
There was a problem hiding this comment.
Could this struct field be updated on openbsd to match the name in C? For renamings like this Rust shouldn't differ much
|
Thanks! I think it's fine to have some breakage here because this isn't a "tier 1 platform" of this library currently (e.g. there's no CI set up for it), but this is a great foundation to start from now! |
semarie
force-pushed
the
openbsd-cleanup
branch
from
b16d4c7
to
f441948
Compare
semarie
force-pushed
the
openbsd-cleanup
branch
from
f441948
to
6c8a63a
Compare
|
@alexcrichton I don't understand the failure for the previous one (6b84742) was ok, and adding 6c8a63a would make a linkage problem with |
|
Thanks @semarie! I'll work on getting this merged (mips failures are likely unrelated) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The following PR is the result of running
libc-testunder OpenBSD, and corrects all problems.I have keeped separated commits for reviewing.
Some commits touch BSD globally (
getnameinfofor example). In these cases, I have tried to review definitions in system code source.Please note that this version of libc will break openbsd target for rustc. There are three breaking change:
HW_AVAILCPU: it will breaknum_cpus()insidesrc/libtest/lib.rsNR_GETENTROPYconstant don't exist under this name (it isSYS_getentropy). But I also remove it and declare the functiongetentropy()which should be a more stable API. The current use is insidesrc/libstd/rand/os.rssiginfo_t.si_addrisn't compatible with the current definition ofsiginfo_si_addr()insrc/libstd/sys/unix/stack_overflow.rsFor all these problems, I have pending patches.