[PATCH] renameat2: port better to macOS

[Paul Eggert]

* lib/renameat2.c (renameat2): Use renameatx_np if available.
---
 ChangeLog   |  3 +++
 lib/renameat2.c | 20 
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index bc0c16991..e4fe8dd61 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,8 @@
 2017-08-15  Paul Eggert  
 
+   renameat2: port better to macOS
+   * lib/renameat2.c (renameat2): Use renameatx_np if available.
+
futimens: don’t assume struct timespec layout
* m4/futimens.m4 (gl_FUNC_FUTIMENS):
* m4/utimensat.m4 (gl_FUNC_UTIMENSAT):
diff --git a/lib/renameat2.c b/lib/renameat2.c
index fd38a71e7..1e107fc50 100644
--- a/lib/renameat2.c
+++ b/lib/renameat2.c
@@ -74,12 +74,25 @@ int
 renameat2 (int fd1, char const *src, int fd2, char const *dst,
unsigned int flags)
 {
+  int ret_val = -1;
+  int err = EINVAL;
+
 #ifdef SYS_renameat2
-  int r = syscall (SYS_renameat2, fd1, src, fd2, dst, flags);
-  if (! (r < 0 && (errno == ENOSYS || errno == EINVAL)))
-return r;
+  ret_val = syscall (SYS_renameat2, fd1, src, fd2, dst, flags);
+  err = errno;
+#elif defined RENAME_EXCL
+  if (! (flags & ~(RENAME_EXCHANGE | RENAME_NOREPLACE)))
+{
+  ret_val = renameatx_np (fd1, src, fd2, dst,
+ ((flags & RENAME_EXCHANGE ? RENAME_SWAP : 0)
+  | (flags & RENAME_NOREPLACE ? RENAME_EXCL : 0)));
+  err = errno;
+}
 #endif
 
+  if (! (ret_val < 0 && (err == EINVAL || err == ENOSYS || err == ENOTSUP)))
+return ret_val;
+
 #if HAVE_RENAMEAT
   {
   size_t src_len;
@@ -88,7 +101,6 @@ renameat2 (int fd1, char const *src, int fd2, char const 
*dst,
   char *dst_temp = (char *) dst;
   bool src_slash;
   bool dst_slash;
-  int ret_val;
   int rename_errno = ENOTDIR;
   struct stat src_st;
   struct stat dst_st;
-- 
2.13.5

Re: test results on NetBSD 7.0

[Paul Eggert]

Bruno Haible wrote:

Test results of a Gnulib POSIX testdir on NetBSD 7.0:


Thanks for doing that. Although I don't know about the math problems, here are 
thoughts on the file-related issues.



FAIL: test-futimens
===

../../gltests/test-futimens.h:154: assertion 'ctime_compare (, ) < 0' 
failed
FAIL test-futimens (exit status: 134)>

> ...

FAIL: test-utimens
==

../../gltests/test-utimens.h:130: assertion 'ctime_compare (, ) < 0' 
failed
FAIL test-utimens (exit status: 134)


These two appear to because futimens and utimens are not properly marking the 
ctime for update after they change a file timestamp. If I'm right, it's a NetBSD 
bug that Gnulib cannot easily work around. It's just a guess, though.



FAIL: test-utimensat


../../gltests/test-utimens.h:71: assertion 'func (BASE "file", ts) == -1' failed
FAIL test-utimensat (exit status: 134)


This appears to be because utimensat is not failing with errno==EINVAL for 
tv_nsec values less than 0 or greater than 9 (and not UTIME_OMIT or 
UTIME_NOW). If I'm right it's a NetBSD bug that Gnulib could work around though 
this is low priority. It's just a guess, though.




FAIL: test-renameat
===

../../gltests/test-rename.h:525: assertion 'stat (BASE "file", ) == 0' failed
FAIL test-renameat (exit status: 134)

FAIL: test-renameat2



These appear to be because Gnulib tests are too strict about renameat. They 
should allow the NetBSD behavior, because it's better than the behavior that 
POSIX requires. I installed the first attached patch to try to fix this.


While looking into the utimensat problem I noticed a portability glitch that is 
unrelated to these NetBSD issues, and fixed that in the second attached patch. 
It's probably just theoretical.
From 9a6c7d3f6ea7c328e7760458b18fe6dfc6f8806f Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Tue, 15 Aug 2017 15:53:50 -0700
Subject: [PATCH 1/2] rename: document+test NetBSD rename

Test failure reported by Bruno Haible in:
http://lists.gnu.org/archive/html/bug-gnulib/2017-08/msg00104.html
This is an area where NetBSD is better-behaved than POSIX,
so allow the NetBSD behavior in tests.
* doc/posix-functions/rename.texi:
* doc/posix-functions/renameat.texi: Document NetBSD behavior.
* tests/test-rename.h (test_rename): Allow NetBSD behavior.
---
 ChangeLog | 11 +++
 doc/posix-functions/rename.texi   | 10 ++
 doc/posix-functions/renameat.texi | 10 ++
 tests/test-rename.h   |  8 +++-
 4 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index b07825f..3d87c90 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2017-08-15  Paul Eggert  
+
+	rename: document+test NetBSD rename
+	Test failure reported by Bruno Haible in:
+	http://lists.gnu.org/archive/html/bug-gnulib/2017-08/msg00104.html
+	This is an area where NetBSD is better-behaved than POSIX,
+	so allow the NetBSD behavior in tests.
+	* doc/posix-functions/rename.texi:
+	* doc/posix-functions/renameat.texi: Document NetBSD behavior.
+	* tests/test-rename.h (test_rename): Allow NetBSD behavior.
+
 2017-08-15  Bruno Haible  
 
 	renameat: Ensure declaration in  on NetBSD.
diff --git a/doc/posix-functions/rename.texi b/doc/posix-functions/rename.texi
index 1e80656..b024b96 100644
--- a/doc/posix-functions/rename.texi
+++ b/doc/posix-functions/rename.texi
@@ -60,6 +60,16 @@ is counter-intuitive, so on some systems, @code{rename} fails with
 @code{ENOTDIR} if either argument is a symlink with a trailing slash:
 glibc, OpenBSD, Cygwin 1.7.
 @item
+POSIX requires that @code{renameat} do nothing and return 0 if the
+source and destination are hard links to the same file.  This behavior
+is counterintuitive, and on some systems @code{renameat} is a no-op in
+this way only if the source and destination identify the same
+directory entry.  On these systems, for example, although renaming
+@file{./f} to @file{f} is a no-op, renaming @file{f} to @file{g}
+deletes @file{f} when @file{f} and @file{g} are hard links to the same
+file:
+NetBSD.
+@item
 After renaming a non-empty directory over an existing empty directory,
 the old directory name is still visible through the @code{stat} function
 for 30 seconds after the rename, on NFS file systems, on some platforms:
diff --git a/doc/posix-functions/renameat.texi b/doc/posix-functions/renameat.texi
index ee01b89..dd97132 100644
--- a/doc/posix-functions/renameat.texi
+++ b/doc/posix-functions/renameat.texi
@@ -39,6 +39,16 @@ is counter-intuitive, so on some systems, @code{renameat} fails with
 @code{ENOTDIR} if either argument is a symlink with a trailing slash:
 glibc, OpenBSD, Cygwin 1.7.
 @item
+POSIX requires that @code{renameat} do nothing and return 0 if the
+source and destination are hard links to the same file.  This behavior
+is counterintuitive, and on some 

Re: workaround against broken duplocale

[Joerg Sonnenberger]

On Tue, Aug 15, 2017 at 11:39:38PM +0200, Bruno Haible wrote:
> Hi Jörg,
> 
> Joerg Sonnenberger wrote:
> > uselocale() is fundamentally broken from a design perspective. It can't
> > be implemented without breaking ABIs.
> 
> Well, glibc did not break ABIs when it introduced uselocale() in 2002.
> If you have not exposed too many internals of the locale set by setlocale(),
> you shouldn't have any problems. And you have the __RENAME macro, to cope
> with these cases.

I don't know how glibc implemented e.g. ctype.h before. The classic way
to do it is providing a global masking table and that can't be switched
to support uselocale() without breaking the ABI or introducing wonderful
inconsistencies. The alternatives all depend on lying to the compiler or
taking a significant performance hit. The current glibc implementation
falls into the former category.

> > It breaks expectations of existing applications in funny ways
> 
> I would say, it breaks expectations of programmers who have not yet gotten
> familiar with the API. But existing applications - that do not invoke
> uselocale() - run without modifications and without change in behaviour.

This is not true. Before uselocale(), a library could assume that all
threads get consistent locale information if they ask at the same time.
Given that setlocale() can't normally be used in any sane way in a
multi-thread program, the "at the same time" is not really a
restriction. Now take a library that implements a parallel sort for
strings and is collation aware. The library provides the natural
optimization of not using threads on single CPU systems. Does
uselocale() affect the behavior of this library or not? Does it matter
if the library uses a static thread pool or not? This is a very common
pattern and one of the big reasons why C++ doesn't have thread-local
locales in the standard, but explicit locale objects.

The other point is that the far majority of use cases of uselocale()
I have seen so use it for switching to the "C" locale for some parsing
and back afterwards. It is sometimes hidden by a few layers of
indirection, but that's it. The rest is using it as fallback
implementation for lack of explicit locale functions, i.e. in STL.

> > and it is highly undesirable from a performance spective.
> 
> Why? If the locale is a single __thread variable (or a set of 6 __thread
> variables, if you prefer), it is just as fast as any __thread variable access.

Yes and __thread is slow on many platforms compared to a normal function
call or access to a global variable. Even on platforms where TLS access
is moderately fast, it can easily make common interfaces quite a bit
slower.

> > It is also by itself useless as building block as
> > pretty much any higher level runtime like C++ STL wants to have explicit
> > control over locales.
> 
> Before these functions were standardized, I would have agreed with you:
> that a decent object-oriented API for locale_t objects was the way to go,
> rather than these odd-to-use newlocale/duplocale APIs with non-extensible
> locale_t objects. But now the standard exists, and you do people a favour
> if you implement it.

I disagree. A lot. As I said above, real world code use supports my
position.

> > >   - duplocale(LC_GLOBAL_LOCALE) is broken.
> > 
> > I think this is a completely unrelated bug where thousand groupers were
> > handled incorrectly. Test certainly works on current.
> 
> I don't think it's the same as a thousand groupers bug:
>   - The number the test exercises comes out as "3.5" where "3,5" is expected.
>   - The month name comes out incorrectly as well.
>   - In the debugger, when I looked at the memory representation of
> duplocale(LC_GLOBAL_LOCALE), I saw a pointer to some C locale data
> followed by many NULL pointers.
> 
> But I'm pleased to hear that it will be fixed in NetBSD 8.

Hm. Could also be the protected issue. I had forgotten about that one.

Joerg

Re: workaround against broken duplocale

[Bruno Haible]

Hi Jörg,

Joerg Sonnenberger wrote:
> uselocale() is fundamentally broken from a design perspective. It can't
> be implemented without breaking ABIs.

Well, glibc did not break ABIs when it introduced uselocale() in 2002.
If you have not exposed too many internals of the locale set by setlocale(),
you shouldn't have any problems. And you have the __RENAME macro, to cope
with these cases.

> It breaks expectations of existing applications in funny ways

I would say, it breaks expectations of programmers who have not yet gotten
familiar with the API. But existing applications - that do not invoke
uselocale() - run without modifications and without change in behaviour.

> and it is highly undesirable from a performance spective.

Why? If the locale is a single __thread variable (or a set of 6 __thread
variables, if you prefer), it is just as fast as any __thread variable access.

> It is also by itself useless as building block as
> pretty much any higher level runtime like C++ STL wants to have explicit
> control over locales.

Before these functions were standardized, I would have agreed with you:
that a decent object-oriented API for locale_t objects was the way to go,
rather than these odd-to-use newlocale/duplocale APIs with non-extensible
locale_t objects. But now the standard exists, and you do people a favour
if you implement it.

> > And on top of that, in NetBSD 7.0,
> >   - strfmon_l is not implemented,
> 
> This one slipped through. I did a full audit for any locale-sensitive
> function, but that one I missed. Thanks for finding it :)

FYI, here's the list of symbols from a Mac OS X 10.5 systems that end in '_l':

asprintf_l
atof_l
atoi_l
atol_l
atoll_l
btowc_l
digittoint_l
fgetwc_l
fgetws_l
fprintf_l
fputwc_l
fputws_l
fscanf_l
fwprintf_l
fwscanf_l
getwc_l
getwchar_l
isalnum_l
isalpha_l
isblank_l
iscntrl_l
isdigit_l
isgraph_l
ishexnumber_l
isideogram_l
islower_l
isnumber_l
isphonogram_l
isprint_l
ispunct_l
isrune_l
isspace_l
isspecial_l
isupper_l
iswalnum_l
iswalpha_l
iswblank_l
iswcntrl_l
iswctype_l
iswdigit_l
iswgraph_l
iswhexnumber_l
iswideogram_l
iswlower_l
iswnumber_l
iswphonogram_l
iswprint_l
iswpunct_l
iswrune_l
iswspace_l
iswspecial_l
iswupper_l
iswxdigit_l
isxdigit_l
localeconv_l
mblen_l
mbrlen_l
mbrtowc_l
mbsinit_l
mbsnrtowcs_l
mbsrtowcs_l
mbstowcs_l
mbtowc_l
nextwctype_l
nl_langinfo_l
printf_l
putwc_l
putwchar_l
scanf_l
snprintf_l
sprintf_l
sscanf_l
strcasecmp_l
strcasestr_l
strcoll_l
strfmon_l
strftime_l
strncasecmp_l
strptime_l
strtod_l
strtof_l
strtoimax_l
strtol_l
strtold_l
strtoll_l
strtoq_l
strtoul_l
strtoull_l
strtoumax_l
strtouq_l
strxfrm_l
swprintf_l
swscanf_l
tolower_l
toupper_l
towctrans_l
towlower_l
towupper_l
ungetwc_l
vasprintf_l
vfprintf_l
vfscanf_l
vfwprintf_l
vfwscanf_l
vprintf_l
vscanf_l
vsnprintf_l
vsprintf_l
vsscanf_l
vswprintf_l
vswscanf_l
vwprintf_l
vwscanf_l
wcrtomb_l
wcscoll_l
wcsftime_l
wcsnrtombs_l
wcsrtombs_l
wcstod_l
wcstof_l
wcstoimax_l
wcstol_l
wcstold_l
wcstoll_l
wcstombs_l
wcstoul_l
wcstoull_l
wcstoumax_l
wcswidth_l
wcsxfrm_l
wctob_l
wctomb_l
wctrans_l
wctype_l
wcwidth_l
wprintf_l
wscanf_l

> >   - duplocale(LC_GLOBAL_LOCALE) is broken.
> 
> I think this is a completely unrelated bug where thousand groupers were
> handled incorrectly. Test certainly works on current.

I don't think it's the same as a thousand groupers bug:
  - The number the test exercises comes out as "3.5" where "3,5" is expected.
  - The month name comes out incorrectly as well.
  - In the debugger, when I looked at the memory representation of
duplocale(LC_GLOBAL_LOCALE), I saw a pointer to some C locale data
followed by many NULL pointers.

But I'm pleased to hear that it will be fixed in NetBSD 8.

Bruno

test results on NetBSD 7.0

[Bruno Haible]

Test results of a Gnulib POSIX testdir on NetBSD 7.0:


1) On both x86 and x86_64

FAIL: test-exp2l


../../gltests/test-exp2.h:50: assertion 'z == y' failed
FAIL test-exp2l (exit status: 134)

FAIL: test-expm1l
=

../../gltests/test-expm1.h:80: assertion 'err > - err_bound / TWO_MANT_DIG && 
err < err_bound / TWO_MANT_DIG' failed
FAIL test-expm1l (exit status: 134)

FAIL: test-futimens
===

../../gltests/test-futimens.h:154: assertion 'ctime_compare (, ) < 0' 
failed
FAIL test-futimens (exit status: 134)

FAIL: test-log10l
=

../../gltests/test-log10.h:68: assertion 'err > - err_bound / TWO_MANT_DIG && 
err < err_bound / TWO_MANT_DIG' failed
FAIL test-log10l (exit status: 134)

FAIL: test-log1pl
=

../../gltests/test-log1p.h:64: assertion 'err > - err_bound / TWO_MANT_DIG && 
err < err_bound / TWO_MANT_DIG' failed
FAIL test-log1pl (exit status: 134)

FAIL: test-log2l


../../gltests/test-log2.h:95: assertion 'err > - err_bound / TWO_MANT_DIG && 
err < err_bound / TWO_MANT_DIG' failed
FAIL test-log2l (exit status: 134)

FAIL: test-logl
===

../../gltests/test-log.h:68: assertion 'err > - err_bound / TWO_MANT_DIG && err 
< err_bound / TWO_MANT_DIG' failed
FAIL test-logl (exit status: 134)

FAIL: test-mkfifoat
===

../../gltests/test-mkfifo.h:36: assertion 'result == 0' failed
FAIL test-mkfifoat (exit status: 134)

FAIL: test-poll
===

Unconnected socket test... passed
Connected sockets test... failed (expecting POLLHUP after shutdown)
General socket test with fork... failed (expecting POLLHUP after shutdown)
Pipe test... passed
FAIL test-poll (exit status: 2)

FAIL: test-ptsname_r


../../gltests/test-ptsname_r.c:83: assertion 'result == errno' failed
FAIL test-ptsname_r (exit status: 134)

FAIL: test-renameat
===

../../gltests/test-rename.h:525: assertion 'stat (BASE "file", ) == 0' failed
FAIL test-renameat (exit status: 134)

FAIL: test-renameat2


../../gltests/test-rename.h:525: assertion 'stat (BASE "file", ) == 0' failed
FAIL test-renameat2 (exit status: 134)

FAIL: test-rintl


../../gltests/test-rintl.c:81: assertion 'rintl (-0.3L) == 0.0L' failed
FAIL test-rintl (exit status: 134)

FAIL: test-utimens
==

../../gltests/test-utimens.h:130: assertion 'ctime_compare (, ) < 0' 
failed
FAIL test-utimens (exit status: 134)

FAIL: test-utimensat


../../gltests/test-utimens.h:71: assertion 'func (BASE "file", ts) == -1' failed
FAIL test-utimensat (exit status: 134)



2) On x86

