>--[Paul Eggert]--<[EMAIL PROTECTED]>
> > > I don't think the uses are portable.
> > Wait, why not?
> The latest POSIX draft says this:
> [...]
Okay.
> > And if they aren't, would it be okay to change the
> > HAVE_WORKING_VFORK to !HAVE_WORKING_FORK?
> No. For AC_FUNC_WAIT3 and AC_SYS_RESTARTABLE_SYSCALLS vfork is
> definitely the wrong function, as those tests rely on the parent and
> child running simultaneously, which is not a portable use of vfork.
Wait, I disagree. If there is no fork(), the platform isn't a POSIX-whatever
platform, so we shouldn't be too strict on what a vfork()ed process is
allowed to do. It doesn't modify variables the parent process uses, but okay
it calles functions, but that seems harmless to me (at least on AmigaOS).
I don't see why the AC_FUNC_WAIT3 test relies on the parent running at the
same time (though I see it with AC_SYS_RESTARTABLE_SYSCALLS - is there
a way to test it just using vfork()?), maybe enlighten me?
> And for AC_FUNC_GETPGRP, if fork is not available, the test will
> assume that getpgrp has no arguments, which I assume is OK for AmigaOS
It happens to be the correct result AFAIK, yes. The ixemul.library providing
the POSIX-stuff is derived from BSD sources. But - it just _happens_ to be
the right answer.
> > * fork(), that should be a fork() if possible, but if not available,
> > a vfork() should do the job as well
> I don't see why this case would ever happen in real code.
Uses of fork() that are only pretty near the requirements of a POSIX
vfork()? Then it might be better to try vfork() than not to have fork() at
all.
> This part of the patch is unrelated to the topic.
Actually I didn't change anything there, so lay the blame on cvs...
Yours, Rüdiger.
--
A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi
