[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] getcwd-lgpl: fix m4 to match relaxed test for BSD
From: |
Jim Meyering |
Subject: |
Re: [PATCH] getcwd-lgpl: fix m4 to match relaxed test for BSD |
Date: |
Mon, 21 Nov 2011 10:59:20 +0100 |
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?