| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
internally, other parts of the library assume sizes don't overflow
ssize_t and/or ptrdiff_t, and the way this assumption is made valid is
by preventing creating of such large objects. malloc already does so,
but the check was missing from mmap.
this is also a quality of implementation issue: even if the
implementation internally could handle such objects, applications
could inadvertently invoke undefined behavior by subtracting pointers
within an object. it is very difficult to guard against this in
applications, so a good implementation should simply ensure that it
does not happen.
|
| |
|
|
|
| |
the address of the pointer to the sched param, rather than the
pointer, was being passed to the kernel.
|
| | |
|
| | |
|
| |
|
|
|
| |
fstat should not fail under normal circumstances, so this fix is
mostly theoretical.
|
| |
|
|
|
| |
the address of the pointer, rather than the pointer, was being passed.
this was probably a copy-and-paste error from corresponding get code.
|
| | |
|
| |
|
|
|
| |
this seems to have been a simple copy-and-paste error from the code
for converting from legacy codepages.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
previously, the path string was being used despite being invalid. with
this change, empty path file or error reading the path file is treated
as an empty path. this is preferable to falling back to a default
path, so that attacks to prevent reading of the path file could not
result in loading incorrect and possibly dangerous (outdated or
mismatching ABI) libraries from.
the code to strip the final newline has also been removed; now that
newline is accepted as a delimiter, it's harmless to leave it in
place.
|
| |
|
|
|
|
|
| |
apparently the original commit was never tested properly, since
getline was only ever reading one line. the intent was to read the
entire file, so use getdelim with the null byte as delimiter as a
cheap way to read a whole file into memory.
|
| |
|
|
|
|
|
|
|
| |
also move all legacy inet_* functions into a single file to avoid
wasting object file and compile time overhead on them.
the added functions are legacy interfaces for working with classful
ipv4 network addresses. they have no modern usefulness whatsoever, but
some programs unconditionally use them anyway, and they're tiny.
|
| |
|
|
|
|
|
| |
based on patch by Strake with minor stylistic changes, and combined
into a single file. this patch remained open for a long time due to
some question as to whether ether_aton would be better implemented in
terms of sscanf, and it's time something was committed, so here it is.
|
| |
|
|
|
| |
this seems to have been a regression from the refactoring which added
the 'm' modifier.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the shgetc api, used internally in scanf and int/float scanning code
to handle field width limiting and pushback, was designed assuming
that pushback could be achieved via a simple decrement on the file
buffer pointer. this only worked by chance for regular FILE streams,
due to the linux readv bug workaround in __stdio_read which moves the
last requested byte through the buffer rather than directly back to
the caller. for unbuffered streams and streams not using __stdio_read
but some other underlying read function, the first character read
could be completely lost, and replaced by whatever junk happened to be
in the unget buffer.
to fix this, simply have shgetc, when it performs an underlying read
operation on the stream, store the character read at the -1 offset
from the read buffer pointer. this is valid even for unbuffered
streams, as they have an unget buffer located just below the start of
the zero-length buffer. the check to avoid storing the character when
it is already there is to handle the possibility of read-only buffers.
no application-exposed FILE types are allowed to use read-only
buffers, but sscanf and strto* may use them internally when calling
functions which use the shgetc api.
|
| |
|
|
|
|
|
| |
issue found and patch provided by Jens Gustedt. after the atomic store
to the error code field of the aiocb, the application is permitted to
free or reuse the storage, so further access is invalid. instead, use
the local copy that was already made.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
due to the interface requirement of having the full state contained in
a single object of type unsigned int, it is difficult to provide a
reasonable-quality implementation; most good PRNGs are immediately
ruled out because they need larger state. the old rand_r gave very
poor output (very short period) in its lower bits; normally, it's
desirable to throw away the low bits (as in rand()) when using a LCG,
but this is not possible since the state is only 32 bits and we need
31 bits of output.
glibc's rand_r uses the same LCG as musl's, but runs it for 3
iterations and only takes 10-11 bits from each iteration to construct
the output value. this partially fixes the period issue, but
introduces bias: not all outputs have the same frequency, and many do
not appear at all. with such a low period, the bias is likely to be
observable.
I tried many approaches to "fix" rand_r, and the simplest I found
which made it pass the "dieharder" tests was applying this
transformation to the output. the "temper" function is taken from
mersenne twister, where it seems to have been chosen for some rigorous
properties; here, the only formal property I'm using is that it's
one-to-one and thus avoids introducing bias.
should further deficiencies in rand_r be reported, the obvious "best"
solution is applying a 32-bit cryptographic block cipher in CTR mode.
I identified several possible ciphers that could be used directly or
adapted, but as they would be a lot slower and larger, I do not see a
justification for using them unless the current rand_r proves
deficient for some real-world use.
|
| |
|
|
|
|
|
| |
apparently these features have been in Linux for a while now, so it
makes sense to support them. the bit twiddling seems utterly illogical
and wasteful, especially the negation, but that's how the kernel folks
chose to encode pids/tids into the clock id.
|
| |
|
|
|
| |
this is a minor fix to increase the period of the obsolete rand_r a bit.
an include header in __rand48_step.c is fixed as well.
|
| |
|
|
|
|
|
| |
some applications rely on the low bits of rand() to be reasonably good
quality prng, so now it fixed by using the top bits of a 64 bit LCG,
this is simple, has small state and passes statistical tests.
D.E. Knuth attributes the multiplier to C.E. Haynes in TAOCP Vol2 3.3.4
|
| | |
|
| |
|
|
|
| |
this commit only covers the byte-based scanf-family functions. the
wide functions still lack support for the 'm' modifier.
|
| |
|
|
|
|
| |
this brings the wide version of the code into alignment with the
byte-based version, in preparation for adding support for the m
(malloc) modifier.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
the concept here is that %s and %c are essentially special-cases of
%[, with some minimal additional special-casing.
aside from simplifying the code and reducing the number of complex
code-paths that would need changing to make optimizations later, the
main purpose of this change is to simplify addition of the 'm'
modifier which causes scanf to allocate storage for the string being
read.
|
| | |
|
| |\ |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
per Austin Group interpretation for issue #686, which cites the
requirements of ISO C, clock() cannot wrap. if the result is not
representable, it must return (clock_t)-1. in addition, the old code
was performing wrapping via signed overflow and thus invoking
undefined behavior.
since it seems impossible to accurately check for overflow with the
old times()-based fallback code, I have simply dropped the fallback
code for now, thus always returning -1 on ancient systems. if there's
a demand for making it work and somebody comes up with a way, it could
be reinstated, but the clock() function is essentially useless on
32-bit system anyway (it overflows in less than an hour).
it should be noted that I used LONG_MAX rather than ULONG_MAX, despite
32-bit archs using an unsigned type for clock_t. this discrepency with
the glibc/LSB type definitions will be fixed now; since wrapping of
clock_t is no longer supported, there's no use in it being unsigned.
|
| |
|
|
|
|
|
|
|
| |
The underflow exception is not raised correctly in some
cornercases (see previous fma commit), added comments
with examples for fmaf, fmal and non-x86 fma.
In fmaf store the result before returning so it has the
correct precision when FLT_EVAL_METHOD!=0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) in downward rounding fma(1,1,-1) should be -0 but it was 0 with
gcc, the code was correct but gcc does not support FENV_ACCESS ON
so it used common subexpression elimination where it shouldn't have.
now volatile memory access is used as a barrier after fesetround.
2) in directed rounding modes there is no double rounding issue
so the complicated adjustments done for nearest rounding mode are
not needed. the only exception to this rule is raising the underflow
flag: assume "small" is an exactly representible subnormal value in
double precision and "verysmall" is a much smaller value so that
(long double)(small plus verysmall) == small
then
(double)(small plus verysmall)
raises underflow because the result is an inexact subnormal, but
(double)(long double)(small plus verysmall)
does not because small is not a subnormal in long double precision
and it is exact in double precision.
now this problem is fixed by checking inexact using fenv when the
result is subnormal
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
* use unsigned arithmetics
* use unsigned to store arg reduction quotient (so n&3 is understood)
* remove z=0.0 variables, use literal 0
* raise underflow and inexact exceptions properly when x is small
* fix spurious underflow in tanl
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* use unsigned arithmetics on the representation
* store arg reduction quotient in unsigned (so n%2 would work like n&1)
* use different convention to pass the arg reduction bit to __tan
(this argument used to be 1 for even and -1 for odd reduction
which meant obscure bithacks, the new n&1 is cleaner)
* raise inexact and underflow flags correctly for small x
(tanl(x) may still raise spurious underflow for small but normal x)
(this exception raising code increases codesize a bit, similar fixes
are needed in many other places, it may worth investigating at some
point if the inexact and underflow flags are worth raising correctly
as this is not strictly required by the standard)
* tanf manual reduction optimization is kept for now
* tanl code path is cleaned up to follow similar logic to tan and tanf
|
| |/
|
|
|
|
|
| |
patch by Strake. previously is was not feasible to duplicate this
functionality of the functions these were modeled on, since argv[0]
was not saved at program startup, but now that it's available it's
easy to use.
|
| |
|
|
|
|
|
|
| |
support for these was recently added to sysmacros.h. note that the
syscall argument is a long, despite dev_t being 64-bit, so on 32-bit
archs the high bits will be lost. it appears the high bits are just
glibc silliness and not part of the kernel api, anyway, but it's nice
that we have them there for future expansion if needed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When FLT_EVAL_METHOD!=0 (only i386 with x87 fp) the excess
precision of an expression must be removed in an assignment.
(gcc needs -fexcess-precision=standard or -std=c99 for this)
This is done by extra load/store instructions which adds code
bloat when lot of temporaries are used and it makes the result
less precise in many cases.
Using double_t and float_t avoids these issues on i386 and
it makes no difference on other archs.
For now only a few functions are modified where the excess
precision is clearly beneficial (mostly polynomial evaluations
with temporaries).
object size differences on i386, gcc-4.8:
old new
__cosdf.o 123 95
__cos.o 199 169
__sindf.o 131 95
__sin.o 225 203
__tandf.o 207 151
__tan.o 605 499
erff.o 1470 1416
erf.o 1703 1649
j0f.o 1779 1745
j0.o 2308 2274
j1f.o 1602 1568
j1.o 2286 2252
tgamma.o 1431 1424
math/*.o 64164 63635
|
| |
|
|
|
|
|
| |
since CLOCKS_PER_SEC is 1000000 (required by XSI) and the times
syscall reports values in 1/100 second units (Linux), the correct
scaling factor is 10000, not 100. note that only ancient kernels which
lack clock_gettime are affected.
|
| |
|
|
|
|
|
|
| |
all return values are valid, and on 32-bit systems, values that look
like errors can and will occur. since the only actual error this
function could return is EFAULT, and it is only returnable when the
application has invoked undefined behavior, simply ignore the
possibility that the return value is actually an error code.
|
| |
|
|
|
|
|
|
|
|
| |
there are several reasons for this change. one is getting rid of the
repetition of the syscall signature all over the place. another is
sharing the constant masks without costly GOT accesses in PIC.
the main motivation, however, is accurately representing whether we
want to block signals that might be handled by the application, or all
signals.
|
| |
|
|
|
| |
use __syscall rather than syscall when failure is not possible or not
to be considered.
|
| | |
|
| |
|
|
|
|
| |
they have already blocked signals before decrementing the thread
count, so the code being removed is unreachable in the case where the
thread is no longer counted.
|
| |
|
|
| |
this was simply a case of saving the state in the wrong place.
|
| |
|
|
|
| |
the previous few commits ended up leaving the thread count and signal
mask wrong for atexit handlers and stdio cleanup.
|
| |
|
|
|
|
| |
now that blocking signals prevents any application code from running
while the last thread is exiting, the cas logic is no longer needed to
prevent decrementing below zero.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the thread count (1+libc.threads_minus_1) must always be greater than
or equal to the number of threads which could have application code
running, even in an async-signal-safe sense. there is at least one
dangerous race condition if this invariant fails to hold: dlopen could
allocate too little TLS for existing threads, and a signal handler
running in the exiting thread could claim the allocated TLS for itself
(via __tls_get_addr), leaving too little for the other threads it was
allocated for and thereby causing out-of-bounds access.
there may be other situations where it's dangerous for the thread
count to be too low, particularly in the case where only one thread
should be left, in which case locking may be omitted. however, all
such code paths seem to arise from undefined behavior, since
async-signal-unsafe functions are not permitted to be called from a
signal handler that interrupts pthread_exit (which is itself
async-signal-unsafe).
this change may also simplify logic in __synccall and improve the
chances of making __synccall async-signal-safe.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for the duration of the vm-sharing clone used by posix_spawn, all
signals are blocked in the parent process, including
implementation-internal signals. since __synccall cannot do anything
until successfully signaling all threads, the fact that signals are
blocked automatically yields the necessary safety.
aside from debloating and general simplification, part of the
motivation for removing the explicit lock is to simplify the
synchronization logic of __synccall in hopes that it can be made
async-signal-safe, which is needed to make setuid and setgid, which
depend on __synccall, conform to the standard. whether this will be
possible remains to be seen.
|
