Re: FreeBSD bugs

[Ed Maste]

On 1 October 2012 22:50, Bruno Haible <address@hidden> wrote:
> Hi Ed,
>
>> it looks like we're pretty close to having all of
>> the tests apply and pass on FreeBSD so I suspect I don't have many
>> more to find.
>
> Do you know what is the status of the following bugs in the newest
> FreeBSD release? Let me cite the sections of gnulib documentation.
> You find the test cases in the corresponding *.m4 files.

Thanks for the list - here's the current status, on 9.1 prerelease.
It'll take a little while to fully analyze the remaining failures.

> alphasort
> The parameters of this function are declared as @code{const void *} on some 
> platforms:

Fixed,
http://www.freebsd.org/cgi/query-pr.cgi?pr=142255
http://svnweb.freebsd.org/base?view=revision&revision=201512

> chown
> Some platforms fail to detect trailing slash on non-directories, as in
> @code{chown("link-to-file/",uid,gid)}:

Fixed - I didn't find the PR or commit, but from configure.log:

configure:14616: checking whether chown honors trailing slash
configure:14653: result: yes

> dup2
> This function returns @code{EMFILE} instead of @code{EBADF} for
> extremely large targets, which interferes with using
> @code{dup2(fd,fd)==fd)} as the minimal @code{EBADF} filter:

Fixed,
http://www.freebsd.org/cgi/query-pr.cgi?pr=164970
http://svnweb.freebsd.org/base?view=revision&revision=234131

> fclose
> On some platforms, this function fails to set the file position of a
> seekable input stream to the byte after the last one actually read:

configure:21795: checking whether fflush works on input streams
configure: program exited with status 4

> fcntl
> This function does not support @code{F_DUPFD_CLOEXEC} on some
> platforms:

Issue is present

> fdopendir
> This function mistakenly closes non-directory file descriptors on some
> platforms:

Issue is present

> fflush
> @code{fflush} on an input stream right after @code{ungetc} does not discard
> the @code{ungetc} buffer, on some platforms:

Issue present, same as fclose above

> fmaf
> This function produces wrong results on some platforms:

configure:47801: checking whether fmaf works
configure:47924: result: yes

> fmal
> This function produces wrong results on some platforms:

configure:48113: checking whether fmal works
configure:48428: result: yes

> fma
> This function produces wrong results on some platforms:

configure:47491: checking whether fma works
configure:47613: result: yes

> *printf
> printf @code{"%010f"} of NaN and Infinity yields an incorrect result (padded
> with zeroes) on some platforms:

configure:17361: checking whether printf supports the zero flag correctly
configure:17406: result: yes

> This function can crash in out-of-memory conditions on some platforms:

configure:17513: checking whether printf survives out-of-memory conditions
configure:17735: result: no

> getdelim, getline
> This function crashes when passed a pointer to a NULL buffer together with a
> pointer to a non-zero buffer size on some platforms:

configure:53720: checking for working getdelim function
configure:53790: result: yes

configure:54487: checking for working getline function
configure:54557: result: yes

> getgroups
> On some platforms, this function fails to reject a negative count,
> even though that is less than the size that would be returned:

Issue present

> lchown
> Some platforms fail to detect trailing slash on non-directories, as in
> @code{lchown("link-to-file/",uid,gid)}:

Fixed, same as chown above

> link
> This function fails to reject trailing slashes on non-directories on
> some platforms:

I didn't find the specific test for this one.

> mkfifo
> This function mishandles trailing slash on some platforms:

configure:69803: checking whether mkfifo rejects trailing slashes
configure:69846: result: yes

> mknod
> This function requires super-user privileges to create a fifo:

configure:69971: checking whether mknod can create fifo without root privileges
configure:70012: result: yes

> This function mishandles trailing slash on some platforms:

Same as mkfifo above

> modf
> This function has problems with infinite arguments on some platforms:

configure:70726: checking whether modf works according to ISO C 99
with IEC 60559
configure: program exited with status 2

> open
> This function does not fail when the file name argument ends in a slash
> and (without the slash) names a nonexistent file or a file that is not a
> directory, on some platforms:

configure:72756: checking whether open recognizes a trailing slash
configure:72807: result: yes

> perror
> This function treats @code{errno} of 0 like failure, although POSIX
> requires that the message declare it as a success, on some platforms:

