Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | reduce spurious inclusion of libc.h | Rich Felker | 2018-09-12 | 1 | -1/+0 |
| | | | | | | | | | | | | | | | | | | | | | libc.h was intended to be a header for access to global libc state and related interfaces, but ended up included all over the place because it was the way to get the weak_alias macro. most of the inclusions removed here are places where weak_alias was needed. a few were recently introduced for hidden. some go all the way back to when libc.h defined CANCELPT_BEGIN and _END, and all (wrongly implemented) cancellation points had to include it. remaining spurious users are mostly callers of the LOCK/UNLOCK macros and files that use the LFS64 macro to define the awful *64 aliases. in a few places, new inclusion of libc.h is added because several internal headers no longer implicitly include libc.h. declarations for __lockfile and __unlockfile are moved from libc.h to stdio_impl.h so that the latter does not need libc.h. putting them in libc.h made no sense at all, since the macros in stdio_impl.h are needed to use them correctly anyway. | ||||
* | add fallback emulation for accept4 on old kernels | Rich Felker | 2014-02-21 | 1 | -1/+12 |
| | | | | | | | | | | | | the other atomic FD_CLOEXEC interfaces (dup3, pipe2, socket) already had such emulation in place. the justification for doing the emulation here is the same as for the other functions: it allows applications to simply use accept4 rather than having to have their own fallback code for ENOSYS/EINVAL (which one you get is arch-specific!) and there is no reasonable way an application could benefit from knowing the operation is emulated/non-atomic since there is no workaround at the application level for non-atomicity (that is the whole reason these interfaces were added). | ||||
* | move accept4, dup3, and pipe2 to non-linux-specific locations | Rich Felker | 2012-09-29 | 1 | -0/+9 |
these interfaces have been adopted by the Austin Group for inclusion in the next version of POSIX. |