based on Gregor's patch sent to the list. includes:
- stdalign.h
- removing gets in C11 mode
- adding aligned_alloc and adjusting other functions to use it
- adding 'x' flag to fopen for exclusive mode
with this patch, setting _POSIX_SOURCE, or setting _POSIX_C_SOURCE or
_XOPEN_SOURCE to an old version, will bring back the interfaces that
were removed in POSIX 2008 - at least the ones i've covered so far,
which are gethostby*, usleep, and ualarm. if there are other functions
still in widespread use that were removed for which similar changes
would be beneficial, they can be added just like this.
this function never existed historically; since the float/double
functions it's based on are nonstandard and deprecated, there's really
no justification for its existence except that glibc has it. it can be
added back if there's ever really a need...
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).
the non-prototype declaration of basename in string.h is an ugly
compromise to avoid breaking 2 types of broken software:
1. programs which assume basename is declared in string.h and thus
would suffer from dangerous pointer-truncation if an implicit
declaration were used.
2. programs which include string.h with _GNU_SOURCE defined but then
declare their own prototype for basename using the incorrect GNU
signature for the function (which would clash with a correct
prototype).
however, since C++ does not have non-prototype declarations and
interprets them as prototypes for a function with no arguments, we
must omit it when compiling C++ code. thankfully, all known broken
apps that suffer from the above issues are written in C, not C++.
this only works with gcc 4.6 and later, but it allows us to support
non-default endianness on archs like arm, mips, ppc, etc. that can do
both without having separate header sets for both variants, and it
saves one #include even on fixed-endianness archs like x86.
apparently some packages see stropts.h and want to be able to use
this. the implementation checks that the file descriptor is valid by
using fcntl/F_GETFD so it can report an error if not (as specified).
two issues: (1) the type was wrong (unsigned instead of signed int),
and (2) the value of FP_ILOGBNAN should be INT_MIN rather than INT_MAX
to match the ABI. this is also much more useful since INT_MAX
corresponds to a valid input (infinity). the standard would allow us
to set FP_ILOGB0 to -INT_MAX instead of INT_MIN, which would give us
distinct values for ilogb(0) and ilogb(NAN), but the benefit seems way
too small to justify ignoring the ABI.
note that the macro is just a "portable" (to any twos complement
system where signed and unsigned int have the same width) way to write
INT_MIN without needing limits.h. it's valid to use this method since
these macros are not required to work in #if directives.
musl does not support legacy 32-bit-off_t whatsoever. off_t is always
64 bit, and correct programs that use off_t and the standard functions
will just work out of the box. (on glibc, they would require
-D_FILE_OFFSET_BITS=64 to work.) however, some programs instead define
_LARGEFILE64_SOURCE and use alternate versions of all the standard
types and functions with "64" appended to their names.
we do not want code to actually get linked against these functions
(it's ugly and inconsistent), so macros are used instead of prototypes
with weak aliases in the library itself. eventually the weak aliases
may be added at the library level for the sake of using code that was
originally built against glibc, but the macros will still be the
desired solution in the headers.
these were at best of limited usefulness (for bootstrapping new
systems, mainly) and at worst caused real kernel headers to get
overwritten when upgrading libc.
in case they're needed by anyone, the exact same files are now
available in a new git repository:
git://git.etalabs.net/mini-lkh
this is a nonstandard function so it's not clear what conditions it
should satisfy. my intent is that it be fast and exact for positive
integral exponents when the result fits in the destination type, and
fast and correctly rounded for small negative integral exponents.
otherwise we aim for at most 1ulp error; it seems to differ from pow
by at most 1ulp and it's often 2-5 times faster than pow.
- add the rest of the junk traditionally in sys/param.h
- add prototypes for some nonstandard functions
- add _GNU_SOURCE to their source files so the compiler can check proto
fcntl values 1024 and up are universal, arch-independent. later I'll
add some of the other linux-specific ones for notify, leases, pipe
size, etc. here too.
this is legal since sa_* is in the reserved namespace for signal.h,
per posix. note that the sa_restorer field is not used anywhere, so
programs that are trying to use it may still break, but at least
they'll compile. if it turns out such programs actually need to be
able to set their own sa_restorer to function properly, i'll add the
necessary code to sigaction.c later.
gcc makes this mapping by default anyway, but it will be disabled by
-fno-builtin (and presumably by -std=c99 or similar). for the main
program the error will be reported by the linker, and the issue can
easily be fixed, but for dynamic-loaded so files, the error cannot be
detected until dlopen time, at which point it has become very obscure.
DECIMAL_DIG is not the same as LDBL_DIG
type_DIG is the maximimum number of decimal digits that can survive a
round trip from decimal to type and back to decimal.
DECIMAL_DIG is the minimum number of decimal digits required in order
for any floating point type to survive the round trip to decimal and
back, and it is generally larger than LDBL_DIG. since the exact
formula is non-trivial, and defining it larger than necessary may be
legal but wasteful, just define the right value in bits/float.h.
thanks to the hard work of Szabolcs Nagy (nsz), identifying the best
(from correctness and license standpoint) implementations from freebsd
and openbsd and cleaning them up! musl should now fully support c99
float and long double math functions, and has near-complete complex
math support. tgmath should also work (fully on gcc-compatible
compilers, and mostly on any c99 compiler).
based largely on commit 0376d44a890fea261506f1fc63833e7a686dca19 from
nsz's libm git repo, with some additions (dummy versions of a few
missing long double complex functions, etc.) by me.
various cleanups still need to be made, including re-adding (if
they're correct) some asm functions that were dropped.
the previous version not only failed to work in c++, but also failed
to produce constant expressions, making the macros useless as
initializers for objects of static storage duration.
gcc 3.3 and later have builtins for these, which sadly seem to be the
most "portable" solution. the alternative definitions produce
exceptions (for NAN) and compiler warnings (for INFINITY) on newer
versions of gcc.
GNU programs may expect the GNU version of basename, which has a
different prototype (argument is const-qualified) and prototype it
themselves too. of course if they're expecting the GNU behavior for
the function, they'll still run into problems, but at least this
eliminates some compile-time failures.
the old abi was intended to duplicate glibc's abi at the expense of
being ugly and slow, but it turns out glib was not even using that abi
except on non-gcc-compatible compilers (which it doesn't even support)
and was instead using an exceptions-in-c/unwind-based approach whose
abi we could not duplicate anyway without nasty dwarf2/unwind
integration.
the new abi is copied from a very old glibc abi, which seems to still
be supported/present in current glibc. it avoids all unwinding,
whether by sjlj or exceptions, and merely maintains a linked list of
cleanup functions to be called from the context of pthread_exit. i've
made some care to ensure that longjmp out of a cleanup function should
work, even though it is not required to.
this change breaks abi compatibility with programs which were using
pthread cancellation, which is unfortunate, but that's why i'm making
the change now rather than later. considering that most pthread
features have not been usable until recently anyway, i don't see it as
a major issue at this point.
note that it still will have the standards-conformant behavior, not
the GNU behavior. but at least this prevents broken code from ending
up with truncated pointers due to implicit declarations...
per 7.18.4: Each invocation of one of these macros shall expand to an
integer constant expression suitable for use in #if preprocessing
directives. The type of the expression shall have the same type as
would an expression of the corresponding type converted according to
the integer promotions. The value of the expression shall be that of
the argument.
the key phrase is "converted according to the integer promotions".
thus there is no intent or allowance that the expression have
smaller-than-int types.
issue reported by nsz, but it's actually not just pedantic. the
functions can take input of any arithmetic type, including floating
point, and the behavior needs to be as if the conversion implicit in
the function call took place.
the changes to syscall_ret are mostly no-ops in the generated code,
just cleanup of type issues and removal of some implementation-defined
behavior. the one exception is the change in the comparison value,
which is fixed so that 0xf...f000 (which in principle could be a valid
return value for mmap, although probably never in reality) is not
treated as an error return.
casting to int would not be correct because high bits could be lost.
mapping the high bits down onto low bits would be costlier in the
common case where the result is just used in a conditional. changing
the type of the bit array elements to int would permute the order of
the bit array on 64-bit big endian systems, so that's not an option
either.
this is a case of poorly written man pages not matching the actual
implementation, and why i hate implementing nonstandard interfaces
with no actual documentation of how they're intended to work.
this bug was introduced in a recent patch. the problem we're working
around is that broken GNU software wants to use "struct siginfo"
rather than "siginfo_t", but "siginfo" is not in the reserved
namespace and thus not legal for the standard header to use.
really wchar_t should never vary, but the ARM EABI defines it as an
unsigned 32-bit int instead of a signed one, and gcc follows this
nonsense. thus, to give a conformant environment, we have to follow
(otherwise L""[0] and L'\0' would be 0U rather than 0, but the
application would be unaware due to a mismatched definition for
WCHAR_MIN and WCHAR_MAX, and Bad Things could happen with respect to
signed/unsigned comparisons, promotions, etc.).
fortunately no rules are imposed by the C standard on the relationship
between wchar_t and wint_t, and WEOF has type wint_t, so we can still
make wint_t always-signed and use -1 for WEOF.
several things are changed. first, i have removed the old __uniclone
function signature and replaced it with the "standard" linux
__clone/clone signature. this was necessary to expose clone to
applications anyway, and it makes it easier to port __clone to new
archs, since it's now testable independently of pthread_create.
secondly, i have removed all references to the ugly ldt descriptor
structure (i386 only) from the c code and pthread structure. in places
where it is needed, it is now created on the stack just when it's
needed, in assembly code. thus, the i386 __clone function takes the
desired thread pointer as its argument, rather than an ldt descriptor
pointer, just like on all other sane archs. this should not affect
applications since there is really no way an application can use clone
with threads/tls in a way that doesn't horribly conflict with and
clobber the underlying implementation's use. applications are expected
to use clone only for creating actual processes, possibly with new
namespace features and whatnot.
actually these are just weak aliases for the normal locking versions
right now, and they will probably stay that way since making them
lock-free without slowing down the normal versions would require
significant code duplication for no benefit.
programs that use this tend to horribly botch international text
support, so it's questionable whether we want to support it even in
the long term... for now, it's just a dummy that calls strcmp.
not heavily tested, but it seems to be correct, including the odd
behavior that seeking is in terms of wide character count. this
precludes any simple buffering, so we just make the stream unbuffered.
this is a "nonstandard" function that was "rejected" by POSIX, but
nonetheless had its behavior documented in the POSIX rationale for
fork. it's present on solaris and possibly some other systems, and
duplicates the whole calling process, not just a single thread. glibc
does not have this function. it should not be used in programs
intending to be portable, but may be useful for testing,
checkpointing, etc. and it's an interesting (and quite small) example
of the usefulness of the __synccall framework originally written to
work around deficiencies in linux's setuid syscall.
STREAMS are utterly useless as far as I can tell, but some software
was apparently broken by the presence of stropts.h but lack of macros
it's supposed to define...
this is a really ugly and backwards function, but its presence will
prevent lots of broken gnulib software from trying to define its own
version of fpurge and thereby failing to build or worse.
basically there are 3 choices for how to implement this variable-size
string member:
1. C99 flexible array member: breaks using dirent.h with pre-C99 compiler.
2. old way: length-1 string: generates array bounds warnings in caller.
3. new way: length-NAME_MAX string. no problems, simplifies all code.
of course the usable part in the pointer returned by readdir might be
shorter than NAME_MAX+1 bytes, but that is allowed by the standard and
doesn't hurt anything.
there is a resource limit of 0 bits to store the concurrency level
requested. thus any positive level exceeds a resource limit, resulting
in EAGAIN. :-)
