new *z*printf-gnu modules

[Bruno Haible]

This set of patches adds -gnu variants for the *z*printf modules
that we have so far, along with small unit tests.


2024-06-25  Bruno Haible  

obstack-zprintf-gnu: Add tests.
* tests/test-obstack-zprintf-gnu.c: New file, based on
tests/test-vazsprintf-gnu.c.
* modules/obstack-zprintf-gnu-tests: New file.

obstack-zprintf-gnu: New module.
* modules/obstack-zprintf-gnu: New file.

2024-06-25  Bruno Haible  

vazsprintf-gnu: Add tests.
* tests/test-vazsprintf-gnu.c: New file, based on
tests/test-zsnprintf-gnu.h.
* modules/vazsprintf-gnu-tests: New file.

vazsprintf-gnu: New module.
* modules/vazsprintf-gnu: New file.

2024-06-25  Bruno Haible  

zsprintf-gnu: Add tests.
* tests/test-zsprintf-gnu.c: New file.
* modules/zsprintf-gnu-tests: New file.

zsprintf-gnu: New module.
* modules/zsprintf-gnu: New file.

2024-06-25  Bruno Haible  

vzsprintf-gnu: Add tests.
* tests/test-vzsprintf-gnu.c: New file.
* tests/test-zsprintf-gnu.h: New file, based on
tests/test-zsnprintf-gnu.h.
* modules/vzsprintf-gnu-tests: New file.

vzsprintf-gnu: New module.
* modules/vzsprintf-gnu: New file.

2024-06-25  Bruno Haible  

zsnprintf-gnu: Add tests.
* tests/test-zsnprintf-gnu.c: New file.
* modules/zsnprintf-gnu-tests: New file.

zsnprintf-gnu: New module.
* modules/zsnprintf-gnu: New file.

2024-06-25  Bruno Haible  

vzsnprintf-gnu: Add tests.
* tests/test-vzsnprintf-gnu.c: New file.
* tests/test-zsnprintf-gnu.h: New file, based on
tests/test-snprintf-gnu.h.
* modules/vzsnprintf-gnu-tests: New file.

vzsnprintf-gnu: New module.
* modules/vzsnprintf-gnu: New file.

>From 3b70d6b43286fedec9b8b92ba69e706db187c1f8 Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Tue, 25 Jun 2024 16:36:18 +0200
Subject: [PATCH 01/12] vzsnprintf-gnu: New module.

* modules/vzsnprintf-gnu: New file.
---
 ChangeLog  |  5 +
 modules/vzsnprintf-gnu | 23 +++
 2 files changed, 28 insertions(+)
 create mode 100644 modules/vzsnprintf-gnu

diff --git a/ChangeLog b/ChangeLog
index 02fc3f35fa..2272ada314 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2024-06-25  Bruno Haible  
+
+	vzsnprintf-gnu: New module.
+	* modules/vzsnprintf-gnu: New file.
+
 2024-06-24  Bruno Haible  
 
 	obstack-zprintf-posix: Add tests.
diff --git a/modules/vzsnprintf-gnu b/modules/vzsnprintf-gnu
new file mode 100644
index 00..04c46a3cc3
--- /dev/null
+++ b/modules/vzsnprintf-gnu
@@ -0,0 +1,23 @@
+Description:
+vzsnprintf() function
+with POSIX compliant and GNU compatible format string interpretation
+
+Files:
+
+Depends-on:
+vzsnprintf-posix
+mixin/printf-gnu
+
+configure.ac:
+gl_PREREQ_VASNPRINTF_WITH_GNU_EXTRAS
+
+Makefile.am:
+
+Include:
+
+
+License:
+LGPLv2+
+
+Maintainer:
+all
-- 
2.34.1

From b6fa7b47c363f799bcb4a65b34c1f63e8ee74f9c Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Tue, 25 Jun 2024 16:38:11 +0200
Subject: [PATCH 02/12] vzsnprintf-gnu: Add tests.

* tests/test-vzsnprintf-gnu.c: New file.
* tests/test-zsnprintf-gnu.h: New file, based on
tests/test-snprintf-gnu.h.
* modules/vzsnprintf-gnu-tests: New file.
---
 ChangeLog|  6 +
 modules/vzsnprintf-gnu-tests | 12 +
 tests/test-vzsnprintf-gnu.c  | 48 
 tests/test-zsnprintf-gnu.h   | 37 +++
 4 files changed, 103 insertions(+)
 create mode 100644 modules/vzsnprintf-gnu-tests
 create mode 100644 tests/test-vzsnprintf-gnu.c
 create mode 100644 tests/test-zsnprintf-gnu.h

diff --git a/ChangeLog b/ChangeLog
index 2272ada314..2aafab3277 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
 2024-06-25  Bruno Haible  
 
+	vzsnprintf-gnu: Add tests.
+	* tests/test-vzsnprintf-gnu.c: New file.
+	* tests/test-zsnprintf-gnu.h: New file, based on
+	tests/test-snprintf-gnu.h.
+	* modules/vzsnprintf-gnu-tests: New file.
+
 	vzsnprintf-gnu: New module.
 	* modules/vzsnprintf-gnu: New file.
 