FAIL: test-expl
===

../../gltests/test-exp.h:82: assertion 'err > - err_bound / TWO_MANT_DIG && err 
< err_bound / TWO_MANT_DIG' failed
FAIL test-expl (exit status: 134)



3) On x86_64

FAIL: test-expl
===

../../gltests/test-exp.h:58: assertion 'err > - err_bound / TWO_MANT_DIG && err 
< err_bound / TWO_MANT_DIG' failed
FAIL test-expl (exit status: 134)

renameat declaration on NetBSD 7.0

[Bruno Haible]

On NetBSD 7.0, I'm seeing this test compilation failure:

gcc -std=gnu99 -DHAVE_CONFIG_H -DEXEEXT=\"\" -I. -I../../gltests -I..  
-DGNULIB_STRICT_CHECKING=1 -DIN_GNULIB_TESTS=1 -I. -I../../gltests -I.. 
-I../../gltests/.. -I../gllib -I../../gltests/../gllib -I/home/bruno/include 
-Wall -D_XOPEN_SOURCE=500  -g -O2 -MT test-renameat.o -MD -MP -MF $depbase.Tpo 
-c -o test-renameat.o ../../gltests/test-renameat.c &&\
mv -f $depbase.Tpo $depbase.Po
In file included from ../../gltests/test-renameat.c:23:0:
../../gltests/test-renameat.c:24:18: error: 'renameat' undeclared here (not in 
a function)
 SIGNATURE_CHECK (renameat, int, (int, char const *, int, char const *));
  ^
