musl/src/linux, branch v0.9.15 musl - an implementation of the standard library for Linux-based systems fanotify.c: fix typo in header inclusion 2014-01-03T10:29:57+00:00 rofl0r retnyg@gmx.net 2014-01-03T10:27:46+00:00 9e91398b282f3ca3541da71c51adb9958f3e9cc2 the header is included only as a guard to check that the declaration and definition match, so the typo didn't cause any breakage aside from omitting this check. 
the header is included only as a guard to check that the declaration
and definition match, so the typo didn't cause any breakage aside
from omitting this check.
disable the brk function 2014-01-02T22:13:19+00:00 Rich Felker dalias@aerifal.cx 2014-01-02T22:13:19+00:00 863d628d93ea341b6a32661a1654320ce69f6a07 the reasons are the same as for sbrk. unlike sbrk, there is no safe usage because brk does not return any useful information, so it should just fail unconditionally. 
the reasons are the same as for sbrk. unlike sbrk, there is no safe
usage because brk does not return any useful information, so it should
just fail unconditionally.
disable sbrk for all values of increment except 0 2014-01-02T22:03:34+00:00 Rich Felker dalias@aerifal.cx 2014-01-02T22:03:34+00:00 7a995fe706e519a4f55399776ef0df9596101f93 use of sbrk is never safe; it conflicts with malloc, and malloc may be used internally by the implementation basically anywhere. prior to this change, applications attempting to use sbrk to do their own heap management simply caused untrackable memory corruption; now, they will fail with ENOMEM allowing the errors to be fixed. sbrk(0) is still permitted as a way to get the current brk; some misguided applications use this as a measurement of their memory usage or for other related purposes, and such usage is harmless. eventually sbrk may be re-added if/when malloc is changed to avoid using the brk by using mmap for all allocations. 
use of sbrk is never safe; it conflicts with malloc, and malloc may be
used internally by the implementation basically anywhere. prior to
this change, applications attempting to use sbrk to do their own heap
management simply caused untrackable memory corruption; now, they will
fail with ENOMEM allowing the errors to be fixed.

sbrk(0) is still permitted as a way to get the current brk; some
misguided applications use this as a measurement of their memory
usage or for other related purposes, and such usage is harmless.

eventually sbrk may be re-added if/when malloc is changed to avoid
using the brk by using mmap for all allocations.
add fanotify syscall wrapper and header 2014-01-02T21:10:45+00:00 rofl0r retnyg@gmx.net 2014-01-02T21:10:45+00:00 5c81b8fe453994a74afa7cd355dd707ee2d01a24 






add sys/quota.h and quotactl syscall wrapper
2013-12-20T16:52:10+00:00

Rich Felker
dalias@aerifal.cx

2013-12-20T16:52:10+00:00

e36d8a1d74a00e56990728508635296440ddce1c

based on patch by Timo Teräs.





based on patch by Timo Teräs.







include cleanups: remove unused headers and add feature test macros
2013-12-12T05:09:18+00:00

Szabolcs Nagy
nsz@port70.net

2013-12-12T05:09:18+00:00

571744447c23f91feb6439948f3a619aca850dfb












fix the prototype of settimeofday to follow the original BSD declaration
2013-05-26T16:01:38+00:00

Szabolcs Nagy
nsz@port70.net

2013-05-26T16:01:38+00:00

31ff797787d89bc01a69ca672fb2340ff21a827e












fix signalfd not to ignore flags
2013-04-08T03:19:00+00:00

Rich Felker
dalias@aerifal.cx

2013-04-08T03:19:00+00:00

bcd9302508e5b89cfdcf2a2acebdf05d88d7479e

also include fallback code for broken kernels that don't support the
flags. as usual, the fallback has a race condition that can leak file
descriptors.





also include fallback code for broken kernels that don't support the
flags. as usual, the fallback has a race condition that can leak file
descriptors.







remove __SYSCALL_SSLEN arch macro in favor of using public _NSIG
2013-03-27T03:07:31+00:00

Rich Felker
dalias@aerifal.cx

2013-03-27T03:07:31+00:00

ccc7b4c3a17ade90de71e1e0f44deebbffd646e6

the issue at hand is that many syscalls require as an argument the
kernel-ABI size of sigset_t, intended to allow the kernel to switch to
a larger sigset_t in the future. previously, each arch was defining
this size in syscall_arch.h, which was redundant with the definition
of _NSIG in bits/signal.h. as it's used in some not-quite-portable
application code as well, _NSIG is much more likely to be recognized
and understood immediately by someone reading the code, and it's also
shorter and less cluttered.

note that _NSIG is actually 65/129, not 64/128, but the division takes
care of throwing away the off-by-one part.





the issue at hand is that many syscalls require as an argument the
kernel-ABI size of sigset_t, intended to allow the kernel to switch to
a larger sigset_t in the future. previously, each arch was defining
this size in syscall_arch.h, which was redundant with the definition
of _NSIG in bits/signal.h. as it's used in some not-quite-portable
application code as well, _NSIG is much more likely to be recognized
and understood immediately by someone reading the code, and it's also
shorter and less cluttered.

note that _NSIG is actually 65/129, not 64/128, but the division takes
care of throwing away the off-by-one part.







remove __arch_prctl alias for arch_prctl
2012-12-07T21:22:13+00:00

Rich Felker
dalias@aerifal.cx

2012-12-07T21:22:13+00:00

3ee67505fe50299d6df6e9bca894fd6b568669fb

if there's evidence of any use for it, we can add it back later. as
far as I can tell, glibc has it only for internal use (and musl uses a
direct syscall in that case rather than a function call), not for
exposing it to applications.





if there's evidence of any use for it, we can add it back later. as
far as I can tell, glibc has it only for internal use (and musl uses a
direct syscall in that case rather than a function call), not for
exposing it to applications.