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: Bruno Haible
Subject: Re: [PATCH] getcwd-lgpl: fix m4 to match relaxed test for BSD
Date: Mon, 21 Nov 2011 00:23:28 +0100
User-agent: KMail/1.13.6 (Linux/2.6.37.6-0.5-desktop; KDE/4.6.0; x86_64; ; )

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".

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".
  - 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.
  - 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?

The first one seems more right to me. Jim, Paul?

Bruno
-- 
In memoriam Kerem Yılmazer <http://en.wikipedia.org/wiki/Kerem_Yılmazer>



reply via email to

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