[GIT-PULLS] [php-src] PR #22717: ext/posix: remove musl pathconf workarounds
[email protected] (orlitzky)
| Newsgroups | php.git-pulls |
|---|---|
| Message-ID | <[email protected]> |
Pull Request: https://github.com/php/php-src/pull/22717
Author: orlitzky
We have a test in `build/php.m4` for the C library (glibc, musl, etc.) that is used to skip the `pathconf()` and `fpathconf()` checks in `ext/posix/config.m4`. They are skipped on musl because the musl implementations do not validate their first arguments, and in the past that lead to two test failures: one for `posix_pathconf()`, and one for `posix_fpathconf()`.
In php >= 8.5, the `posix_fpathconf()` wrapper now validates the file descriptor itself, so there is no longer any need to exclude musl in that case.
The other failure in `posix_pathconf()` looks for an error when using a non-existent path. POSIX however allows the implementation to ignore the path when it will not affect the result, meaning that musl is fully compliant here. And as we obtain the correct answer in lieu of an error, I think it is fine to accept the musl implementation here as well.
This commit removes the build-time musl exception, and updates the one failing test to expect either a failure (glibc), or an integer response (musl) when given an invalid path.
The relevant POSIX page is https://pubs.opengroup.org/onlinepubs/9799919799/functions/pathconf.html, but you have to read the RATIONALE section for the juicy bit:
> Also note that most of the errors are optional. If one of the variables always has the same value on an implementation, the implementation need not look at path or fildes to return that value and is, therefore, not required to detect any of the errors except the meaning of [EINVAL] that indicates that the value of name is not valid for that variable, and the [EOVERFLOW] error that indicates the value to be returned is larger than {LONG_MAX}.
Targeting PHP-8.5 where `posix_fpathconf()` already works, but the same approach can be used in `posix_fpathconf.phpt` for PHP-8.4.