../../gltests/signature.h:46:58: note: in definition of macro 'SIGNATURE_CHECK2'
   static ret (* _GL_UNUSED signature_check ## id) args = fn
  ^
../../gltests/signature.h:39:3: note: in expansion of macro 'SIGNATURE_CHECK1'
   SIGNATURE_CHECK1 (fn, ret, args, __LINE__)
   ^
../../gltests/test-renameat.c:24:1: note: in expansion of macro 
'SIGNATURE_CHECK'
 SIGNATURE_CHECK (renameat, int, (int, char const *, int, char const *));
 ^
Makefile:8106: recipe for target 'test-renameat.o' failed


This patch fixes it.


2017-08-15  Bruno Haible  

renameat: Ensure declaration in  on NetBSD.
* lib/stdio.in.h: Include  also on NetBSD.
* doc/posix-functions/renameat.texi: Mention this problem.

diff --git a/doc/posix-functions/renameat.texi 
b/doc/posix-functions/renameat.texi
index 46b25b1..ee01b89 100644
--- a/doc/posix-functions/renameat.texi
+++ b/doc/posix-functions/renameat.texi
@@ -19,7 +19,7 @@ Solaris 9.
 @item
 This function is declared in @code{} instead of @code{}
 on some platforms:
-Solaris 11 2011-11.
+NetBSD 7.0, Solaris 11 2011-11.
 @item
 This function is missing on some platforms:
 glibc 2.3.6, Mac OS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8,
diff --git a/lib/stdio.in.h b/lib/stdio.in.h
index 5329b9d..5ca8a23 100644
--- a/lib/stdio.in.h
+++ b/lib/stdio.in.h
@@ -111,9 +111,9 @@
 #define _GL_ATTRIBUTE_FORMAT_SCANF_SYSTEM(formatstring_parameter, 
first_argument) \
   _GL_ATTRIBUTE_FORMAT ((__scanf__, formatstring_parameter, first_argument))
 
