3 ms·

> its semantics do not depend on how a process is executed by the host operating system Implementation details can leak though. For example on unix, if your pr

by thayne 3y ago

> its semantics do not depend on how a process is executed by the host operating system Implementation details can leak though. For example on unix, if your process uses a lot of memory, a fork can result in an out of memory error, if there isn't enough memory left on the system to copy the parent process memory. And afaict things like how file descriptors are inherited are implementation defined. > which works more or less in the same way under any OS Even ignoring subtle differences in how subprocesses are spawned, there is the little issue that shell escaping and argument splitting works differently on different OSes, or even different shells on the same OS.

adrian_b 3y ago
Because the differences mentioned by you between shells and OSes are unavoidable, the C standard specifies that the interpretation of the character string passed as an argument of the system() function is implementation-defined and it must be documented by any implementation of the standard C library. This does not change the fact that whether a system() function implementation uses or does not use fork and exec is neither specified by the function definition nor relevant for the user, and in any case system() is not the function that should be used when the intention is to simplify some code that otherwise would invoke fork and exec.
- thayne 3y ago
  > This does not change the fact that whether a system() function implementation uses or does not use fork and exec is neither specified by the function definition nor relevant for the user I agree that it isn't specified, but it can be relevant for the user, depending on what the user is doing. > in any case system() is not the function that should be used when the intention is to simplify some code that otherwise would invoke fork and exec Which was my original point. system doesn't save you from the problems of fork/exec, because depending on the system, it might be using fork/exec anyway, and adds additional limitations and caveats on top.

by thayne 3y ago

adrian_b 3y ago

Because the differences mentioned by you between shells and OSes are unavoidable, the C standard specifies that the interpretation of the character string passed as an argument of the system() function is implementation-defined and it must be documented by any implementation of the standard C library. This does not change the fact that whether a system() function implementation uses or does not use fork and exec is neither specified by the function definition nor relevant for the user, and in any case system() is not the function that should be used when the intention is to simplify some code that otherwise would invoke fork and exec.

thayne 3y ago
> This does not change the fact that whether a system() function implementation uses or does not use fork and exec is neither specified by the function definition nor relevant for the user I agree that it isn't specified, but it can be relevant for the user, depending on what the user is doing. > in any case system() is not the function that should be used when the intention is to simplify some code that otherwise would invoke fork and exec Which was my original point. system doesn't save you from the problems of fork/exec, because depending on the system, it might be using fork/exec anyway, and adds additional limitations and caveats on top.