diff --git a/modules/vzsnprintf-gnu-tests b/modules/vzsnprintf-gnu-tests
new file mode 100644
index 00..caf3f4ee8d
--- /dev/null
+++ b/modules/vzsnprintf-gnu-tests
@@ -0,0 +1,12 @@
+Files:
+tests/test-vzsnprintf-gnu.c
+tests/test-zsnprintf-gnu.h
+tests/macros.h
+
+Depends-on:
+
+configure.ac:
+
+Makefile.am:
+TESTS += test-vzsnprintf-gnu
+check_PROGRAMS += test-vzsnprintf-gnu
diff --git a/tests/test-vzsnprintf-gnu.c b/tests/test-vzsnprintf-gnu.c
new file mode 100644
index 00..65e893c050
--- /dev/null
+++ b/tests/test-vzsnprintf-gnu.c
@@ -0,0 +1,48 @@
+/* Test of POSIX and GNU compatible vzsnprintf() function.
+   Copyright (C) 2007-2024 Free Software Foundation, Inc.
+
+   This program is free software: you can redistribute it and/or modify
+   it under the terms of the GNU General Public License 

Re: gnulib macro to check for PIC for a dependent library?

[Bruno Haible]

Hi Dmitrii,

> Building shared libraries which depend upon
> other libraries breaks whenever a dependency found (by something like
> AC_SEARCH_LIBS) was not built with -fPIC (or whatever
> the name of this option might be on the platform in question).
> And, preferably, one might want to check that the dependency is
> a dynamic library itself.
> 
> Are there any gnulib (or autoconf) macros available which can help here?

None that I know of.

You might get better feedback from a libtool mailing list than from here.
But my understanding is that

1) Static libraries are generally built without -fPIC. Building static
   libraries with -fPIC was commonly done in the 1990ies, because ELF
   and its dependency mechanisms were not in use everywhere at that time.
   Since the time shared libraries work fine, there is hardly any use any
   more to position-independent static code (except, of course, on systems
   where everything is compiled with -fPIE).

2) libtool adds an option --with-pic to the generated configure script of a
   package. But hardly anyone makes use of it.

3) Many packages come only with a shared library, not with a .a file any
   more. See:
   $ ll /usr/lib/x86_64-linux-gnu/lib*.so | wc -l
   422
   $ ll /usr/lib/x86_64-linux-gnu/lib*.a | wc -l
   207

   The reason is that distros prefer shared libraries: When there is a
   bug fix to a package, they have to rebuild that one package and not
   also a dozen of other packages.

4) On x86, it was possible to put non-PIC code into a shared library, and
   that worked (albeit with a performance hit). On x86_64, this does not
   work any more. And despite of that, the fact that most static libraries
   are not built with -fPIC does not hurt anyone (apparently).

> Thinking of writing such a macro myself

I think it would not really be useful. Your time is better spent in making
all packages that currently ship only a static library ship a shared library
as well.

Bruno

Re: new *z*printf-gnu modules

[Collin Funk]

Hi Bruno,

Bruno Haible  writes:

> This set of patches adds -gnu variants for the *z*printf modules
> that we have so far, along with small unit tests.

Looks good (+ previous patches). One question though since I noticed
these functions are defined in stdio.h.

Is the correct way to use them as Paul mentioned previously?
Like this [1]:


#undef printf
#define printf zprintf

Collin

[1] https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00353.html

Re: new *z*printf-gnu modules

[Bruno Haible]

And likewise for the c-*z*printf modules:


2024-06-25  Bruno Haible  

c-vazsprintf-gnu: Add tests.
* tests/test-vazsprintf-gnu.h: New file, extracted from
tests/test-vazsprintf-gnu.c.
* tests/test-vazsprintf-gnu.c: Include test-vazsprintf-gnu.h.
(test_function): Moved out to tests/test-vazsprintf-gnu.h.
* modules/vazsprintf-gnu-tests (Files): Add tests/test-vazsprintf-gnu.h.
* tests/test-c-vazsprintf-gnu.c: New file.
* tests/test-c-vazsprintf-gnu.sh: New file, based on
tests/test-c-snprintf.sh.
* modules/c-vazsprintf-gnu-tests: New file.

c-vazsprintf-gnu: New module.
* modules/c-vazsprintf-gnu: New file.

2024-06-25  Bruno Haible  

c-zsnprintf-gnu: Add tests.
* tests/test-c-zsnprintf-gnu.c: New file.
* tests/test-c-zsnprintf-gnu.sh: New file, based on
tests/test-c-snprintf.sh.
* modules/c-zsnprintf-gnu-tests: New file.

c-zsnprintf-gnu: New module.
* modules/c-zsnprintf-gnu: New file.

2024-06-25  Bruno Haible  

c-vzsnprintf-gnu: Add tests.
* tests/test-c-vzsnprintf-gnu.c: New file, based on
tests/test-vzsnprintf-gnu.c.
* tests/test-c-vzsnprintf-gnu.sh: New file, based on
tests/test-c-snprintf.sh.
* modules/c-vzsnprintf-gnu-tests: New file.

c-vzsnprintf-gnu: New module.
* modules/c-vzsnprintf-gnu: New file.

>From f04e21fafb6211ff05d9e792ba3e79dd857c97bc Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Wed, 26 Jun 2024 01:03:35 +0200
Subject: [PATCH 1/6] c-vzsnprintf-gnu: New module.

* modules/c-vzsnprintf-gnu: New file.
---
 ChangeLog|  5 +
 modules/c-vzsnprintf-gnu | 23 +++
 2 files changed, 28 insertions(+)
 create mode 100644 modules/c-vzsnprintf-gnu

diff --git a/ChangeLog b/ChangeLog
index 12be34ac2b..beab2cc12a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2024-06-25  Bruno Haible  
+
+	c-vzsnprintf-gnu: New module.
+	* modules/c-vzsnprintf-gnu: New file.
+
 2024-06-25  Bruno Haible  
 
 	c-vasnprintf: Add tests.
diff --git a/modules/c-vzsnprintf-gnu b/modules/c-vzsnprintf-gnu
new file mode 100644
index 00..9a02c1d847
--- /dev/null
+++ b/modules/c-vzsnprintf-gnu
@@ -0,0 +1,23 @@
+Description:
+c_vzsnprintf() function
+with POSIX compliant and GNU compatible format string interpretation
+
+Files:
+
+Depends-on:
+c-vzsnprintf
+mixin/printf-gnu
+
+configure.ac:
+gl_PREREQ_VASNPRINTF_WITH_GNU_EXTRAS
+
+Makefile.am:
+
+Include:
+"c-vsnprintf.h"
+
+License:
+LGPLv2+
+
+Maintainer:
+all
-- 
2.34.1

>From 6888e9e333bf103431e2c0903e0b4490849b886d Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Wed, 26 Jun 2024 01:04:02 +0200
Subject: [PATCH 2/6] c-vzsnprintf-gnu: Add tests.

* tests/test-c-vzsnprintf-gnu.c: New file, based on
tests/test-vzsnprintf-gnu.c.
* tests/test-c-vzsnprintf-gnu.sh: New file, based on
tests/test-c-snprintf.sh.
* modules/c-vzsnprintf-gnu-tests: New file.
---
 ChangeLog  |  7 +
 modules/c-vzsnprintf-gnu-tests | 19 
 tests/test-c-vzsnprintf-gnu.c  | 53 ++
 tests/test-c-vzsnprintf-gnu.sh | 15 ++
 4 files changed, 94 insertions(+)
 create mode 100644 modules/c-vzsnprintf-gnu-tests
 create mode 100644 tests/test-c-vzsnprintf-gnu.c
 create mode 100755 tests/test-c-vzsnprintf-gnu.sh

diff --git a/ChangeLog b/ChangeLog
index beab2cc12a..e23e904e12 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,12 @@
 2024-06-25  Bruno Haible  
 
+	c-vzsnprintf-gnu: Add tests.
+	* tests/test-c-vzsnprintf-gnu.c: New file, based on
+	tests/test-vzsnprintf-gnu.c.
+	* tests/test-c-vzsnprintf-gnu.sh: New file, based on
+	tests/test-c-snprintf.sh.
+	* modules/c-vzsnprintf-gnu-tests: New file.
+
 	c-vzsnprintf-gnu: New module.
 	* modules/c-vzsnprintf-gnu: New file.
 
diff --git a/modules/c-vzsnprintf-gnu-tests b/modules/c-vzsnprintf-gnu-tests
new file mode 100644
index 00..044c5f25ec
--- /dev/null
+++ b/modules/c-vzsnprintf-gnu-tests
@@ -0,0 +1,19 @@
+Files:
+tests/test-c-vzsnprintf-gnu.c
+tests/test-zsnprintf-gnu.h
+tests/test-c-vzsnprintf-gnu.sh
+tests/macros.h
+m4/locale-fr.m4
+m4/codeset.m4
+
+Depends-on:
+setlocale
+
+configure.ac:
+gt_LOCALE_FR
+
+Makefile.am:
+TESTS += test-c-vzsnprintf-gnu.sh
+TESTS_ENVIRONMENT += LOCALE_FR='@LOCALE_FR@'
+check_PROGRAMS += test-c-vzsnprintf-gnu
+test_c_vzsnprintf_gnu_LDADD = $(LDADD) $(SETLOCALE_LIB)
diff --git a/tests/test-c-vzsnprintf-gnu.c b/tests/test-c-vzsnprintf-gnu.c
new file mode 100644
index 00..4facc1f9c3
--- /dev/null
+++ b/tests/test-c-vzsnprintf-gnu.c
@@ -0,0 +1,53 @@
+/* Test of POSIX and GNU compatible c_vzsnprintf() function.
+   Copyright (C) 2011-2024 Free Software Foundation, Inc.
+
+   This program is free software: you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation, either version 3 of the Li

Re: new *z*printf-gnu modules

[Bruno Haible]

Collin Funk wrote:
> I'm not sure how portable the __asm__ redirects are.

Only supported by GCC and clang, I would say.

> could include a header with extern inline functions?

And that extern inline function would be called 'printf', right?
That would work in programs, but would be hairy in libraries,
because (on ELF systems) the 'printf' in one library would override
the 'printf' from libc and thus have side effects on other libraries
linked to the same executable.

> Maybe something like:
> 
> #define PERFER_ZPRINTF 1

Should the application be able to set this macro per compilation unit?
Or should it better be the same throughout the entire package (i.e.
defined in config.h)?

Bruno

inventory of POSIX.1-2024 changes

[Bruno Haible]

To get an overview what Gnulib can do to better support the POSIX-1.2024 APIs,
I went through the POSIX.1-2024 PDF and collected references to "Issue 8"
and "Austin Group Defect".

The result are two files:
  - A list of header files and functions for which the documentation might
need to change. Attached: posix-2024-doc.TODO
  - A list of header files and functions for which the Gnulib may help
improve the portability. Attached: posix-2024-impl.TODO

I plan to add these files to the maint-tools/ repository, so that we can
track progress. For the moment, as we don't have the HTML formatted
POSIX yet, we cannot work on the documentation part. But you can look at
the posix-2024-impl.TODO to figure areas which you would like to work on
(or at least start to evaluate the feasibility in Gnulib).

Bruno
Gnulib documentation tasks related to POSIX.1-2024
==

Documentation
-

Update documentation regarding new header files:
-- Borrowed from ISO C:





-- Originating in POSIX:




Update documentation regarding modified existing header files
(see CHANGE HISTORY > Issue 8):




















































Update documentation regarding new functions.
-- Borrowed from ISO C:
CMPLX, CMPLXF, CMPLXL
aligned_alloc
at_quick_exit
atomic_compare_exchange_strong
atomic_compare_exchange_strong_explicit
atomic_compare_exchange_weak
atomic_compare_exchange_weak_explicit
atomic_exchange
atomic_exchange_explicit
atomic_fetch_add
atomic_fetch_add_explicit
atomic_fetch_and
atomic_fetch_and_explicit
atomic_fetch_or
atomic_fetch_or_explicit
atomic_fetch_sub
atomic_fetch_sub_explicit
atomic_fetch_xor
atomic_fetch_xor_explicit
atomic_flag_clear
atomic_flag_clear_explicit
atomic_flag_test_and_set
atomic_flag_test_and_set_explicit
atomic_init
atomic_is_lock_free
atomic_load
atomic_load_explicit
atomic_signal_fence
atomic_thread_fence
atomic_store
atomic_store_explicit
c16rtomb
c32rtomb
call_once
cnd_broadcast
cnd_signal
cnd_destroy
cnd_init
cnd_timedwait
cnd_wait
kill_dependency
mbrtoc16
mbrtoc32
mtx_destroy
mtx_init
mtx_lock
mtx_timedlock
mtx_trylock
mtx_unlock
quick_exit
thrd_create
thrd_current
thrd_detach
thrd_equal
thrd_exit
thrd_join
thrd_sleep
thrd_yield
tss_create
tss_delete
tss_get
tss_set
-- Originating in POSIX:
be16toh
be32toh
be64toh
htobe16
htobe32
htobe64
htole16
htole32
htole64
le16toh
le32toh
le64toh
bindtextdomain
bind_textdomain_codeset
textdomain
dladdr
ffsl, ffsll
getentropy
getlocalename_l
getresgid
getresuid
dgettext
dgettext_l
dcgettext
dcgettext_l
dngettext
dngettext_l
dcngettext
dcngettext_l
gettext
gettext_l
ngettext
ngettext_l
in6addr_any
in6addr_loopback
memmem
posix_close
posix_devctl
posix_getdents
posix_spawn_file_actions_addchdir
posix_spawn_file_actions_addfchdir
secure_getenv
setresgid
setresuid
sig2str
str2sig
strlcat
strlcpy
tcgetwinsize
tcsetwinsize
timespec_get
wcslcat
wcslcpy
_Fork

Update documentation regarding modified functions
(see CHANGE HISTORY > Issue 8):
_Exit, exit
abort
abs
accept, accept4
aio_fsync
aio_suspend
aio_write
alarm
asctime
asin, asinf, asinl
asinh, asinhf, asinhl
atan, atanf, atanl
atan2, atan2f, atan2l
atanh, atanhf, atanhl
atexit
atoi
basename
bind
cabs, cabsf, cabsl
cacos, cacosf, cacosl
cacosh, cacoshf, cacoshl
calloc
carg, cargf, cargl
casin, casinf, casinl
casinh, casinhf, casinhl
catan, catanf, catanl
catanh, catanhf, catanhl
catopen
ccos, ccosf, ccosl
ccosh, ccoshf, ccoshl
ceil, ceilf, ceill
cexp, cexpf, cexpl
chmod, fchmodat
clock
clock_getres
clog, clogf, clogl
close, posix_close
closedir
closelog, openlog, setlogmask, syslog
confstr
connect
copysign, copysignf, copysignl
cpow, cpowf, cpowl
creat
crypt
csin, csinf, csinl
csinh, csinhf, csinhl
csqrt, csqrtf, csqrtl
ctan, ctanf, ctanl
ctanh, ctanhf, ctanhl
ctime
dbm_clearerr, dbm_close, dbm_delete, dmb_error, dmb_fetch, dbm_firstkey, 
dbm_nextkey, dbm_open, dbm_store
dirfd
dirname
dlclose
dlerror
dlopen
dlsym
drand48, erand48, jrand48, lcong48, lrand48, mrand48, nrand48, seed48, srand48
dup, dup2, dup3
encrypt
endhostent, gethostent, sethostent
endnetent, getnetbyaddr, getnetbyname, getnetent, setnetent
endprotoent, getprotobyname, getprotobynumber, getprotoent, setprotoent
endservent, getservbyname, getservbyport, getservent, setservent
erf, erff, erfl
errno
execl, execle, execlp, execv, execve, execvp, fexecve
exit
expm1, expm1f, expm1l
fabs, fabsf, fabsl
fchmod
fchown
fclose
fcntl
fdatasync
fdopen
fdopendir, opendir
fflush
fgetc
fgets
fgetwc
fgetws
flockfile, ftrylockfile, funlockfile
floor, floorf, floorl
fmax, fmaxf, fmaxl
fmemopen
fmin, fminf, fminl
fmod, fmodf, fmodl
fnmatch
fopen
fork, _Fork
fpathconf, pathconf
asprintf, dprintf, fprintf, printf, snprintf, sprintf
fputc
fputwc
fread
free
freeaddrinfo, getaddrinfo
freelocale
freopen
frexp, frexpf, frexpl
fscanf, scanf, sscanf
fseek, fseeko
fsetpos
fstatat, lstat, stat
fsync
ftell, ftello
ftruncate
futimens, utimensat, utimes
fwprintf, swprintf, wprintf
fwrite
fwscanf, swsca

Re: inventory of POSIX.1-2024 changes

[Collin Funk]

Bruno Haible  writes:

> I plan to add these files to the maint-tools/ repository, so that we can
> track progress. For the moment, as we don't have the HTML formatted
> POSIX yet, we cannot work on the documentation part. But you can look at
> the posix-2024-impl.TODO to figure areas which you would like to work on
> (or at least start to evaluate the feasibility in Gnulib).

Thanks. I was doing this in an unorganized fashion when I mentioned the
EXIT_FAILURE changed.

Is it okay if I add inet_ntoa? It is "obsolete" in this latest revision
but it is used everywhere including GNU Inetutils [1] [2]. FWIW I don't
think its usage is bad as long as you don't have plans to make your
program multithreaded.

I'm thinking that Windows will need a replacement just to get rid of the
stdcall convention and other systems can use inet_ntop with a static
buffer.

Collin

[1] https://github.com/search?q=+inet_ntoa+lang%3AC&type=code
[2] https://codesearch.debian.net/search?q=+inet_ntoa&literal=1

Re: inet_ntoa

[Bruno Haible]

Collin Funk wrote:
> Is it okay if I add inet_ntoa? It is "obsolete" in this latest revision
> but it is used everywhere including GNU Inetutils [1] [2]. FWIW I don't
> think its usage is bad as long as you don't have plans to make your
> program multithreaded.

The problems of inet_ntoa are summarized in our documentation
(doc/posix-functions/inet_ntoa.texi). The biggest problem is that
it does not support IPv6. IPv6 is everywhere nowadays: internet
providers give out IPv6 addresses to their customers, and probably
2/3 of the websites I usually connect to have both an IPv6 and
an IPv4 address.

Therefore, it makes no sense to maintain programs that work
only with IPv4 and not with IPv6.

While it is - in theory - possible that a program has different
code paths for IPv4 and IPv6 and uses inet_ntoa for the former one,
this is probably a small minority. Most programs will want to
handle IPv4 and IPv6 through the same code, and inet_ntop is the
function to use.

So, I don't think adding an inet_ntoa module to Gnulib would really
help anyone.

Bruno

Re: inet_ntoa

[Collin Funk]

Bruno Haible  writes:

> The problems of inet_ntoa are summarized in our documentation
> (doc/posix-functions/inet_ntoa.texi). The biggest problem is that
> it does not support IPv6. IPv6 is everywhere nowadays: internet
> providers give out IPv6 addresses to their customers, and probably
> 2/3 of the websites I usually connect to have both an IPv6 and
> an IPv4 address.

Ah, I forgot about that. Ignore my comments then I was speaking from
rough memory. :)

> Therefore, it makes no sense to maintain programs that work
> only with IPv4 and not with IPv6.
[...]
> So, I don't think adding an inet_ntoa module to Gnulib would really
> help anyone.

Agreed.

Collin

c-vasnprintf: Fix link errors

[Bruno Haible]

c-vasnprintf has a long-standing bug: When I add a unit test for it, it leads
to link errors:

/usr/bin/ld: ../gllib/libgnu.a(c-vasnprintf.o): in function `c_vasnprintf':
/GNULIB/testdir2/build-64/gllib/../../gllib/vasnprintf.c:2246: undefined 
reference to `printf_parse'
/usr/bin/ld: /GNULIB/testdir2/build-64/gllib/../../gllib/vasnprintf.c:2257: 
undefined reference to `printf_fetchargs'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:3610: test-c-vasnprintf] Error 1

These two patches fix the bug and add the unit test. Will push once savannah
is up again.


2024-06-25  Bruno Haible  

c-vasnprintf: Add tests.
* tests/test-c-vasnprintf.c: New file, based on tests/test-c-snprintf.c.
* tests/test-c-vasnprintf.sh: New file, based on
tests/test-c-snprintf.sh.
* modules/c-vasnprintf-tests: New file.

2024-06-25  Bruno Haible  

c-vasnprintf: Fix link errors.
* modules/c-vasnprintf (configure.ac): Ensure printf-args.c and
printf-parse.c get compiled. Invoke gl_PREREQ_PRINTF_ARGS,
gl_PREREQ_PRINTF_PARSE.

>From 82791096e9320f4fbf0390f7fa7e06e49b4c9672 Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Tue, 25 Jun 2024 19:35:20 +0200
Subject: [PATCH 1/2] c-vasnprintf: Fix link errors.

* modules/c-vasnprintf (configure.ac): Ensure printf-args.c and
printf-parse.c get compiled. Invoke gl_PREREQ_PRINTF_ARGS,
gl_PREREQ_PRINTF_PARSE.
---
 ChangeLog| 7 +++
 modules/c-vasnprintf | 4 
 2 files changed, 11 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index 48274cadbf..f97591d3f3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2024-06-25  Bruno Haible  
+
+	c-vasnprintf: Fix link errors.
+	* modules/c-vasnprintf (configure.ac): Ensure printf-args.c and
+	printf-parse.c get compiled. Invoke gl_PREREQ_PRINTF_ARGS,
+	gl_PREREQ_PRINTF_PARSE.
+
 2024-06-25  Bruno Haible  
 
 	obstack-zprintf-gnu: Add tests.
diff --git a/modules/c-vasnprintf b/modules/c-vasnprintf
index ab48d64310..53c7babe84 100644
--- a/modules/c-vasnprintf
+++ b/modules/c-vasnprintf
@@ -39,6 +39,10 @@ mbszero
 
 configure.ac:
 AC_REQUIRE([AC_C_RESTRICT])
+AC_LIBOBJ([printf-args])
+AC_LIBOBJ([printf-parse])
+gl_PREREQ_PRINTF_ARGS
+gl_PREREQ_PRINTF_PARSE
 gl_PREREQ_VASNPRINTF_WITH_POSIX_EXTRAS
 
 Makefile.am:
-- 
2.34.1

>From d2267879157bb4817fcf2eeeda4797b6f0c31d58 Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Tue, 25 Jun 2024 19:27:42 +0200
Subject: [PATCH 2/2] c-vasnprintf: Add tests.

* tests/test-c-vasnprintf.c: New file, based on tests/test-c-snprintf.c.
* tests/test-c-vasnprintf.sh: New file, based on
tests/test-c-snprintf.sh.
* modules/c-vasnprintf-tests: New file.
---
 ChangeLog  |  8 ++
 modules/c-vasnprintf-tests | 18 
 tests/test-c-vasnprintf.c  | 57 ++
 tests/test-c-vasnprintf.sh | 15 ++
 4 files changed, 98 insertions(+)
 create mode 100644 modules/c-vasnprintf-tests
 create mode 100644 tests/test-c-vasnprintf.c
 create mode 100755 tests/test-c-vasnprintf.sh

diff --git a/ChangeLog b/ChangeLog
index f97591d3f3..12be34ac2b 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2024-06-25  Bruno Haible  
+
+	c-vasnprintf: Add tests.
+	* tests/test-c-vasnprintf.c: New file, based on tests/test-c-snprintf.c.
+	* tests/test-c-vasnprintf.sh: New file, based on
+	tests/test-c-snprintf.sh.
+	* modules/c-vasnprintf-tests: New file.
+
 2024-06-25  Bruno Haible  
 
 	c-vasnprintf: Fix link errors.
diff --git a/modules/c-vasnprintf-tests b/modules/c-vasnprintf-tests
new file mode 100644
index 00..8837f3c185
--- /dev/null
+++ b/modules/c-vasnprintf-tests
@@ -0,0 +1,18 @@
+Files:
+tests/test-c-vasnprintf.c
+tests/test-c-vasnprintf.sh
+tests/macros.h
+m4/locale-fr.m4
+m4/codeset.m4
+
+Depends-on:
+setlocale
+
+configure.ac:
+gt_LOCALE_FR
+
+Makefile.am:
+TESTS += test-c-vasnprintf.sh
+TESTS_ENVIRONMENT += LOCALE_FR='@LOCALE_FR@'
+check_PROGRAMS += test-c-vasnprintf
+test_c_vasnprintf_LDADD = $(LDADD) $(SETLOCALE_LIB)
diff --git a/tests/test-c-vasnprintf.c b/tests/test-c-vasnprintf.c
new file mode 100644
index 00..3ac92c2408
--- /dev/null
+++ b/tests/test-c-vasnprintf.c
@@ -0,0 +1,57 @@
+/* Test of c_vasnprintf() function.
+   Copyright (C) 2011-2024 Free Software Foundation, Inc.
+
+   This program is free software: you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation, either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see .  */
+
+#include 

