Colin Rafferty wrote: Almost, but not quite. system() needs to change the signal disposition between the (v)fork() and the exec(). On platforms which don't overcommit, the fork() might fail with ENOMEM, so you would like to use vfork() instead. However, system() needs to change the signal disposition, and (AFAIK) you can't guarantee being able to call sigaction() etc following vfork() on all platforms. On a platform where you can't, system() would have to be implemented using fork(), which could fail if it doesn't overcommit. OTOH, a bare-bones vfork()/exec() without changing the signal disposition isn't really much use. Ultimately, this is only an issue on platforms which both: a) don't overcommit, and b) don't allow certain useful functions to be safely called between a vfork() and an exec(). As Georg pointed out: so such systems would appear to exist. Also, XEmacs' use of fork() is in situations more akin to popen(), where it is also necessary to use e.g. dup2() to set up pipes. For the benefit of platforms which don't overcommit, it would be useful to figure out what we call between fork() and exec(), so that vfork() can be used instead where possible. -- Glynn Clements <glynn(a)sensei.co.uk&gt;