The following reply was made to PR apache-api/2258; it has been noted by GNATS.
From: "Saccoccio, Robert" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Cc: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Subject: RE: apache-api/2258: The second arg to spawn_child_err() changed
from "void (*)(void *)" in 1.2 to "int(*)(void *)" in 1.3
Date: Thu, 21 May 1998 16:06:15 -0400
> implementation. So, third-party modules which use
> spawn_child are going to have to be modified for 1.3
> anyways. Also, all third-party modules should use
> ap_spawn_child_err_buff to be completely safe on NT.
>
What's the best way to conditionally handle both 1.2.x and 1.3b6-, 1.3b7+?
APACHE_RELEASE?
I'm actually calling spawn_child(), not ap_spawn_child_err() (like the
apache code referred to below). spawn_child(), as you mentioned, is a macro
which maps to ap_spawn_child_err(). Its actually the spawn_child() API that
brought this to my attention. Is that too changing with 1.3b7 (similar to
the change to ap_spawn_child_err())?
> > Additionally, calls to spawn_child() should be changed to
> ap_spawn_child()
> > for consistency with the conversion to the new namespace. This will
> > require ap_spawn_child() be defined in alloc.h instead of spawn_child()
> > (which should be only in compat.h). The current approach is
> non-intuitive
> > and sets a bad example.
>
> Would be nice to do, it's slightly more complex since spawn_child
> is a macro but shouldn't be impossible. I'll see about doing
> it.
>
Its not clear to me why it being a macro makes it more complex?
