RE: libiberty/pex-unix vfork abuse?

["Dave Korn" <dave dot korn at artimi dot com>]

On 07 December 2007 16:59, Ian Lance Taylor wrote:

> "Dave Korn" <dave.korn@artimi.com> writes:
> 
>>   Note the several calls to dup2() and close(), which seem to me to be
>> "calls [to] any other function", and the setting of environ, which seem to
>> me to be modification of "any data other than a variable of type pid_t
>> used to store the return value from vfork()".
> 
> Despite the standardese, vfork was invented to support calling
> dup/dup2 before calling exec.  Without that feature, it would be
> nearly useless.  Any actual implementation of vfork must support
> calling dup/dup2, or it will break all real programs which use vfork.

  Ah, right, hence the 'defensive coding' relating to the fdtab in cygwin.  I
can see how hard it would be to do the standard unix fork-and-fd-swap dance
without that.  (Should possibly Cc. the austin group ml and suggest a revision
to the wording, assuming they aren't deciding to remove it altogether).

> On the other hand, the setting of environ is very dubious and is
> likely to break on real systems.  The code should be changed to call
> execve instead.  Unfortunately there is no standard execvpe function.
> Fortunately gcc never uses the variant which sets environ.  Offhand
> I'm not sure what does.

  Perhaps we could work around this case by setting environ in the parent
before the vfork call and restoring it afterward, but we'd need kind of
serialisation there, and I don't know how to do a critical section using
pthreads/posix.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....