-/* Solaris 10 declares renameat in , not in .  */
+/* Solaris 10 and NetBSD 7.0 declare renameat in , not in . 
 */
 /* But in any case avoid namespace pollution on glibc systems.  */
-#if (@GNULIB_RENAMEAT@ || defined GNULIB_POSIXCHECK) && defined __sun \
+#if (@GNULIB_RENAMEAT@ || defined GNULIB_POSIXCHECK) && (defined __sun || 
defined __NetBSD__) \
 && ! defined __GLIBC__
 # include 
 #endif

Re: workaround against broken duplocale

[Joerg Sonnenberger]

On Tue, Aug 15, 2017 at 09:28:26PM +0200, Bruno Haible wrote:
> Which is pretty senseless, since it forces programs to use functions that take
> an explicit locale argument (fprintf_l, strfmon_l, and similar). The point
> of standardizing duplocale(), newlocale(), uselocale() was to *eliminate*
> the need for these non-standard *_l functions.

uselocale() is fundamentally broken from a design perspective. It can't
be implemented without breaking ABIs. It breaks expectations of existing
applications in funny ways and it is highly undesirable from a
performance spective. It is also by itself useless as building block as
pretty much any higher level runtime like C++ STL wants to have explicit
control over locales.

> And on top of that, in NetBSD 7.0,
>   - strfmon_l is not implemented,

