summaryrefslogtreecommitdiff
path: root/src/fcntl
AgeCommit message (Collapse)AuthorFilesLines
2022-10-19remove LFS64 symbol aliases; replace with dynamic linker remappingRich Felker5-10/+0
originally the namespace-infringing "large file support" interfaces were included as part of glibc-ABI-compat, with the intent that they not be used for linking, since our off_t is and always has been unconditionally 64-bit and since we usually do not aim to support nonstandard interfaces when there is an equivalent standard interface. unfortunately, having the symbols present and available for linking caused configure scripts to detect them and attempt to use them without declarations, producing all the expected ill effects that entails. as a result, commit 2dd8d5e1b8ba1118ff1782e96545cb8a2318592c was made to prevent this, using macros to redirect the LFS64 names to the standard names, conditional on _GNU_SOURCE or _LARGEFILE64_SOURCE. however, this has turned out to be a source of further problems, especially since g++ defines _GNU_SOURCE by default. in particular, the presence of these names as macros breaks a lot of valid code. this commit removes all the LFS64 symbols and replaces them with a mechanism in the dynamic linker symbol lookup failure path to retry with the spurious "64" removed from the symbol name. in the future, if/when the rest of glibc-ABI-compat is moved out of libc, this can be removed.
2018-09-12remove spurious inclusion of libc.h for LFS64 ABI aliasesRich Felker5-10/+5
the LFS64 macro was not self-documenting and barely saved any characters. simply use weak_alias directly so that it's clear what's being done, and doesn't depend on a header to provide a strange macro.
2018-09-12reduce spurious inclusion of libc.hRich Felker1-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.
2016-07-01fix posix_fadvise syscall args on powerpc, unify with arm fixRich Felker2-12/+8
commit 6d38c9cf80f47623e5e48190046673bbd0dc410b provided an arm-specific version of posix_fadvise to address the alternate argument order the kernel expects on arm, but neglected to address that powerpc (32-bit) has the same issue. instead of having arch variant files in duplicate, simply put the alternate version in the top-level file under the control of a macro defined in syscall_arch.h.
2016-06-29fix misordered syscall arguments for posix_fadvise on armRich Felker1-0/+12
the arm version of the syscall has a custom argument ordering to avoid needing a 7-argument syscall due to 64-bit argument alignment.
2016-06-29in posix_fadvise, don't bypass __syscall macro infrastructureRich Felker1-1/+1
when commit 0b6eb2dfb2e84a8a51906e7634f3d5edc230b058 added the parentheses around __syscall to invoke the function directly, there was no __syscall7 in the syscall macro infrastructure, so this hack was needed. commit 9a3bbce447403d735282586786dc436ec1ffbad4 fixed that but failed to remove the hack.
2015-04-21remove dead case for F_SETLKW in fcntlRich Felker1-1/+0
the first switch already returns in the F_SETLKW code path so it need not be handled in the second switch. moreover the code in the second switch is wrong for the F_SETLKW command: it's not cancellable.
2014-10-31fix uninitialized mode variable in openat functionRich Felker1-1/+1
this was introduced in commit 2da3ab1382ca8e39eb1e4428103764a81fba73d3 as an oversight while making the variadic argument access conditional.
2014-10-30fix invalid access by openat to possibly-missing variadic mode argumentRich Felker1-4/+8
the mode argument is only required to be present when the O_CREAT or O_TMPFILE flag is used.
2014-10-30fix failure of open to read variadic mode argument for O_TMPFILERich Felker1-1/+1
2014-06-06avoid invalid use of va_arg in openRich Felker1-5/+8
reading the variadic mode argument is only valid when the O_CREAT flag is present. this probably does not matter, but is needed for formal correctness, and could affect LTO or other full-program analysis.
2014-06-06add O_CLOEXEC fallback for open and related functionsRich Felker1-1/+6
since there is no easy way to detect whether open honored or ignored the O_CLOEXEC flag, the optimal solution to providing a fallback is simply to make the fcntl syscall to set the close-on-exec flag immediately after open returns.
2014-05-24support kernels with no SYS_open syscall, only SYS_openatRich Felker1-1/+1
open is handled specially because it is used from so many places, in so many variants (2 or 3 arguments, setting errno or not, and cancellable or not). trying to do it as a function would not only increase bloat, but would also risk subtle breakage. this is the first step towards supporting "new" archs where linux lacks "old" syscalls.
2014-03-07in fcntl, use unsigned long instead of long for variadic argument typeRich Felker1-2/+2
neither is correct; different commands take different argument types, and some take no arguments at all. I have a much larger overhaul of fcntl prepared to address this, but it's not appropriate to commit during freeze. the immediate problem being addressed affects forward-compatibility on x32: if new commands are added and they take pointers, but the libc-level fcntl function is not aware of them, using long would sign-extend the pointer to 64 bits and give the kernel an invalid pointer. on the kernel side, the argument to fcntl is always treated as unsigned long, so no harm is done by treating possibly-signed integer arguments as unsigned. for every command that takes an integer argument except for F_SETOWN, large integer arguments and negative arguments are handled identically anyway. in the case of F_SETOWN, the kernel is responsible for converting the argument which it received as unsigned long to int, so the sign of negative arguments is recovered. the other problem that will be addressed later is that the type passed to va_arg does not match the type in the caller of fcntl. an advanced compiler doing cross-translation-unit analysis could potentially see this mismatch and issue warnings or otherwise make trouble. on i386, this patch was confirmed not to alter the code generated by gcc 4.7.3. in principle the generated code should not be affected on any arch except x32.
2014-01-08in fcntl, avoid passing pointer arguments to syscalls as longsRich Felker1-3/+12
really, fcntl should be changed to use the correct type corresponding to cmd when calling va_arg, and to carry the correct type through until making the syscall. however, this greatly increases binary size and does not seem to offer any benefits except formal correctness, so I'm holding off on that change for now. the minimal changes made in this patch are in preparation for addition of the x32 port, where the syscall macros need to know whether their arguments are pointers or integers in order to properly pass them to the 64-bit kernel.
2014-01-06add some missing LFS64 aliases for fadvise/fallocate functionsRich Felker2-0/+6
2013-12-12include cleanups: remove unused headers and add feature test macrosSzabolcs Nagy3-3/+0
2013-03-26provide emulation of fcntl F_DUPFD_CLOEXEC on old kernelsRich Felker1-0/+16
I'm not entirely happy with the amount of ugliness here, but since F_DUPFD_CLOEXEC is used elsewhere in code that's expected to work on old kernels (popen), it seems necessary. reportedly even some modern kernels went back and broke F_DUPFD_CLOEXEC (making it behave like plain F_DUPFD), so it might be necessary to add some additional fixup code later to deal with that issue too.
2012-09-08move fallocate syscall wrapper to linux-specific syscalls dirRich Felker1-9/+0
2012-09-08add fallocate (nonstandardized) functionRich Felker1-0/+9
this is equivalent to posix_fallocate except that it has an extra mode/flags argument to control its behavior, and stores the error in errno rather than returning an error code.
2012-09-08fix broken fallocate syscall in posix_fallocateRich Felker1-1/+1
the syscall takes an extra flag argument which should be zero to meet the POSIX requirements.
2012-06-20proper error handling for fcntl F_GETOWN on modern kernelsRich Felker1-1/+9
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.
2012-05-31enable LARGEFILE64 aliasesRich Felker1-2/+0
these will NOT be used when compiling with -D_LARGEFILE64_SOURCE on musl; instead, they exist in the hopes of eventually being able to run some glibc-linked apps with musl sitting in place of glibc. also remove the (apparently incorrect) fcntl alias.
2011-10-09fix F_GETOWN return value handlingRich Felker1-0/+1
the fcntl syscall can return a negative value when the command is F_GETOWN, and this is not an error code but an actual value. thus we must special-case it and avoid calling __syscall_ret to set errno. this fix is better than the glibc fix (using F_GETOWN_EX) which only works on newer kernels and is more complex.
2011-09-21update syscalls with off_t arguments to handle argument alignment, if neededRich Felker2-4/+4
the arm syscall abi requires 64-bit arguments to be aligned on an even register boundary. these new macros facilitate meeting the abi requirement without imposing significant ugliness on the code.
2011-04-20add syscall wrappers for posix_fadvise, posix_fallocateRich Felker2-0/+16
2011-04-17overhaul pthread cancellationRich Felker3-15/+4
this patch improves the correctness, simplicity, and size of cancellation-related code. modulo any small errors, it should now be completely conformant, safe, and resource-leak free. the notion of entering and exiting cancellation-point context has been completely eliminated and replaced with alternative syscall assembly code for cancellable syscalls. the assembly is responsible for setting up execution context information (stack pointer and address of the syscall instruction) which the cancellation signal handler can use to determine whether the interrupted code was in a cancellable state. these changes eliminate race conditions in the previous generation of cancellation handling code (whereby a cancellation request received just prior to the syscall would not be processed, leaving the syscall to block, potentially indefinitely), and remedy an issue where non-cancellable syscalls made from signal handlers became cancellable if the signal handler interrupted a cancellation point. x86_64 asm is untested and may need a second try to get it right.
2011-03-20global cleanup to use the new syscall interfaceRich Felker3-3/+3
2011-02-12initial check-in, version 0.5.0v0.5.0Rich Felker4-0/+73