Re: [patch] Zap more #ifdef HAVE_VFORK

[Kevin Buettner <kevinb at cygnus dot com>]

On Mar 26, 11:45am, Andrew Cagney wrote:

> Missed this when re-fixing the autoconfed vfork() call.
[...]
>     /* Clone the debugger. */
> - #ifdef HAVE_VFORK
>     if (debug_fork)
>       debugger_pid = fork ();
>     else
>       debugger_pid = vfork ();
> - #else
> -   debugger_pid = fork ();
> - #endif

This didn't make any sense to me at first.  It did when I went back
and (re)read

    http://sources.redhat.com/ml/gdb-patches/2001-01/msg00380.html

What's happening is that AC_FUNC_VFORK is doing #define vfork fork
when the host doesn't have vfork.

Personally, I think the AC_FUNC_VFORK mechanism is being overly clever
and does not contribute to the clarity of the code.  We have very few
calls to fork() in gdb and I would much rather see the somewhat more
clunky:

    #ifdef HAVE_VFORK
	pid = vfork ();
    #else
	pid = fork ();
    #endif

instead of just

    pid = vfork ();

with the understanding the vfork might've been magically defined to
be fork.

I'm sure I would feel differently if we had several hundred calls to
fork/vfork in the sources.

If we're going to use the AC_FUNC_VFORK mechanisms, might I suggest
that we do one of the following?

    1) Document the fact that the autoconf cleverness *might* actually
       have defined vfork to be fork at each use vfork.

    2) Create a gdb_fork() which does the appropriate thing *and*
       documents the autoconf cleverness in the guts of gdb_fork().

Kevin