Refactor checks for fpathconf and pathconf

[petk]

Hello, this was found recently. The posix_pathconf and posix_fpathconf are PHP function names. On the system these are pathconf and fpathconf therefore the typos fixed in the M4 stub file. Otherwise, with the current code in the master branch these functions won't be enabled on any system.

These two might not be available everywhere so we check them in config.m4 when doing the configure step.

Constants that are defined into main/php_config.h: HAVE_FPATHCONF
HAVE_PATHCONF

Implemented via GH-10238
Related to GH-10350

[petk]

@devnexen I also now understand what was up with the Alpine issue. Case is a bit different there. Alpine Linux has a very limited musl libc with POSIX implementation. Many things don't work there or they work differently compared to other distros. For example, the pathconf is present but it somehow has different limits set (those path max length constants)... I'm still not sure how to fix that entirely (the pathconf PHP test var_dumps int(255) instead of false etc). Maybe we should simply change the phpt file or even disable it for cases such as Alpine. I'll look into this more. But yes, probably we can merge this one as it is. It is a bit of a separate issue.

[nielsdos]

@petk Is there a reason this wasn't merged yet 🙂 ? It seems okay to me.
Reason I'm asking is that there's now a bug report for this issue. The PR would also need to be rebased on 8.3.

[petk]

Branch updated. I've also modified the TODO comments. Otherwise, what is the issue here: On Alpine Linux the tests will fail. The functions will be there working except that the error will be emitted differently (int(255) instead of false) because musl has very minimalist POSIX implementation of these two functions.

Edit: I was even doing all sorts of acrobatics here already:

dnl pathconf and fpathconf on musl libc don't check if first argument is valid,
dnl so we simply disable them there.
AC_CACHE_CHECK([whether pathconf and fpathconf work as expected], [php_cv_func_fpathconf_works], [
AC_RUN_IFELSE([AC_LANG_SOURCE([
  #include <unistd.h>
  int main(void) {
    return -1 == fpathconf(-1, _PC_PATH_MAX) ? 0 : 1;
  }
])],[
  php_cv_func_fpathconf_works=yes
],[
  php_cv_func_fpathconf_works=no
],[
  AS_IF([command -v ldd >/dev/null && ldd --version 2>&1 | grep -q ^musl], [
    php_cv_func_fpathconf_works=no
  ],[
    php_cv_func_fpathconf_works=yes
  ])
])
])
AS_IF([test "x$php_cv_func_fpathconf_works" = xyes], [
AC_DEFINE([HAVE_POSIX_PATHCONF], [1], [Whether pathconf and fpathconf work as expected])
])

It would be more properly to adjust the C code instead, however the error on musl will be very simplified...

[nielsdos]

Not sure what to do here. Looking at the musl source code and the POSIX description, it seems indeed wrong on musl's side.
While we can work around this, I really dislike doing so because we would be the ones to clean up Alpine/musl mess again...

[petk]

Added new commit here. Then let's simply disable these two on musl libc and check them on other implementations.

[mumumu]

Added new commit here.

OK. I confirmed this commit fixed this issue.

$ tar xvfz php-8.3.0RC6.tar.gz
$ cd php-8.3.0RC6
$ wget https://patch-diff.githubusercontent.com/raw/php/php-src/pull/11774.patch
$ patch -p1 < 11774.patch
$ ./buildconf --force
$ ./configure && make
$ ./sapi/cli/php -r 'echo posix_fpathconf(0,POSIX_PC_LINK_MAX);'
127

[petk]

This has been merged to 8.3 branch via ff2b508