Re: new *z*printf-gnu modules

[Bruno Haible]

Hi Collin,

> Is the correct way to use them as Paul mentioned previously?
> Like this [1]:
> 
> 
> #undef printf
> #define printf zprintf

This is more hairy than you might think. Because of the GCC attribute syntax.

stdio.in.h does

/* Don't break __attribute__((format(printf,M,N))).  */
#define printf __printf__

because there are not many symbols that can be used in place of 'printf'.

Do you have an idea for doing this nicely? Perhaps another kind of redirect?
A 'static inline' function would not be good, because it cannot be used
everywhere (ISO C 23 § 6.7.4.(3)). Maybe an 'extern inline'? Or can __asm__
based redirection made portable across all systems?

Bruno

Re: new *z*printf-gnu modules

[Collin Funk]

Bruno Haible  writes:

> This is more hairy than you might think. Because of the GCC attribute syntax.
>
> stdio.in.h does
>
> /* Don't break __attribute__((format(printf,M,N))).  */
> #define printf __printf__
>
> because there are not many symbols that can be used in place of 'printf'.

Ah, interesting. I didn't even know that. Makes sense though.

> Do you have an idea for doing this nicely? Perhaps another kind of redirect?
> A 'static inline' function would not be good, because it cannot be used
> everywhere (ISO C 23 § 6.7.4.(3)). Maybe an 'extern inline'? Or can __asm__
> based redirection made portable across all systems?

