Bruno Haible wrote: > Eric Blake wrote on 2011-08-17: >> gl_FUNC_GETCWD_ABORT_BUG([gl_abort_bug=yes]);; >> esac >> >> - case $gl_cv_func_getcwd_null,$gl_cv_func_getcwd_path_max,$gl_abort_bug in >> - *yes,yes,no) ;; >> + case >> $gl_cv_func_getcwd_null,$gl_cv_func_getcwd_posix_signature$gl_cv_func_getcwd_path_max,$gl_abort_bug >> in >> + *yes,yes,yes,no) ;; >> *) >> dnl Full replacement lib/getcwd.c, overrides LGPL replacement. >> REPLACE_GETCWD=1;; > > This change has the effect of setting REPLACE_GETCWD to 1 on *all* > platforms. A string with only two commas can never math the pattern > "*yes,yes,yes,no".
Obviously a typo. > Such as on glibc 2.11/Linux or MacOS X or FreeBSD 6.4, OpenBSD 4.9, NetBSD > 5.1: > checking whether getcwd (NULL, 0) allocates memory for result... yes > checking for getcwd with POSIX signature... yes > checking whether getcwd is declared... yes > S["REPLACE_GETCWD"]="1" > > I'd like to rectify this. The fix is not just to fix the 'case' statement, > because on OpenBSD 4.9, NetBSD 5.1 that leads to REPLACE_GETCWD=0 (as > intended) > but then the unit test fails with error code 32, i.e. test_abort_bug() > returned 4. > > On these two platforms, > - The test program from m4/getcwd-abort-bug.m4 fails with exit code 4, > - but the macrology around it considers an error code 4 to be OK > (this is also what the comment says: "This is ok, and expected". That is true. Remember that this is a configure-time test. It is testing the system's getcwd. Some versions of getcwd do fail in that case, yet we must use them when possible, to handle names shorter than PATH_MAX with inaccessible parents. In this case, gnulib's getcwd calls the system's getcwd, and handles the case in which it fails due to the PATH_MAX limitation. > - Then, if getcwd does not get overridden by gnulib, in tests/test-getcwd.c > the function test_abort_bug() returns 4 and the test fails. That sounds right, because here, we're testing gnulib's replacement getcwd function. With gnulib's getcwd, a return value of 4 from test_abort_bug does indicate a failure. > - Finally, the documentation says that the 'getcwd' module fixes the fact > that "This function does not handle long file names (greater than > PATH_MAX)" > > So, what should we do? > - Change m4/getcwd-abort-bug.m4 to consider an exit code 4 also to be a > failure? > - Or change tests/test-getcwd.c to consider test_abort_bug() = 4 a success > and change the documentation to state that getcwd(NULL,0) may not work > with long file names, even when module 'getcwd' is enabled? gnulib's getcwd should never make test_abort_bug() return 4. Do you know how/why that happens?