Not sure this is the test described above, but:
configure:73464: checking whether perror matches strerror
configure:73512: result: yes

> pthread_sigmask
> This function is declared in @code{<pthread.h>} instead of @code{<signal.h>}
> on some platforms:

It's in signal.h

> This function does nothing and always returns 0 in programs that are not
> linked with @code{-lpthread} on some platforms:

configure:76179: checking whether pthread_sigmask works without -lpthread
configure:76219: result: no

> readlink
> Some platforms mistakenly succeed on @code{readlink("link/",buf,len)}:

configure:77747: checking whether readlink handles trailing slash correctly
configure:77782: result: yes

> On some platforms, @code{readlink} returns @code{int} instead of
> @code{ssize_t}:

configure:77720: checking whether readlink signature is correct
configure:77745: result: yes

> realpath
> This function does not allow for a NULL @samp{resolved} parameter on
> some platforms:

configure:13665: checking whether realpath works
configure:13841: result: yes

> remove
> This function fails to reject trailing slashes on non-directories on
> some platforms:

I see REPLACE_REMOVE='1', but don't see a test corresponding to this.

> rename
> This function does not reject trailing slashes on symlinks to
> non-directories on some platforms, as in
> @code{rename("link-to-file/","f")}:

configure:79590: checking whether rename honors trailing slash on destination
configure:79641: result: yes
configure:79650: checking whether rename honors trailing slash on source
configure:79701: result: yes

> scandir
> The fourth parameter of this function is declared as @code{int (*) (const 
> void *, const void *)} on some platforms:

I don't see the test, but from the man page:

     scandir(const char *dirname, struct dirent ***namelist,
         int (*select)(const struct dirent *),
         int (*compar)(const struct dirent **, const struct dirent **));

> setenv
> On some platforms, this function does not fail with @samp{EINVAL} when
> passed an empty string or a string containing @samp{=}:

configure:82666: checking whether setenv validates arguments
configure:82704: $? = 0

> stat
> On some platforms, @code{stat("link-to-file/",buf)} succeeds instead
> of failing with @code{ENOTDIR}.

configure:86558: checking whether stat handles trailing slashes on directories
configure:86591: result: yes
configure:86593: checking whether stat handles trailing slashes on files
configure:86638: result: yes

> strerror
> This function reports failure for @code{strerror(0)} (by setting
> @code{errno} or using a string similar to out-of-range values),
> although POSIX requires this to leave @code{errno} unchanged and
> report success, on some platforms:

configure:31836: checking whether strerror(0) succeeds
configure:31876: result: yes

> strerror_r
> This function reports failure for @code{strerror_r(0, buf, len)},
> although POSIX requires this to succeed, on some platforms:

I don't see an explicit test for strerror_r for this, but presumably
fixed as strerror above.

> When the value is not in range or the buffer is too small, this
> function fails to leave a NUL-terminated string in the buffer on some
> platforms:

configure:31937: checking whether strerror_r works
configure:32003: result: yes

> strstr
> This function has quadratic instead of linear worst-case complexity on some
> platforms:

configure:89105: checking whether strstr works in linear time
configure:89190: result: no

> strtod
> This function returns the wrong end pointer for @samp{-0x} on some
> platforms:
> This function fails to parse @samp{NaN()} on some platforms:
> This function fails to correctly parse very long strings on some
> platforms:

configure:89327: checking whether strtod obeys C99
configure:89452: result: yes

> symlink
> On some systems, @code{symlink(value,"name/")} mistakenly creates a
> symlink:

configure:90017: checking whether symlink handles trailing slash correctly
configure:90056: result: yes

> unlink
> Some systems mistakenly succeed on @code{unlink("link-to-file/")}:

configure:109928: checking whether unlink honors trailing slashes
configure:109981: result: yes

> unsetenv
> This function has the return type @samp{void} instead of @samp{int} on some
> platforms:

It's int.

> On some platforms, this function does not fail with @samp{EINVAL} when
> passed an empty string or a string containing @samp{=}:

Hmm, it's actually failing before that now.

configure:110450: checking whether unsetenv obeys POSIX
configure: program exited with status 3
       if (getenv ("a")) return 3;

> utimes
> On some platforms, this function mis-handles trailing slash:

configure:34961: checking whether the utimes function works
configure:35086: result: yes