This one slipped through. I did a full audit for any locale-sensitive
function, but that one I missed. Thanks for finding it :)

>   - duplocale(LC_GLOBAL_LOCALE) is broken.

I think this is a completely unrelated bug where thousand groupers were
handled incorrectly. Test certainly works on current.

Joerg

workaround against broken duplocale

[Bruno Haible]

Hi,

Running a gnulib testdir on NetBSD, I'm seeing a link error for test-duplocale.
This is due to the fact that the NetBSD people implemented duplocale() without
uselocale().
  https://mail-index.netbsd.org/tech-userlevel/2013/04/23/msg007714.html
Which is pretty senseless, since it forces programs to use functions that take
an explicit locale argument (fprintf_l, strfmon_l, and similar). The point
of standardizing duplocale(), newlocale(), uselocale() was to *eliminate*
the need for these non-standard *_l functions.

And on top of that, in NetBSD 7.0,
  - strfmon_l is not implemented,
  - duplocale(LC_GLOBAL_LOCALE) is broken.

I'm committing these workarounds:
  1) Extend the duplocale unit test so that it does meaningful tests even when
 uselocale() is not defined. Verified to work on glibc and macOS systems.
  2) Extend the duplocale autoconf test to recognize the broken behaviour on
 NetBSD.

@ Jörg Sonnenberger: Find attached a program (netbsd7-bug.c) that exhibits
the bug. Its exit code on NetBSD 7.0 is 2. The correct exit code is 0.

