musl/src/process/system.c, branch master musl - an implementation of the standard library for Linux-based systems 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.
fix return value of system on failure to spawn child process 2018年08月29日T00:39:26+00:00 Rich Felker dalias@aerifal.cx 2018年08月29日T00:39:26+00:00 1d297a2821f8c5c5bc13b0bad88c966603ef46dc the value 0x7f00 (as if by _exit(127)) is specified only for the case where the child is created but then fails to exec the shell, since traditional fork+exec implementations do not admit reporting an error via errno in this case without additional machinery. it's unclear whether an implementation not subject to this failure mode needs to emulate it; one could read the standard as requiring that. if so, additional code will need to be added to map posix_spawn errors into the form system is expected to return. but for now, returning -1 to indicate an error is significantly better behavior than always reporting failures as if the shell failed to exec after fork.
the value 0x7f00 (as if by _exit(127)) is specified only for the case
where the child is created but then fails to exec the shell, since
traditional fork+exec implementations do not admit reporting an error
via errno in this case without additional machinery. it's unclear
whether an implementation not subject to this failure mode needs to
emulate it; one could read the standard as requiring that. if so,
additional code will need to be added to map posix_spawn errors into
the form system is expected to return. but for now, returning -1 to
indicate an error is significantly better behavior than always
reporting failures as if the shell failed to exec after fork.
include cleanups: remove unused headers and add feature test macros 2013年12月12日T05:09:18+00:00 Szabolcs Nagy nsz@port70.net 2013年12月12日T05:09:18+00:00 571744447c23f91feb6439948f3a619aca850dfb
remove cruft from pre-posix_spawn version of the system function 2013年03月25日T02:40:54+00:00 Rich Felker dalias@aerifal.cx 2013年03月25日T02:40:54+00:00 7914ce9204e907ae770fcbe59975010520fcac58
consistently use the internal name __environ for environ 2013年02月17日T19:24:39+00:00 Rich Felker dalias@aerifal.cx 2013年02月17日T19:24:39+00:00 23ccb80fcb325bd89e40508a57ff4ccedea6926d patch by Jens Gustedt. previously, the intended policy was to use __environ in code that must conform to the ISO C namespace requirements, and environ elsewhere. this policy was not followed in practice anyway, making things confusing. on top of that, Jens reported that certain combinations of link-time optimization options were breaking with the inconsistent references; this seems to be a compiler or linker bug, but having it go away is a nice side effect of the changes made here.
patch by Jens Gustedt.
previously, the intended policy was to use __environ in code that must
conform to the ISO C namespace requirements, and environ elsewhere.
this policy was not followed in practice anyway, making things
confusing. on top of that, Jens reported that certain combinations of
link-time optimization options were breaking with the inconsistent
references; this seems to be a compiler or linker bug, but having it
go away is a nice side effect of the changes made here.
base system() on posix_spawn 2013年02月03日T23:21:04+00:00 Rich Felker dalias@aerifal.cx 2013年02月03日T23:21:04+00:00 a8799356d560d3b02a19a4bda4a638a4a9a80856 this avoids duplicating the fragile logic for executing an external program without fork.
this avoids duplicating the fragile logic for executing an external
program without fork.
system is a cancellation point 2012年10月29日T01:17:45+00:00 Rich Felker dalias@aerifal.cx 2012年10月29日T01:17:45+00:00 76f28cfce59dfc499252c874f87c34567e6c86c6 ideally, system would also be cancellable while running the external command, but I cannot find any way to make that work without either leaking zombie processes or introducing behavior that is far outside what the standard specifies. glibc handles cancellation by killing the child process with SIGKILL, but this could be unsafe in that it could leave the data being manipulated by the command in an inconsistent state.
ideally, system would also be cancellable while running the external
command, but I cannot find any way to make that work without either
leaking zombie processes or introducing behavior that is far outside
what the standard specifies. glibc handles cancellation by killing the
child process with SIGKILL, but this could be unsafe in that it could
leave the data being manipulated by the command in an inconsistent
state.
fix usage of locks with vfork 2012年10月19日T19:02:37+00:00 Rich Felker dalias@aerifal.cx 2012年10月19日T19:02:37+00:00 599f97360389911c293e0ca4c5eb49e007377fba __release_ptc() is only valid in the parent; if it's performed in the child, the lock will be unlocked early then double-unlocked later, corrupting the lock state.
__release_ptc() is only valid in the parent; if it's performed in the
child, the lock will be unlocked early then double-unlocked later,
corrupting the lock state.
overhaul system() and popen() to use vfork; fix various related bugs 2012年10月18日T19:58:23+00:00 Rich Felker dalias@aerifal.cx 2012年10月18日T19:58:23+00:00 44eb4d8b9b7b3b539bcd4e311e9d7c8e2acf8d80 since we target systems without overcommit, special care should be taken that system() and popen(), like posix_spawn(), do not fail in processes whose commit charges are too high to allow ordinary forking. this in turn requires special precautions to ensure that the parent process's signal handlers do not end up running in the shared-memory child, where they could corrupt the state of the parent process. popen has also been updated to use pipe2, so it does not have a fd-leak race in multi-threaded programs. since pipe2 is missing on older kernels, (non-atomic) emulation has been added. some silly bugs in the old code should be gone too.
since we target systems without overcommit, special care should be
taken that system() and popen(), like posix_spawn(), do not fail in
processes whose commit charges are too high to allow ordinary forking.
this in turn requires special precautions to ensure that the parent
process's signal handlers do not end up running in the shared-memory
child, where they could corrupt the state of the parent process.
popen has also been updated to use pipe2, so it does not have a
fd-leak race in multi-threaded programs. since pipe2 is missing on
older kernels, (non-atomic) emulation has been added.
some silly bugs in the old code should be gone too.
initial check-in, version 0.5.0 2011年02月12日T05:22:29+00:00 Rich Felker dalias@aerifal.cx 2011年02月12日T05:22:29+00:00 0b44a0315b47dd8eced9f3b7f31580cf14bbfc01

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