History log of /freebsd/lib/libc/tests/gen/posix_spawn_test.c (Results 1 – 7 of 7)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: release/14.0.0
# 559a218c 01-Nov-2023 Warner Losh <imp@FreeBSD.org>

libc: Purge unneeded cdefs.h

These sys/cdefs.h are not needed. Purge them. They are mostly left-over
from the $FreeBSD$ removal. A few in libc are still required for macros
that cdefs.h defines. Kee

libc: Purge unneeded cdefs.h

These sys/cdefs.h are not needed. Purge them. They are mostly left-over
from the $FreeBSD$ removal. A few in libc are still required for macros
that cdefs.h defines. Keep those.

Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D42385

show more ...


# 1d386b48 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/


Revision tags: release/13.2.0, release/12.4.0, release/13.1.0
# c9afc768 27-Jan-2022 Kyle Evans <kevans@FreeBSD.org>

tests: fix posix_spawnp_enoexec_fallback_null_argv0

This test was written because execvp was found to improperly handle the
argc == 0 case when it falls back from an ENOEXEC. We could probably
most

tests: fix posix_spawnp_enoexec_fallback_null_argv0

This test was written because execvp was found to improperly handle the
argc == 0 case when it falls back from an ENOEXEC. We could probably
mostly revert it now, but let's just fix the test for the time being and
circle back later to decide if we want to simplify execvp. The test
will likely remain either way just to make sure execvp isn't working
around the newly enforced restriction with the fallback.

Fixes: 301cb491ea41 ("execvp: fix up the ENOEXEC fallback")
Reported by: jenkins via lwhsu@

show more ...


Revision tags: release/12.3.0, release/13.0.0, release/12.2.0, release/11.4.0
# 301cb491 10-Jun-2020 Kyle Evans <kevans@FreeBSD.org>

execvp: fix up the ENOEXEC fallback

If execve fails with ENOEXEC, execvp is expected to rebuild the command
with /bin/sh instead and try again.

The previous version did this, but overlooked two det

execvp: fix up the ENOEXEC fallback

If execve fails with ENOEXEC, execvp is expected to rebuild the command
with /bin/sh instead and try again.

The previous version did this, but overlooked two details:

argv[0] can conceivably be NULL, in which case memp would never get
terminated. We must allocate no less than three * sizeof(char *) so we can
properly terminate at all times. For the non-NULL argv standard case, we
count all the non-NULL elements and actually skip the first argument, so we
end up capturing the NULL terminator in our bcopy().

The second detail is that the spec is actually worded such that we should
have been preserving argv[0] as passed to execvp:

"[...] executed command shall be as if the process invoked the sh utility
using execl() as follows:

execl(<shell path>, arg0, file, arg1, ..., (char *)0);

where <shell path> is an unspecified pathname for the sh utility, file is
the process image file, and for execvp(), where arg0, arg1, and so on
correspond to the values passed to execvp() in argv[0], argv[1], and so on."

So we make this change at this time as well, while we're already touching
it. We decidedly can't preserve a NULL argv[0] as this would be incredibly,
incredibly fragile, so we retain our legacy behavior of using "sh" for
argv[] in this specific instance.

Some light tests are added to try and detect some components of handling the
ENOEXEC fallback; posix_spawnp_enoexec_fallback_null_argv0 is likely not
100% reliable, but it at least won't raise false-alarms and it did result in
useful failures with pre-change libc on my machine.

This is a secondary change in D25038.

Reported by: Andrew Gierth <andrew_tao173.riddles.org.uk>
Reviewed by: jilles, kib, Andrew Gierth
MFC after: 1 week

show more ...


Revision tags: release/12.1.0, release/11.3.0, release/12.0.0, release/11.2.0, release/10.4.0, release/11.1.0, release/11.0.1, release/11.0.0, release/10.3.0
# b626f5a7 04-Jan-2016 Glen Barber <gjb@FreeBSD.org>

MFH r289384-r293170

Sponsored by: The FreeBSD Foundation


# a5d8944a 19-Nov-2015 Navdeep Parhar <np@FreeBSD.org>

Catch up with head (r291075).


# fbf5b9f8 09-Nov-2015 Enji Cooper <ngie@FreeBSD.org>

Integrate tools/regression/lib/libc/gen into the FreeBSD test suite
as lib/libc/tests/gen

The code in test-fnmatch that was used for generating:

- bin/sh/tests/builtins/case2.0
- bin/sh/tests/built

Integrate tools/regression/lib/libc/gen into the FreeBSD test suite
as lib/libc/tests/gen

The code in test-fnmatch that was used for generating:

- bin/sh/tests/builtins/case2.0
- bin/sh/tests/builtins/case3.0

has been left undisturbed. The target `make sh-tests` has been moved over
from tools/regression/lib/libc/gen/Makefile to
lib/libc/tests/gen/Makefile and made into a PHONY target

case2.0 and case3.0 test input generation isn't being done automatically.
This needs additional discussion.

MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division

show more ...