Bruno

>From a71158abf562cd6ed3fe384b0d99cba0de2034c2 Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Tue, 15 Aug 2017 20:23:00 +0200
Subject: [PATCH 1/2] duplocale tests: Verify use with *_l functions.

* modules/duplocale-tests (configure.ac): Test for uselocale and
some *_l functions.
* tests/test-duplocale.c (test_with_uselocale): New function, extracted
from main.
(get_locale_dependent_values_from, test_with_locale_parameter): New
functions.
(main): Test both test_with_uselocale and test_with_locale_parameter.
---
 ChangeLog   |  11 +
 modules/duplocale-tests |   2 +-
 tests/test-duplocale.c  | 111 +---
 3 files changed, 117 insertions(+), 7 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index b23b295..5791694 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,16 @@
 2017-08-15  Bruno Haible  
 
+	duplocale tests: Verify use with *_l functions.
+	* modules/duplocale-tests (configure.ac): Test for uselocale and
+	some *_l functions.
+	* tests/test-duplocale.c (test_with_uselocale): New function, extracted
+	from main.
+	(get_locale_dependent_values_from, test_with_locale_parameter): New
+	functions.
+	(main): Test both test_with_uselocale and test_with_locale_parameter.
+
+2017-08-15  Bruno Haible  
+
 	extensions: Enable NetBSD specific extensions.
 	* m4/extensions.m4 (AC_USE_SYSTEM_EXTENSIONS): Define _NETBSD_SOURCE.
 
