Age | Commit message (Collapse) | Author | Lines |
|
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.
|
|
|
|
some software apparently uses this and breaks with musl due to
mismatching definitions...
|
|
it's not even provided in the library at the moment, but could easily
be provided with weak aliases if desired.
|
|
|
|
long double and float bessel functions are no longer xsi extensions
|
|
|
|
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.
|
|
|
|
|
|
these are mostly untested and adapted directly from corresponding byte
string functions and similar.
|
|
|
|
these will also avoid obnoxious warnings with gcc -Wbraces.
|
|
apparently some broken stuff (libstdc++) needs this.
|
|
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.
|
|
this should be everything except for some functions where the non-_l
version isn't even implemented yet (mainly some non-ISO-C wcs*
functions).
|
|
|
|
|
|
these have not been heavily tested, but they should work as described
in the old standards. probably broken for non-finite values...
|
|
this type should never be used anyway, but some old junk uses it..
|
|
|
|
|
|
|
|
based on patch by Jeremy Huntwork
|
|
patch by Jeremy Huntwork
|
|
|
|
|
|
this is a nonstandard junk header anyway, so just do what apps expect..
|
|
based on patch by sh4rm4. these functions are deprecated; futimens and
utimensat should be used instead in new programs.
|
|
|
|
|
|
patch by Arvid Picciani (aep)
|
|
note that none of these are implemented, and programs depending on
them may break... patch by sh4rm4
|
|
patches by sh4rm4, presumably needed to make gdb or some similar junk
happy...
|
|
...and still be valid in #if directives.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|