#
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 ...
|
#
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 ...
|
#
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 ...
|
#
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 ...
|