diff --git a/modules/duplocale-tests b/modules/duplocale-tests
index 9cd9d44..3420abf 100644
--- a/modules/duplocale-tests
+++ b/modules/duplocale-tests
@@ -7,7 +7,7 @@ Depends-on:
 langinfo
 
 configure.ac:
-AC_CHECK_FUNCS_ONCE([duplocale])
+AC_CHECK_FUNCS_ONCE([duplocale uselocale strfmon_l snprintf_l nl_langinfo_l])
 AC_CHECK_HEADERS([monetary.h])
 
 Makefile.am:
diff --git a/tests/test-duplocale.c b/tests/test-duplocale.c
index 0db1513..ba3ab09 100644
--- a/tests/test-duplocale.c
+++ b/tests/test-duplocale.c
@@ -52,8 +52,10 @@ get_locale_dependent_values (struct locale_dependent_values *result)
   /* result->time is usually "janvier" */
 }
 
-int
-main ()
+#if HAVE_USELOCALE
+
+static int
+test_with_uselocale (void)
 {
   struct locale_dependent_values expected_results;
   locale_t mixed1;
@@ -73,10 +75,7 @@ main ()
   /* Use a per-thread locale.  */
   perthread = newlocale (LC_ALL_MASK, "es_ES.UTF-8", NULL);
   if (perthread == NULL)
-{
-  fprintf (stderr, "Skipping test: Spanish Unicode locale is not installed\n");
-  return 77;
-}
+return 1;
   uselocale (perthread);
 
   /* Save the locale in a locale_t object again.  */
@@ -122,6 +121,106 @@ main ()
   return 0;
 }
 
