musl/src/stdio/fopen.c, branch master musl - an implementation of the standard library for Linux-based systems remove LFS64 symbol aliases; replace with dynamic linker remapping 2022年10月19日T18:01:31+00:00 Rich Felker dalias@aerifal.cx 2022年09月26日T21:14:18+00:00 246f1c811448f37a44b41cd8df8d0ef9736d95f4 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.
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.
remove spurious inclusion of libc.h for LFS64 ABI aliases 2018年09月12日T18:34:38+00:00 Rich Felker dalias@aerifal.cx 2018年09月12日T04:28:34+00:00 63a4c9adf227a6f6a5f7f70f6dc3f8863f846927 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.
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.
reduce spurious inclusion of libc.h 2018年09月12日T18:34:37+00:00 Rich Felker dalias@aerifal.cx 2018年09月12日T04:08:09+00:00 5ce3737931bb411a8d167356d4d0287b53b0cbdc 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.
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.
remove cancellation points in stdio 2015年06月13日T20:53:02+00:00 Rich Felker dalias@aerifal.cx 2015年06月13日T20:53:02+00:00 4ef9b828c1f39553a69e0635ac91f0fcadd6e8c6 commit 58165923890865a6ac042fafce13f440ee986fd9 added these optional cancellation points on the basis that cancellable stdio could be useful, to unblock threads stuck on stdio operations that will never complete. however, the only way to ensure that cancellation can achieve this is to violate the rules for side effects when cancellation is acted upon, discarding knowledge of any partial data transfer already completed. our implementation exhibited this behavior and was thus non-conforming. in addition to improving correctness, removing these cancellation points moderately reduces code size, and should significantly improve performance on i386, where sysenter/syscall instructions can be used instead of "int 128ドル" for non-cancellable syscalls.
commit 58165923890865a6ac042fafce13f440ee986fd9 added these optional
cancellation points on the basis that cancellable stdio could be
useful, to unblock threads stuck on stdio operations that will never
complete. however, the only way to ensure that cancellation can
achieve this is to violate the rules for side effects when
cancellation is acted upon, discarding knowledge of any partial data
transfer already completed. our implementation exhibited this behavior
and was thus non-conforming.
in addition to improving correctness, removing these cancellation
points moderately reduces code size, and should significantly improve
performance on i386, where sysenter/syscall instructions can be used
instead of "int 128ドル" for non-cancellable syscalls.
add O_CLOEXEC fallback for open and related functions 2014年06月06日T19:42:42+00:00 Rich Felker dalias@aerifal.cx 2014年06月06日T19:42:42+00:00 7765706c0584ed4a30e0b7a3ada742e490ef02b0 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.
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.
support kernels with no SYS_open syscall, only SYS_openat 2014年05月25日T02:54:05+00:00 Rich Felker dalias@aerifal.cx 2014年05月25日T02:54:05+00:00 594c827a22124ae550b9a877b8188e0898dff8db 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.
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.
clean up stdio_impl.h 2012年11月08日T21:39:41+00:00 Rich Felker dalias@aerifal.cx 2012年11月08日T21:39:41+00:00 835f9f950e2f6059532bd9ab9857a856ed21a4fd this header evolved to facilitate the extremely lazy practice of omitting explicit includes of the necessary headers in individual stdio source files; not only was this sloppy, but it also increased build time. now, stdio_impl.h is only including the headers it needs for its own use; any further headers needed by source files are included directly where needed.
this header evolved to facilitate the extremely lazy practice of
omitting explicit includes of the necessary headers in individual
stdio source files; not only was this sloppy, but it also increased
build time.
now, stdio_impl.h is only including the headers it needs for its own
use; any further headers needed by source files are included directly
where needed.
greatly improve freopen behavior 2012年10月25日T01:16:06+00:00 Rich Felker dalias@aerifal.cx 2012年10月25日T01:16:06+00:00 892cafff665b44d238e3b664f61ca38dd965cba6 1. don't open /dev/null just as a basis to copy flags; use shared __fmodeflags function to get the right file flags for the mode. 2. handle the case (probably invalid, but whatever) case where the original stream's file descriptor was closed; previously, the logic re-closed it. 3. accept the "e" mode flag for close-on-exec; update dup3 to fallback to using dup2 so we can simply call __dup3 instead of putting fallback logic in freopen itself.
1. don't open /dev/null just as a basis to copy flags; use shared
__fmodeflags function to get the right file flags for the mode.
2. handle the case (probably invalid, but whatever) case where the
original stream's file descriptor was closed; previously, the logic
re-closed it.
3. accept the "e" mode flag for close-on-exec; update dup3 to fallback
to using dup2 so we can simply call __dup3 instead of putting fallback
logic in freopen itself.
add 'e' modifier (close-on-exec) to fopen and fdopen 2012年09月29日T22:09:34+00:00 Rich Felker dalias@aerifal.cx 2012年09月29日T22:09:34+00:00 8582a6e9f25dd7b87d72961f58008052a4cac473 this feature will be in the next version of POSIX, and can be used internally immediately. there are many internal uses of fopen where close-on-exec is needed to fix bugs.
this feature will be in the next version of POSIX, and can be used
internally immediately. there are many internal uses of fopen where
close-on-exec is needed to fix bugs.
use restrict everywhere it's required by c99 and/or posix 2008 2012年09月07日T02:44:55+00:00 Rich Felker dalias@aerifal.cx 2012年09月07日T02:44:55+00:00 400c5e5c8307a2ebe44ef1f203f5a15669f20347 to deal with the fact that the public headers may be used with pre-c99 compilers, __restrict is used in place of restrict, and defined appropriately for any supported compiler. we also avoid the form [restrict] since older versions of gcc rejected it due to a bug in the original c99 standard, and instead use the form *restrict.
to deal with the fact that the public headers may be used with pre-c99
compilers, __restrict is used in place of restrict, and defined
appropriately for any supported compiler. we also avoid the form
[restrict] since older versions of gcc rejected it due to a bug in the
original c99 standard, and instead use the form *restrict.

AltStyle によって変換されたページ (->オリジナル) /