On Tue, Jun 12, 2001 at 02:17:32PM -0700, Paul Eggert wrote:
> > From: Eric Siegerman <[EMAIL PROTECTED]>
> > Date: Tue, 12 Jun 2001 15:02:58 -0400
> >
> > you can get away with:
> > #define a b
> > (or the equivalent using true functions) only if a()'s behaviour
> > is a strict subset of b()'s. That's not the case with
> > fork/vfork, in either direction.
>
> But it is true for 'vfork' if you use vfork portably.
I earlier quoted a document which states that doing so is
difficult in practice, "especially in high-level languages". (I
won't reiterate the rest of the quote, just the reference:
http://www.linuxdoc.org/HOWTO/Secure-Programs-HOWTO/avoid-vfork.html)
If this is out to lunch, please tell me, and I'll shut up about
it! If it's correct, though, it's a strong argument against
using vfork in place of fork in code which is intended to be
portable.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. [EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