+#endif
+
+#if HAVE_STRFMON_L || HAVE_SNPRINTF_L || HAVE_NL_LANGINFO_L
+
+static void
+get_locale_dependent_values_from (struct locale_dependent_values *result, locale_t locale)
+{
+#if HAVE_STRFMON_L
+  strfmon_l (result->monetary, sizeof (result->monetary), locale,
+ "%n", 123.75);
+  /* result->monetary is usually "$123.75" */
+#endif
+#if HAVE_SNPRINTF_L
+  snprintf_l (result->numeric, sizeof (result->numeric), locale,
+  "%g", 3.5);
+  /* result->numeric is usually "3,5" */
+#endif
+#if HAVE_NL_LANGINFO_L
+  strcpy (result->time, nl_langinfo_l (MON_1, locale));
+  /* result->time is usually "janvier" */
+#endif
+}
+
+static int
+test_with_locale_parameter (void)
+{
+  struct locale_dependent_values expected_results;
+  locale_t mixed1;
+  locale_t mixed2;
+
+  /* Set up a locale which is a mix between different system locales.  */
+  setlocale (LC_ALL, "en_US.UTF-8");
+  setlocale (LC_NUMERIC, "de_DE.UTF-8");
+  setlocale (LC_TIME, "fr_FR.UTF-8");
+  get_locale_dependent_values (_results);
+
+  /* Save the locale in a locale_t object.  */
+  mixed1 = duplocale (LC_GLOBAL_LOCALE);
+  ASSERT (mixed1 != NULL);
+
+  /* Create another locale_t object.  */
+  mixed2 = newlocale (LC_ALL_MASK, "es_ES.UTF-8", 

Re: O_NOFOLLOW on NetBSD

[Bruno Haible]

Paul Eggert wrote:
> https://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/sys/featuretest.h
> 
> says that defining _NETBSD_SOURCE should be helpful only if _ANSI_SOURCE, 
> _POSIX_SOURCE, _POSIX_C_SOURCE, or _XOPEN_SOURCE is defined. I suppose it 
> shouldn't hurt to define _NETBSD_SOURCE, to handle these (presumably rare) 
> configurations.

Yes, I agree. Our 'extensions' module does not define any of
_ANSI_SOURCE, _POSIX_SOURCE, _POSIX_C_SOURCE, or _XOPEN_SOURCE on NetBSD
(I checked it with NetBSD 7.0), therefore with the default CFLAGS and CPPFLAGS
this patch is a no-op. But when someone uses -D_XOPEN_SOURCE=500 or something
like that, gnulib would not operate properly without -D_NETBSD_SOURCE:
configure produces wrong findings for REPLACE_FCNTL, REPLACE_FSTATAT,
REPLACE_DUPLOCALE, REPLACE_RENAMEAT, HAVE_COPYSIGN, REPLACE_SYMLINKAT,
REPLACE_LINKAT, REPLACE_FCHOWNAT, REPLACE_UNSETENV, REPLACE_PTSNAME_R,
and so on.


2017-08-15  Bruno Haible  

extensions: Enable NetBSD specific extensions.
* m4/extensions.m4 (AC_USE_SYSTEM_EXTENSIONS): Define _NETBSD_SOURCE.

diff --git a/m4/extensions.m4 b/m4/extensions.m4
index 0c16bb8..f854338 100644
--- a/m4/extensions.m4
+++ b/m4/extensions.m4
@@ -1,4 +1,4 @@
-# serial 16  -*- Autoconf -*-
+# serial 17  -*- Autoconf -*-
 # Enable extensions on systems that normally disable them.
 
 # Copyright (C) 2003, 2006-2017 Free Software Foundation, Inc.
@@ -68,6 +68,10 @@ dnl configure.ac when using autoheader 2.62.
 #ifndef _GNU_SOURCE
 # undef _GNU_SOURCE
 #endif
+/* Enable NetBSD extensions on NetBSD.  */
+#ifndef _NETBSD_SOURCE
+# undef _NETBSD_SOURCE
+#endif
 /* Enable OpenBSD extensions on NetBSD.  */
 #ifndef _OPENBSD_SOURCE
 # undef _OPENBSD_SOURCE
@@ -132,6 +136,7 @@ dnl configure.ac when using autoheader 2.62.
   AC_DEFINE([_ALL_SOURCE])
   AC_DEFINE([_DARWIN_C_SOURCE])
   AC_DEFINE([_GNU_SOURCE])
+  AC_DEFINE([_NETBSD_SOURCE])
   AC_DEFINE([_OPENBSD_SOURCE])
   AC_DEFINE([_POSIX_PTHREAD_SEMANTICS])
   AC_DEFINE([__STDC_WANT_IEC_60559_ATTRIBS_EXT__])

Re: Feature Request: Implement glibc reallocarray() function

[Darshit Shah]

* Bruno Haible  [170814 21:41]:

Hi Darshit,

Thank you very much for your patience, to go through these details for your
first major gnulib contributions! I appreciate it a lot.

Bruno



I'd like to thank everyone here who helped me along the way making sure 
that the patch was made perfectly. And also to deal with my broken MUA 
configuration for a while, not to mention my editor which is set to use 
tabs and I kept forgetting to change it for the gnulib code.


Now, I have a better idea of how ti work with gnulib even for my own 
projects. 


--
Thanking You,
Darshit Shah
PGP Fingerprint: 7845 120B 07CB D8D6 ECE5 FF2B 2A17 43ED A91A 35B6


signature.asc
Description: PGP signature