Fixes pushed to git, thanks!
When given an unexecutable path, child_spawn() returns 0, but errno
is unset... that's on purpose. Unfortunately, in the parent there is
no way to know the child's execve() error code; all we have is the
exit status, 127, and we cannot report the reason for the failure.
Rather than set errno to something that may be wrong and prompt the
caller to take inadequate measures, I'd rather set it to 0, which
glibc reports as "success" but really means "no error information"
except in a few, well-known contexts; and let the caller deal with
the lack of more accurate reporting. I know it's not satisfying, but
we can't do any better.
>I have realised that a simpler unexecutable path can be, for example,
>/etc (is it mandated in POSIX?); this can save the mkstemp() call
>in the sysdep test.
POSIX doesn't mandate any path other than /dev/null and /dev/console
and I'd rather not try executing them, who knows what weird permissions
they may have on obscure OSes.
It's a sysdep test, it's not performance-critical; I'd rather use
mkstemp() to be *sure* we have a path that does not exist.
(Of course the user could always race the program, but we're not trying
to harden against stupidity here.)
>(And frankly I personally do not really find it much worthwhile to
>introduce this amount of complexity for the broken dependency of a
>quite minor performance optimisation...)
I agree it's a lot of work for not much, but as you said, the
behaviour is arguably conformant, and your experience proves that old
glibcs are still around, so I'd rather make posix_spawn usable where
it exists instead of placing the burden of --with-sysdep-posixspawn=no
on users who have a bad version.
As shown by the qemu bug I linked above, this impacts s6-svscan,
which relies on correct child_spawn() reporting when running custom
signal handlers, so not working around bad posix_spawn QoI may lead
to buggy signal management in s6-svscan, and nobody wants that.
A cursory web search appears to say that glibc-2.27 is when they fixed
the posix_spawn QoI; 2.17 being bad is consistent with that. But I can't
be bothered to go spelunk in glibc code to check and/or bisect, so if
someone could confirm, thank you, otherwise, no big deal.
--
Laurent
Received on Thu Jun 29 2023 - 10:21:19 CEST