This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [libiberty patch] pex-unix error behaviour
On 08/21/2018 03:04 PM, Ian Lance Taylor wrote:
On Tue, Aug 21, 2018 at 11:15 AM, Nathan Sidwell <nathan@acm.org> wrote:
OK, but what about a system that does
int vfork() { return fork(); }
?
Isn't such a system just buggy? Hm, apparently not. Because of the
requirement the user just calls 'exec(), _exit ()' a conformant program
cannot tell whether it's fork-like or not. However we're already
violating that constraint by dinking environ and calling close & write
[in ways that are ok regardless of a fork-like attribute]. I see the
man page says 'The requirements put on vfork() by the standards are
weaker than those put on fork(2), so an implementation where the two are
synonymous is compliant. In particular, the programmer cannot rely on
the parent remaining blocked until the child either terminates or calls
execve(2), and cannot rely on any specific behavior with respect to
shared memory.'
pants. I suppose we could add an autoconf test to probe whether the
child and parent are serialized or not. that may or may not be simpler
than ...
The error behaviour if that program fails to be exec'd is confusing --
there's an error about the exec failing but it's not attached to location
information and the like, then there's a much more obvious error about
communication failing. I found it confusing the first time I tripped over
it (and I was writing that bit of the compiler :)
Is there any reason we couldn't fix that without relying on the odd
behavior of vfork?
Maybe, ideas? (but this seemed the simplest way for me to get it to do
what I wanted :)
nathan
--
Nathan Sidwell