Re: [PATCH 4/9] sockets, sys_stat: remove AC_C_INLINE in MSVC-only cases
Hi Paul, > Anyway, I reverted that change. Thanks. Bruno
Re: diffutils test failure on nixos/hydra's solaris build
On 30 September 2012 17:39, Bruno Haible wrote:
> Jim Meyering wrote on 2012-08-28:
>> FAIL: test-localeconv (exit: 262)
>> =
>>
>> test-localeconv.c:41: assertion failed
>>
>> which corresponds to this line:
>>
>> $ cat -n tests/test-localeconv.c|grep -B6 41
>> 35{
>> 36 struct lconv *l = localeconv ();
>> 37
>> 38 ASSERT (STREQ (l->decimal_point, "."));
>> 39 ASSERT (STREQ (l->thousands_sep, ""));
>> 40 #if !defined __FreeBSD__
>> 41 ASSERT (STREQ (l->grouping, ""));
>>
>
> It's easy to work around the failure. Since that particular test
> is already exempted on FreeBSD, it's not a big deal to also disable
> it on Solaris 11.
For FreeBSD specifically I'd rather conclude either that this is a bug
in our localeconv and fix it, or that more than one value for
l->grouping is permissible and change the test. I've raised a FreeBSD
pr for this: http://www.freebsd.org/cgi/query-pr.cgi?pr=172215 since
it looks to me like the most recent standards suggest grouping should
be "" rather than "\177".
That said, the test passes for me with the following change:
--- a/tests/test-localeconv.c
+++ b/tests/test-localeconv.c
@@ -37,15 +37,11 @@ main ()
ASSERT (STREQ (l->decimal_point, "."));
ASSERT (STREQ (l->thousands_sep, ""));
-#if !(defined __FreeBSD__ || defined __sun)
-ASSERT (STREQ (l->grouping, ""));
-#endif
+ASSERT (l->grouping[0] == CHAR_MAX || STREQ (l->grouping, ""));
ASSERT (STREQ (l->mon_decimal_point, ""));
ASSERT (STREQ (l->mon_thousands_sep, ""));
-#if !(defined __FreeBSD__ || defined __sun)
-ASSERT (STREQ (l->mon_grouping, ""));
-#endif
+ASSERT (l->mon_grouping[0] == CHAR_MAX || STREQ (l->mon_grouping, ""));
ASSERT (STREQ (l->positive_sign, ""));
ASSERT (STREQ (l->negative_sign, ""));
-Ed
Re: unistd.h has to be included twice to avoid compile errors on MinGW
Bruno Haible wrote: Hi, Philip Nienhuis wrote on 2012-08-26: See this thread: http://lists.gnu.org/archive/html/bug-gnulib/2011-01/msg00473.html When compiling code invoking gnulib under MinGW, the statement #include has to present in duplo to avoid certain errors of the kind: "... is not a member of 'gnulib'" (where ... could be e.g., gethostname, isatty, unlink, etc). This issue has not been solved until now; so here's again a request to look into it. This is a complicated issue that we cannot solve by guesswork. What we need is an unambiguous step-by-step "how to reproduce" recipe. What source code file to compile (or alternatively, what sources to download), with which compiler to configure it (there are many mingw versions floating around), etc. Isn't the analysis in the thread linked to in my post insufficient? Looks fairly step-by-step to me. I'm not a MinGW developer - I have mailed this bug report at the request of octave devs (see this thread: https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-August/029710.html (line wrap!)) Hopefully some MinGW devs can jump in? Thanks Bruno, Philip
Re: diffutils test failure on nixos/hydra's solaris build
Ed Maste wrote:
> On 30 September 2012 17:39, Bruno Haible wrote:
>> Jim Meyering wrote on 2012-08-28:
>>> FAIL: test-localeconv (exit: 262)
>>> =
>>>
>>> test-localeconv.c:41: assertion failed
>>>
>>> which corresponds to this line:
>>>
>>> $ cat -n tests/test-localeconv.c|grep -B6 41
>>> 35{
>>> 36 struct lconv *l = localeconv ();
>>> 37
>>> 38 ASSERT (STREQ (l->decimal_point, "."));
>>> 39 ASSERT (STREQ (l->thousands_sep, ""));
>>> 40 #if !defined __FreeBSD__
>>> 41 ASSERT (STREQ (l->grouping, ""));
>>>
>>
>> It's easy to work around the failure. Since that particular test
>> is already exempted on FreeBSD, it's not a big deal to also disable
>> it on Solaris 11.
>
> For FreeBSD specifically I'd rather conclude either that this is a bug
> in our localeconv and fix it, or that more than one value for
> l->grouping is permissible and change the test. I've raised a FreeBSD
> pr for this: http://www.freebsd.org/cgi/query-pr.cgi?pr=172215 since
> it looks to me like the most recent standards suggest grouping should
> be "" rather than "\177".
>
> That said, the test passes for me with the following change:
Thanks for the patch!
Dare I ask? ;-) Did you try it on Solaris 11?
If not, I will get to it.
> --- a/tests/test-localeconv.c
> +++ b/tests/test-localeconv.c
> @@ -37,15 +37,11 @@ main ()
>
> ASSERT (STREQ (l->decimal_point, "."));
> ASSERT (STREQ (l->thousands_sep, ""));
> -#if !(defined __FreeBSD__ || defined __sun)
> -ASSERT (STREQ (l->grouping, ""));
> -#endif
> +ASSERT (l->grouping[0] == CHAR_MAX || STREQ (l->grouping, ""));
>
> ASSERT (STREQ (l->mon_decimal_point, ""));
> ASSERT (STREQ (l->mon_thousands_sep, ""));
> -#if !(defined __FreeBSD__ || defined __sun)
> -ASSERT (STREQ (l->mon_grouping, ""));
> -#endif
> +ASSERT (l->mon_grouping[0] == CHAR_MAX || STREQ (l->mon_grouping, ""));
> ASSERT (STREQ (l->positive_sign, ""));
> ASSERT (STREQ (l->negative_sign, ""));
>
> -Ed
Re: Add hash_pjw_s(), 3rd attempt
On 09/27/2012 10:19 PM, Nikos Mavrogiannopoulos wrote: > Updated. Hello, Any update on that? Do you plan to include it? regards, Nikos
Re: Add hash_pjw_s(), 3rd attempt
Nikos Mavrogiannopoulos wrote: > On 09/27/2012 10:19 PM, Nikos Mavrogiannopoulos wrote: > >> Updated. > Any update on that? Do you plan to include it? Yes, I'll apply it shortly. Thanks.
Re: Add hash_pjw_s(), 3rd attempt
Nikos Mavrogiannopoulos wrote: > On 09/27/2012 10:19 PM, Nikos Mavrogiannopoulos wrote: >> Updated. > > Hello, > Any update on that? Do you plan to include it? Hi Nikos, I went to deal with the mechanics of adding it and noticed a few details. What do you think about hash_pjw_no_mod or hash_pjw_bare as the function name? They convey more meaning than the "_s" suffix. Also, please make it look like other new-module commits. I.e., - list the module name in MODULES.html.sh - make the first line of the commit log be "new-module-name: new module" - add a ChangeLog entry extra credit: - add a test module, even though there isn't one for hash-pjw
Re: diffutils test failure on nixos/hydra's solaris build
On 1 October 2012 13:48, Jim Meyering wrote:
> Ed Maste wrote:
>
>> On 30 September 2012 17:39, Bruno Haible wrote:
>>> Jim Meyering wrote on 2012-08-28:
FAIL: test-localeconv (exit: 262)
=
test-localeconv.c:41: assertion failed
which corresponds to this line:
$ cat -n tests/test-localeconv.c|grep -B6 41
35{
36 struct lconv *l = localeconv ();
37
38 ASSERT (STREQ (l->decimal_point, "."));
39 ASSERT (STREQ (l->thousands_sep, ""));
40 #if !defined __FreeBSD__
41 ASSERT (STREQ (l->grouping, ""));
>>>
>>> It's easy to work around the failure. Since that particular test
>>> is already exempted on FreeBSD, it's not a big deal to also disable
>>> it on Solaris 11.
>>
>> For FreeBSD specifically I'd rather conclude either that this is a bug
>> in our localeconv and fix it, or that more than one value for
>> l->grouping is permissible and change the test. I've raised a FreeBSD
>> pr for this: http://www.freebsd.org/cgi/query-pr.cgi?pr=172215 since
>> it looks to me like the most recent standards suggest grouping should
>> be "" rather than "\177".
>>
>> That said, the test passes for me with the following change:
>
> Thanks for the patch!
> Dare I ask? ;-) Did you try it on Solaris 11?
> If not, I will get to it.
Sorry, I meant to mention that - no, I did not test it on Solaris.
-Ed
Problem with new release target in maint.mk
I get the following error while trying to make a GNU Zile release: /bin/bash: -c: line 1: syntax error near unexpected token `then' /bin/bash: -c: line 1: `@if test -d ../release; then\' make[2]: *** [release-prep] Error 1 I'm using bash 4.2.24(1)-release as shipped with Ubuntu 12.04. /bin/sh is dash 0.5.7. (I am slightly unclear why the error above is from bash, not dash…) -- http://rrt.sc3d.org
Re: Problem with new release target in maint.mk
Reuben Thomas wrote: > I get the following error while trying to make a GNU Zile release: > > /bin/bash: -c: line 1: syntax error near unexpected token `then' > /bin/bash: -c: line 1: `@if test -d ../release; then \' > make[2]: *** [release-prep] Error 1 > > I'm using bash 4.2.24(1)-release as shipped with Ubuntu 12.04. /bin/sh > is dash 0.5.7. (I am slightly unclear why the error above is from > bash, not dash…) Hi Reuben, Are you sure you're using the latest? There have been a few changes in that code recently. I've just tried this (after temporarily removing the previous make -s announcement command): make V=1 release-prep RELEASE_TYPE=stable and it worked fine. For the record, now that rule starts like this: .PHONY: release-prep release-prep: $(AM_V_GEN)$(MAKE) --no-print-directory -s announcement \ > ~/announce-$(my_distdir) $(AM_V_at)if test -d $(release_archive_dir); then \ ln $(rel-files) $(release_archive_dir); \ chmod a-w $(rel-files); \ fi
Re: Problem with new release target in maint.mk
On 1 October 2012 20:37, Jim Meyering wrote: > Reuben Thomas wrote: >> I get the following error while trying to make a GNU Zile release: >> >> /bin/bash: -c: line 1: syntax error near unexpected token `then' >> /bin/bash: -c: line 1: `@if test -d ../release; then \' >> make[2]: *** [release-prep] Error 1 >> >> I'm using bash 4.2.24(1)-release as shipped with Ubuntu 12.04. /bin/sh >> is dash 0.5.7. (I am slightly unclear why the error above is from >> bash, not dash…) > > Hi Reuben, > > Are you sure you're using the latest? $ cd gnulib /home/rrt/Software/zile-stable/gnulib $ git pull Already up-to-date. > For the record, now that rule starts like this: > > .PHONY: release-prep > release-prep: > $(AM_V_GEN)$(MAKE) --no-print-directory -s announcement \ > > ~/announce-$(my_distdir) > $(AM_V_at)if test -d $(release_archive_dir); then \ > ln $(rel-files) $(release_archive_dir); \ > chmod a-w $(rel-files); \ > fi I don't think it can be that, because that's not line 1. I think it's the rule for writable-files: writable-files: $(AM_V_GEN)if test -d $(release_archive_dir); then \ for file in $(DIST_ARCHIVES); do \ for p in ./ $(release_archive_dir)/; do \ -- http://rrt.sc3d.org
Re: Problem with new release target in maint.mk
Wait, I got it. I managed to splice two lines that shouldn't be spliced when making a small edit to maint.mk. Sorry for the noise. -- http://rrt.sc3d.org
Re: Problem with new release target in maint.mk
Reuben Thomas wrote: > On 1 October 2012 20:37, Jim Meyering wrote: >> Reuben Thomas wrote: >>> I get the following error while trying to make a GNU Zile release: >>> >>> /bin/bash: -c: line 1: syntax error near unexpected token `then' >>> /bin/bash: -c: line 1: `@if test -d ../release; then \' >>> make[2]: *** [release-prep] Error 1 >>> >>> I'm using bash 4.2.24(1)-release as shipped with Ubuntu 12.04. /bin/sh >>> is dash 0.5.7. (I am slightly unclear why the error above is from >>> bash, not dash…) >> >> Hi Reuben, >> >> Are you sure you're using the latest? > > $ cd gnulib > /home/rrt/Software/zile-stable/gnulib > $ git pull > Already up-to-date. > >> For the record, now that rule starts like this: >> >> .PHONY: release-prep >> release-prep: >> $(AM_V_GEN)$(MAKE) --no-print-directory -s announcement \ >> > ~/announce-$(my_distdir) >> $(AM_V_at)if test -d $(release_archive_dir); then \ >> ln $(rel-files) $(release_archive_dir); \ >> chmod a-w $(rel-files); \ >> fi > > I don't think it can be that, because that's not line 1. I think it's > the rule for writable-files: Glad you solved the problem and that it's not with any version in git. For future reference, the "*** [release-prep]" part of the diagnostic you included above says that "release-prep" is the rule that failed. > writable-files: > $(AM_V_GEN)if test -d $(release_archive_dir); then \ > for file in $(DIST_ARCHIVES); do \ > for p in ./ $(release_archive_dir)/; do \
[PATCH] set SO_REUSE* before bind(), not after
While investigating skipped tests on FreeBSD I found that test-poll
and test-select were skipped due to bind() returning EADDRINUSE. It
turns out that these tests call setsockopt(..., SO_REUSE... after
calling bind(), not before.
diff --git a/tests/test-poll.c b/tests/test-poll.c
index 7ba0280..69a30f0 100644
--- a/tests/test-poll.c
+++ b/tests/test-poll.c
@@ -96,6 +96,9 @@ open_server_socket ()
s = socket (AF_INET, SOCK_STREAM, 0);
+ x = 1;
+++ b/tests/test-poll.c
@@ -96,6 +96,9 @@ open_server_socket ()
s = socket (AF_INET, SOCK_STREAM, 0);
+ x = 1;
+ setsockopt (s, SOL_SOCKET, SO_REUSEPORT, &x, sizeof (x));
+
memset (&ia, 0, sizeof (ia));
ia.sin_family = AF_INET;
inet_pton (AF_INET, "127.0.0.1", &ia.sin_addr);
@@ -106,9 +109,6 @@ open_server_socket ()
exit (77);
}
- x = 1;
- setsockopt (s, SOL_SOCKET, SO_REUSEPORT, &x, sizeof (x));
-
if (listen (s, 1) < 0)
{
perror ("listen");
diff --git a/tests/test-select.h b/tests/test-select.h
index 1169e59..af0e38c 100644
--- a/tests/test-select.h
+++ b/tests/test-select.h
@@ -84,6 +84,9 @@ open_server_socket (void)
s = socket (AF_INET, SOCK_STREAM, 0);
+ x = 1;
+ setsockopt (s, SOL_SOCKET, SO_REUSEPORT, &x, sizeof (x));
+
memset (&ia, 0, sizeof (ia));
ia.sin_family = AF_INET;
inet_pton (AF_INET, "127.0.0.1", &ia.sin_addr);
@@ -94,9 +97,6 @@ open_server_socket (void)
exit (77);
}
Re: Problem with new release target in maint.mk
On 10/01/2012 02:03 PM, Reuben Thomas wrote: > On 1 October 2012 20:37, Jim Meyering wrote: >> Reuben Thomas wrote: >>> I get the following error while trying to make a GNU Zile release: >>> >>> /bin/bash: -c: line 1: syntax error near unexpected token `then' >>> /bin/bash: -c: line 1: `@if test -d ../release; then \' >>> make[2]: *** [release-prep] Error 1 >>> >>> I'm using bash 4.2.24(1)-release as shipped with Ubuntu 12.04. /bin/sh >>> is dash 0.5.7. (I am slightly unclear why the error above is from >>> bash, not dash…) Probably because SHELL is set in your makefile to point to /bin/bash based on what shell configure used, and that in turn is probably because your /bin/sh (presumably dash) lacked something that configure wanted to use (the most common problem here is that older dash lacked $LINENO support). But you'd have to check your config.log to be sure. >> release-prep: >> $(AM_V_GEN)$(MAKE) --no-print-directory -s announcement \ >> > ~/announce-$(my_distdir) >> $(AM_V_at)if test -d $(release_archive_dir); then \ >> ln $(rel-files) $(release_archive_dir); \ >> chmod a-w $(rel-files); \ >> fi > > I don't think it can be that, because that's not line 1. Yes it is. Remember that in make, each line that is not a continuation of the previous line is fed to a new '$SHELL -c' instance, and therefore, there are TWO 'line 1' locations within the release-prep rule, because there are two shells spawned. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Problem with new release target in maint.mk
On 1 October 2012 22:49, Eric Blake wrote: > therefore, there are TWO 'line 1' locations within the release-prep > rule, because there are two shells spawned. Didn't spot the lack of continuation, which, as it turned out, was precisely the opposite of the bug I'd introduced. I must be backslash-blind :-\ -- http://rrt.sc3d.org
Re: [PATCH] set SO_REUSE* before bind(), not after
Hi,
Ed Maste wrote:
> While investigating skipped tests on FreeBSD I found that test-poll
> and test-select were skipped due to bind() returning EADDRINUSE. It
> turns out that these tests call setsockopt(..., SO_REUSE... after
> calling bind(), not before.
You're obviously right. SO_REUSEADDR can have no effect if it comes
after the bind() call.
The patch you attached was syntactically malformed. I committed this
one in your name; I hope it is what you meant.
The "tiny change" marker means "small enough to not require the exchange
of legal paperwork". Feel free to report more bugs like this, that you find!
2012-10-01 Ed Maste(tiny change)
select, poll tests: Make setsockopt invocation effective.
* tests/test-poll.c (open_server_socket): Move setsockopt() call before
the bind() call.
* tests/test-select.h (open_server_socket): Likewise.
--- tests/test-poll.c.orig Tue Oct 2 01:48:04 2012
+++ tests/test-poll.c Tue Oct 2 01:43:34 2012
@@ -96,6 +96,9 @@
s = socket (AF_INET, SOCK_STREAM, 0);
+ x = 1;
+ setsockopt (s, SOL_SOCKET, SO_REUSEPORT, &x, sizeof (x));
+
memset (&ia, 0, sizeof (ia));
ia.sin_family = AF_INET;
inet_pton (AF_INET, "127.0.0.1", &ia.sin_addr);
@@ -106,9 +109,6 @@
exit (77);
}
- x = 1;
- setsockopt (s, SOL_SOCKET, SO_REUSEPORT, &x, sizeof (x));
-
if (listen (s, 1) < 0)
{
perror ("listen");
--- tests/test-select.h.origTue Oct 2 01:48:05 2012
+++ tests/test-select.h Tue Oct 2 01:44:07 2012
@@ -84,6 +84,9 @@
s = socket (AF_INET, SOCK_STREAM, 0);
+ x = 1;
+ setsockopt (s, SOL_SOCKET, SO_REUSEPORT, &x, sizeof (x));
+
memset (&ia, 0, sizeof (ia));
ia.sin_family = AF_INET;
inet_pton (AF_INET, "127.0.0.1", &ia.sin_addr);
@@ -94,9 +97,6 @@
exit (77);
}
- x = 1;
- setsockopt (s, SOL_SOCKET, SO_REUSEPORT, &x, sizeof (x));
-
if (listen (s, 1) < 0)
{
perror ("listen");
Re: [PATCH] set SO_REUSE* before bind(), not after
On 1 October 2012 19:52, Bruno Haible wrote: > Hi, > > Ed Maste wrote: >> While investigating skipped tests on FreeBSD I found that test-poll >> and test-select were skipped due to bind() returning EADDRINUSE. It >> turns out that these tests call setsockopt(..., SO_REUSE... after >> calling bind(), not before. > > You're obviously right. SO_REUSEADDR can have no effect if it comes > after the bind() call. > > The patch you attached was syntactically malformed. I committed this > one in your name; I hope it is what you meant. Yes, that's what I meant - sorry about the mixed up patch. I'm not exactly sure how it happened - I'll double-check submissions in the future. > Feel free to report more bugs like this, that you find! Absolutely, although 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.
Re: diffutils test failure on nixos/hydra's solaris build
Hi Ed, > For FreeBSD specifically I'd rather conclude either that this is a bug > in our localeconv and fix it, or that more than one value for > l->grouping is permissible and change the test. Looking at http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html section 7.3.4, subsection "LC_NUMERIC Category in the POSIX Locale", there is a table ┌┬───┬──┬──┬───┐ ││ langinfo │ POSIX Locale │ localeconv() │ localedef │ ├┼───┼──┼──┼───┤ │ Item │ Constant │Value │Value │ Value │ ├┼───┼──┼──┼───┤ │ decimal_point │ RADIXCHAR │ "." │ "." │ . │ ├┼───┼──┼──┼───┤ │ thousands_sep │ THOUSEP │ N/A │ "" │"" │ ├┼───┼──┼──┼───┤ │ grouping │ - │ N/A │ "" │-1 │ └┴───┴──┴──┴───┘ which clearly says that the 'grouping' value in localeconv() should be the empty string. > I've raised a FreeBSD > pr for this: http://www.freebsd.org/cgi/query-pr.cgi?pr=172215 since > it looks to me like the most recent standards suggest grouping should > be "" rather than "\177". Thanks! > That said, the test passes for me with the following change: > > --- a/tests/test-localeconv.c > +++ b/tests/test-localeconv.c > @@ -37,15 +37,11 @@ main () > > -#if !(defined __FreeBSD__ || defined __sun) > -ASSERT (STREQ (l->grouping, "")); > -#endif > +ASSERT (l->grouping[0] == CHAR_MAX || STREQ (l->grouping, "")); The intent of this test is also to document to what extent a gnulib user can rely on the POSIX specification. Once someone has tested it on OpenIndiana, I'd suggest to write this code this way: #if !(defined __FreeBSD__ || defined __sun) /* POSIX specifies that localeconv()->grouping is "" in the C locale. */ ASSERT (STREQ (l->grouping, "")); #else /* On some platforms, the value is different. */ ASSERT (STREQ (l->grouping, "") || l->grouping[0] == CHAR_MAX); #endif Bruno
Re: FreeBSD bugs
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.
alphasort
The parameters of this function are declared as @code{const void *} on some
platforms:
chown
Some platforms fail to detect trailing slash on non-directories, as in
@code{chown("link-to-file/",uid,gid)}:
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:
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:
fcntl
This function does not support @code{F_DUPFD_CLOEXEC} on some
platforms:
fdopendir
This function mistakenly closes non-directory file descriptors on some
platforms:
fflush
@code{fflush} on an input stream right after @code{ungetc} does not discard
the @code{ungetc} buffer, on some platforms:
fmaf
This function produces wrong results on some platforms:
fmal
This function produces wrong results on some platforms:
fma
This function produces wrong results on some platforms:
*printf
printf @code{"%010f"} of NaN and Infinity yields an incorrect result (padded
with zeroes) on some platforms:
This function can crash in out-of-memory conditions on some platforms:
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:
getgroups
On some platforms, this function fails to reject a negative count,
even though that is less than the size that would be returned:
lchown
Some platforms fail to detect trailing slash on non-directories, as in
@code{lchown("link-to-file/",uid,gid)}:
link
This function fails to reject trailing slashes on non-directories on
some platforms:
mkfifo
This function mishandles trailing slash on some platforms:
mknod
This function requires super-user privileges to create a fifo:
This function mishandles trailing slash on some platforms:
modf
This function has problems with infinite arguments on some platforms:
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:
perror
This function treats @code{errno} of 0 like failure, although POSIX
requires that the message declare it as a success, on some platforms:
pthread_sigmask
This function is declared in @code{} instead of @code{}
on some platforms:
This function does nothing and always returns 0 in programs that are not
linked with @code{-lpthread} on some platforms:
readlink
Some platforms mistakenly succeed on @code{readlink("link/",buf,len)}:
On some platforms, @code{readlink} returns @code{int} instead of
@code{ssize_t}:
realpath
This function does not allow for a NULL @samp{resolved} parameter on
some platforms:
remove
This function fails to reject trailing slashes on non-directories on
some platforms:
rename
This function does not reject trailing slashes on symlinks to
non-directories on some platforms, as in
@code{rename("link-to-file/","f")}:
scandir
The fourth parameter of this function is declared as @code{int (*) (const void
*, const void *)} on some platforms:
setenv
On some platforms, this function does not fail with @samp{EINVAL} when
passed an empty string or a string containing @samp{=}:
stat
On some platforms, @code{stat("link-to-file/",buf)} succeeds instead
of failing with @code{ENOTDIR}.
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:
strerror_r
This function reports failure for @code{strerror_r(0, buf, len)},
although POSIX requires this to succeed, on some platforms:
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:
strstr
This function has quadratic instead of linear worst-case complexity on some
platforms:
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:
symlink
On some systems, @code{symlink(value,"name/")} mistakenly creates a
symlink:
unlink
Some systems mistakenly succeed on @code{unlink("link-to-file/")}:
unsetenv
This function has the return type @samp{void} instead of @samp{int} on some
platforms:
On some platforms, this function does not fail with @samp{EINVAL} when
passed an empty string or a string containing @samp{=}:
utimes
On some platforms, this function
