Hi Jim,
Getting back to this issue from last Monday:
> > If we fix Eric's typo, REPLACE_GETCWD will come out as 0 on OpenBSD and
> > NetBSD.
>
> Do you know how that happens, given the corrected code?
It's because of the details in m4/getcwd-abort-bug.m4.
> The part that is surprising is that
Bruno Haible wrote:
...
>> > 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(NUL
Hi Jim,
> > 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.
Yes, sure.
> > Such as on glibc 2.11/Linux or MacOS X or FreeBSD 6.4, OpenBSD 4.9, NetBSD
> > 5.1:
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$
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,$
Commit c6dc8f1 changed test-getcwd-lgpl to allow BSD behavior
where getcwd(NULL,1) allocates the proper size, in addition to
the glibc behavior of allocating exactly one byte then failing
with ERANGE. But the m4 test was still rejecting the former
behavior.
However, merely fixing the test to avoi