I don't have any ideas at the moment. I'm not sure how portable the
__asm__ redirects are. Maybe something like:

#define PERFER_ZPRINTF 1
#include 

could include a header with extern inline functions?

Collin

Re: c-vasnprintf: Fix link errors

[Collin Funk]

Bruno Haible  writes:

> These two patches fix the bug and add the unit test. Will push once savannah
> is up again.

Seems to be up now. I think it was down since last night/early this
morning so I couldn't pull any of your previous patches either.

Collin

Integer overflows in memchr

[Po Lu]

It has been brought to my attention that a defective memchr is
distributed with certain Android E-book readers with Android 2.3.5 that
is liable to integer overflows with large values of N:

  memchr ("", 0, SIZE_MAX);

returns NULL, since:

Dump of assembler code for function memchr:
   0xafd20644 <+0>: addsr2, r0, r2  @ <- overflow
   0xafd20646 <+2>: addsr3, r0, #3
   0xafd20648 <+4>: push{r4, r5, lr}
   0xafd2064a <+6>: cmp r0, r2  @ <- r0 is consequently 
smaller than r2
   0xafd2064c <+8>: bcs.n   0xafd20686 
   0xafd2064e <+10>:ldrb.w  r4, [r3, #-3]
   0xafd20652 <+14>:cmp r4, r1
   0xafd20654 <+16>:beq.n   0xafd20688 
   0xafd20656 <+18>:addsr4, r0, #1
   0xafd20658 <+20>:cmp r2, r4
   0xafd2065a <+22>:bls.n   0xafd20686 
   0xafd2065c <+24>:ldrbr5, [r0, #1]
   0xafd2065e <+26>:cmp r5, r1
   0xafd20660 <+28>:beq.n   0xafd2066e 
   0xafd20662 <+30>:addsr4, r0, #2
   0xafd20664 <+32>:cmp r2, r4
   0xafd20666 <+34>:bls.n   0xafd20686 
   0xafd20668 <+36>:ldrbr5, [r0, #2]
   0xafd2066a <+38>:cmp r5, r1
   0xafd2066c <+40>:bne.n   0xafd20672 
   0xafd2066e <+42>:mov r0, r4
   0xafd20670 <+44>:b.n 0xafd20688 
   0xafd20672 <+46>:cmp r2, r3
   0xafd20674 <+48>:bls.n   0xafd20686 
   0xafd20676 <+50>:ldrbr4, [r0, #3]
   0xafd20678 <+52>:addsr3, #4
   0xafd2067a <+54>:cmp r4, r1
   0xafd2067c <+56>:bne.n   0xafd20682 
   0xafd2067e <+58>:subsr0, r3, #4
   0xafd20680 <+60>:b.n 0xafd20688 
   0xafd20682 <+62>:addsr0, #4
   0xafd20684 <+64>:b.n 0xafd2064a 
   0xafd20686 <+66>:movsr0, #0  @ <- NULL is returned
   0xafd20688 <+68>:pop {r4, r5, pc}

disassembly of libc.so samples extracted from real Android devices
reveals that defective versions of memchr are present until Android 4.3,
API level 18.

As it appears, this is a misbegotten (and poorly) "optimized" version of
memchr that derives a destination pointer from the source, and deduces
whether the limit has been encountered by a simple integer magnitude
comparison between the two pointers, which prompts an immediate return
when the offset is such that the first sum overflows.  This extends to
affect strnlen, which is implemented around memchr, and assumes that a
NULL value indicates that the NULL byte is beyond the provided limit:

Dump of assembler code for function strnlen:
   0xafd20ab4 <+0>: push{r4, r5, r6, lr}
   0xafd20ab6 <+2>: mov r4, r1  @ <- MAXLEN
   0xafd20ab8 <+4>: mov r2, r4
   0xafd20aba <+6>: movsr1, #0
   0xafd20abc <+8>: mov r5, r0
   0xafd20abe <+10>:bl  0xafd20644 
   0xafd20ac2 <+14>:cbz r0, 0xafd20ac6 
   0xafd20ac4 <+16>:subsr4, r0, r5
   0xafd20ac6 <+18>:mov r0, r4  @ <- MAXLEN returned
   0xafd20ac8 <+20>:pop {r4, r5, r6, pc}

producing crashes in this function in Emacs:

static int
store_mode_line_string (const char *string, Lisp_Object lisp_string,
bool copy_string,
int field_width, int precision, Lisp_Object props)
{
  ptrdiff_t len;
  int n = 0;

  if (string != NULL)
{
  len = strnlen (string, precision <= 0 ? SIZE_MAX : precision);
  lisp_string = make_string (string, len);

when PRECISION is 0, and SIZE_MAX is returned, causing `make_string' to
be called to allocate a string of negative length.  Perhaps Gnulib
should provide a module with replacements for memchr and affected string
functions, viz., strnlen, memmem, wmemchr, mbstowcs, mbsrtowcs,
wcsrtombs, and wcstombs.

Re: Integer overflows in memchr

[Po Lu]

Po Lu  writes:

> disassembly of libc.so samples extracted from real Android devices
> reveals that defective versions of memchr are present until Android 4.3,
> API level 18.

Correction, up to API level 22 on architectures without specific
implementations of memrchr, as these issues suggest:

  https://issuetracker.google.com/issues/37020957
  https://android-review.googlesource.com/c/platform/bionic/+/132480

idpriv-drop: Handle large user and group ids.

[Collin Funk]

I was looking at a program that used PID & 0x as an arbitrary
identifier. Not directly related to this patch but it made me think
about what the limits are on process, user, and group IDs.

Here is what POSIX Issue 7 says in the documentation in 
[1]:

The implementation shall support one or more programming environments in
which the widths of blksize_t, pid_t, size_t, ssize_t, and suseconds_t
are no greater than the width of type long.


I've committed these two patches adjusting idpriv-drop and
idpriv-droptemp which previously stored the result of getuid () and
getgid () in an 'int'. Not sure if this would cause issues on any of the
platforms these modules support.

For other modules where an ID is used as the result to printf it is
often casted to an int. Should I change those to intmax_t? I feel like
that would be the most portable way.

Collin

[1] https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/

>From 01f20d6346ca1faad35af98e55c602b5584b094c Mon Sep 17 00:00:00 2001
From: Collin Funk 
Date: Tue, 25 Jun 2024 21:34:51 -0700
Subject: [PATCH 1/2] idpriv-drop: Handle large user and group ids.

* lib/idpriv-drop.c (idpriv_drop): Use uid_t and gid_t instead of int.
---
 ChangeLog | 5 +
 lib/idpriv-drop.c | 4 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 359250daf2..f10e0edb43 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2024-06-25  Collin Funk  
+
+	idpriv-drop: Handle large user and group ids.
+	* lib/idpriv-drop.c (idpriv_drop): Use uid_t and gid_t instead of int.
+
 2024-06-25  Bruno Haible  
 
 	c-vazsprintf-gnu: Add tests.
diff --git a/lib/idpriv-drop.c b/lib/idpriv-drop.c
index a14d3ba9a0..3bc0d6f98c 100644
--- a/lib/idpriv-drop.c
+++ b/lib/idpriv-drop.c
@@ -26,10 +26,10 @@ int
 idpriv_drop (void)
 {
 #if HAVE_GETUID
-  int uid = getuid ();
+  uid_t uid = getuid ();
 #endif
 #if HAVE_GETGID
-  int gid = getgid ();
+  gid_t gid = getgid ();
 #endif
 
   /* Drop the gid privilege first, because in some cases the gid privilege
-- 
2.45.2

>From 9e301afb8826b2c0926779c1439643b7506df953 Mon Sep 17 00:00:00 2001
From: Collin Funk 
Date: Tue, 25 Jun 2024 21:39:50 -0700
Subject: [PATCH 2/2] idpriv-droptemp: Handle large user and group ids.

* lib/idpriv-droptemp.c (saved_uid): Use uid_t instead of int.
(saved_gid): Use gid_t instead of int.
(idpriv_temp_drop): Use uid_t and gid_t instead of int.
(idpriv_temp_restore): Likewise.
---
 ChangeLog |  6 ++
 lib/idpriv-droptemp.c | 12 ++--
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index f10e0edb43..05bec51810 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
 2024-06-25  Collin Funk  
 
+	idpriv-droptemp: Handle large user and group ids.
+	* lib/idpriv-droptemp.c (saved_uid): Use uid_t instead of int.
+	(saved_gid): Use gid_t instead of int.
+	(idpriv_temp_drop): Use uid_t and gid_t instead of int.
+	(idpriv_temp_restore): Likewise.
+
 	idpriv-drop: Handle large user and group ids.
 	* lib/idpriv-drop.c (idpriv_drop): Use uid_t and gid_t instead of int.
 
diff --git a/lib/idpriv-droptemp.c b/lib/idpriv-droptemp.c
index eb882dea6d..15337cdd9e 100644
--- a/lib/idpriv-droptemp.c
+++ b/lib/idpriv-droptemp.c
@@ -25,18 +25,18 @@
 
 /* The privileged uid and gid that the process had earlier.  */
 #if HAVE_GETUID
-static int saved_uid = -1;
+static uid_t saved_uid = -1;
 #endif
 #if HAVE_GETGID
-static int saved_gid = -1;
+static gid_t saved_gid = -1;
 #endif
 
 int
 idpriv_temp_drop (void)
 {
 #if HAVE_GETEUID && HAVE_GETEGID && (HAVE_SETRESUID || HAVE_SETREUID) && (HAVE_SETRESGID || HAVE_SETREGID)
-  int uid = getuid ();
-  int gid = getgid ();
+  uid_t uid = getuid ();
+  gid_t gid = getgid ();
 
   /* Find out about the privileged uid and gid at the first call.  */
   if (saved_uid == -1)
@@ -124,8 +124,8 @@ int
 idpriv_temp_restore (void)
 {
 #if HAVE_GETEUID && HAVE_GETEGID && (HAVE_SETRESUID || HAVE_SETREUID) && (HAVE_SETRESGID || HAVE_SETREGID)
-  int uid = getuid ();
-  int gid = getgid ();
+  uid_t uid = getuid ();
+  gid_t gid = getgid ();
 
   if (saved_uid == -1 || saved_gid == -1)
 /* Caller error: idpriv_temp_drop was never invoked.  */
-- 
2.45.2

Re: idpriv-drop: Handle large user and group ids.

[Collin Funk]

Collin Funk  writes:

> The implementation shall support one or more programming environments in
> which the widths of blksize_t, pid_t, size_t, ssize_t, and suseconds_t
> are no greater than the width of type long.

Oops, I only quoted the part mentioning pid_t. Two other important
parts:

* nlink_t, uid_t, gid_t, and id_t shall be integer types.
* blksize_t, pid_t, and ssize_t shall be signed integer types.

> I've committed these two patches adjusting idpriv-drop and
> idpriv-droptemp which previously stored the result of getuid () and
> getgid () in an 'int'. Not sure if this would cause issues on any of the
> platforms these modules support.

Hence using uid_t and gid_t here instead of int. It seems most platforms
use ≤ 32-bit values. Maybe it is possible that uid_t is unsigned and the
current user ID could not be represented in a 32-bit signed integer.

> For other modules where an ID is used as the result to printf it is
> often casted to an int. Should I change those to intmax_t? I feel like
> that would be the most portable way.

Correction here, intmax_t for printing pid_t values. For others, which
may be unsigned, uintmax_t after checking >= 0.

Collin