based on patches by orc and Isaac Dunham, with some fixes. sys/io.h
exists and contains prototypes for these functions regardless of
whether the target arch has them; this is a bit unorthodox but I don't
think it will break anything. the function definitions do not exist
unless the appropriate SYS_* syscall number macro is defined, which
should make sure configure scripts looking for these functions don't
find them on other systems.
presently, sys/io.h does not have the inb/outb/etc. port io
macros/functions. I'd be surprised if ioperm/iopl are useful without
them, so they probably need to be added at some point in appropriate
bits/io.h files...
the kernel wrongly expects the cmsg length field to be size_t instead
of socklen_t. in order to work around the issue, we have to impose a
length limit and copy to a local buffer. the length limit should be
more than sufficient for any real-world use; these headers are only
used for passing file descriptors and permissions between processes
over unix sockets.
on arm, the location of the saved-signal-mask flag and mask were off
by one between sigsetjmp and siglongjmp, causing incorrect behavior
restoring the signal mask. this is because the siglongjmp code assumed
an extra slot was in the non-sig jmp_buf for the flag, but arm did not
have this. now, the extra slot is removed for all archs since it was
useless.
also, arm eabi requires jmp_buf to have 8-byte alignment. we achieve
that using long long as the type rather than with non-portable gcc
attribute tags.
the new version is largely the work of Solar Designer, with minor
changes for integration with musl. compared to the old code, text size
is reduced by about 7k, stack space usage by about 70k, and
performance is greatly improved by avoiding expensive calculation of
constant tables on each run.
this version also adds support for extended des-based password hashes,
which allow for unlimited key (password) length and configurable
iteration counts.
i've also published the interface for crypt_r in a new crypt.h header.
especially since this is not a standard interface, i did not feel
compelled to match the glibc abi for the crypt_data structure. the
glibc structure is way too big to allocate on the stack; in fact it's
so big that the first usage may cause the main thread to exceed its
pre-committed stack size of 128k and thus could cause the program to
crash even on systems with overcommit disabled. the only legitimate
use of crypt_data for crypt_r is to store the hash string to return,
so i've reserved 256 bytes, which should be more than sufficient
(longest known password hashes are ~60 characters, and beyond that is
possibly even exceeding some implementations' passwd file field size
limit).
on old kernels, there's no way to detect errors; we must assume
negative syscall return values are pgrp ids. but if the F_GETOWN_EX
fcntl works, we can get a reliable answer.
based on patch by Emil Renner Berthing, with minor changes to dirent.h
for LFS64 and organization of declarations
this code should work unmodified once a real strverscmp is added, but
I've been hesitant to add it because the GNU strverscmp behavior is
harmful in a lot of cases (for instance if you have numeric filenames
in hex). at some point I plan on trying to design a variant of the
algorithm that behaves better on a mix of filename styles.
this is ugly and stupid, but now that the *64 symbol names exist, a
lot of broken GNU software detects them in configure, then either
breaks during build due to missing off64_t definition, or attempts to
compile without function declarations/prototypes. "fixing" it here is
easier than telling everyone to add yet another feature test macro to
their builds.
i originally made it the same size as the bloated GNU version, which
contains space for saved signal mask, but this makes some structures
containing jmp_buf become much larger for no benefit. we will never
use the signal mask field with plain setjmp; sigsetjmp serves that
purpose.
i made a best attempt, but the intended semantics of this function are
fundamentally contradictory. there is no consistent way to handle
ownership of locks when forking a multi-threaded process. the code
could have worked by accident for programs that only used normal
mutexes and nothing else (since they don't actually store or care
about their owner), but that's about it. broken-by-design interfaces
that aren't even in glibc (only solaris) don't belong in musl.
there is no reason to avoid multiple identical macro definitions; this
is perfectly legal C, and even with the maximal warning options
enabled, gcc does not issue any warning for it.
we do not bother making h_errno thread-local since the only interfaces
that use it are inherently non-thread-safe. but still use the
potentially-thread-local ABI to access it just to avoid lock-in.
this one is for program(s|ers) who haven't heard of uint16_t and
uint32_t (which are obviously the correct types for use in such
situations, as they're the argument/return types for ntohs/htons and
ntohl/htonl).
Rich Felker
nsz