On 1 October 2012 22:50, Bruno Haible <br...@clisp.org> 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
