I don't know linux at all, but from what I have seen about the problem
here, it looks as if linux doesn't really have vfork() at all, but
some abomination that they happen to call vfork() (of course, for linux,
that sounds pretty typical).
Sorry, but you are wrong. If this was the case, I would have written the
bug report along the lines of "Please work around the broken linux
vfork()". But out of reason I didn't.
One of the *requirements* for vfork() - the thing that actually makes
the big difference, is that the parent process cannot continue until after
the child process has called exec() (one of the exec family) or exit().
This is what the linux vfork manpage says.
But BTW IIRC there is no guarantee that this "requirement" is met in the
standards. Ie #define vfork() fork() is a valid implementation. But
of course not all systems obey the standards...
By definition, that means that "errno smashing" cannot happen, as the
child half of the pair must be gone before the parent half returns
from the vfork() sys call - sys calls are always allowed to alter errno,
so the parent cannot be depending upon its value being unchanged around
a vfork() call (only that it will have a meaningful value when vfork()
returns -1)
Obviously nmh does depend upon errno being unchanged, so it's the fault
of nmh itself not linux. (Indeed I overlooked, that this is
a bug even if fork() is used instead. However, I guess it's still a bad
idea to use any syscalls between vfork() and exec() - so actually it's
two bugs to be fixed...)
Harald
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers