This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 <> 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 Sidwell

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]