bug-gnulib
[Top][All Lists]
Advanced

[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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]