Re: [PATCH v1] xstrtol: 1 is not a valid base

Hi Paul, On Thu, Jul 18, 2024 at 05:37:26PM GMT, Paul Eggert wrote: > On 2024-07-18 12:53, Alejandro Colomar wrote: > > I think it'd be common to assume that unless specifically > > documented, you behave like POSIX's strtol(3), which produces defined > > behavior for a base of 1. > > Fair enough

[PATCH v1 0/2] xstrtol() fixes

Hi Paul, This patch set --hopefully; writing calls to strtol(3) is a PITA-- fixes the remaining issues I've observed in xstrtol(). Have a lovely day! Alex Alejandro Colomar (2): xstrtol: Correctly handle an invalid base xstrtol: Add defensive check against undocumented errors lib/xstrtol.c

[PATCH v1 1/2] xstrtol: Correctly handle an invalid base

strtol(3) doesn't set the end pointer if the base is invalid. This allows a caller to differentiate between "invalid base" (what strtoi(3bsd) calls EINVAL) and an "no digits seen" (what strtoi(3bsd) calls ECANCELED) in systems that report EINVAL on no digits seen (POSIX allows this). strt

[PATCH v1 2/2] xstrtol: Add defensive check against undocumented errors

strtod(3) calls malloc(3) in some systems. While strtol(3) doesn't, let's be cautious and write code that would be safe under a theoretical implementation of strtol(3) that could ENOMEM (and let's assume we don't know what 'e' will look like after such an error). Some attempt of defensive error h

Re: [PATCH v1 1/2] xstrtol: Correctly handle an invalid base

Hi Paul, On Fri, Jul 19, 2024 at 02:53:38PM GMT, Alejandro Colomar wrote: > strtol(3) doesn't set the end pointer if the base is invalid. This > allows a caller to differentiate between "invalid base" (what > strtoi(3bsd) calls EINVAL) and an "no digits seen" (what strtoi(3bsd) > calls ECANCELED)

Re: [PATCH v1 1/2] xstrtol: Correctly handle an invalid base

On Fri, Jul 19, 2024 at 03:09:52PM GMT, Alejandro Colomar wrote: > Hi Paul, > > On Fri, Jul 19, 2024 at 02:53:38PM GMT, Alejandro Colomar wrote: > > strtol(3) doesn't set the end pointer if the base is invalid. This > > allows a caller to differentiate between "invalid base" (what > > strtoi(3bsd

Re: doc: Document the stack-trace and abort-debug modules

> > > The stack-trace and abort-debug modules are now in a state where they > > > can be documented. Done as follows: > > > > Thanks. Are these modules safe to use in signal handlers? > > No, they aren't. They aren't. But you can still get a stack traces, even from signal handlers, with some add

Re: [PATCH v1] xstrtol: 1 is not a valid base

Paul Eggert wrote: > I installed the attached Gnulib patch which addresses that > point ... The comments reference parameter names VAL, VALID_SUFFIXES, etc. but the declaration does not contain parameter names. This patch fixes that: 2024-07-19 Bruno Haible xstrtol: Improve document

Re: [PATCH v1] xstrtol: 1 is not a valid base

Alejandro Colomar wrote: > BTW, does gnulib have documentation for xstrtol()? I couldn't find it. > And for MALLOC()? I'm interested in reading both. Paul added the documentation for xstrtol(). There is no macro or symbol named MALLOC in gnulib; I don't know what you are referring to. Bruno

Re: [PATCH v1] xstrtol: Remove dead code

Alejandro Colomar wrote: > strtod(3) defers to strtol(3) for the example program. Is this adequate? strtod() can produce underflow (e.g. for "1e-500"). In this case all implementations except MSVC set errno to ERANGE. This is a case that cannot happen in strtol(). Bruno

Re: [PATCH v1] xstrtol: Remove dead code

Alejandro Colomar wrote: > We'd need to know the precise specification of that system that can set > errno = ENOMEM. > > Is *endp guaranteed to be set? Or may it be unset (as happens with > EINVAL)? One system that calls malloc() during strtod() is NetBSD. See $ grep -ri malloc src/lib/libc/gdt

doc: Mention a bug in NetBSD's *gettext functions

POSIX:2024 (page 1193, line 40734) specifies that the LANGUAGE environment variable should be ignored if its value is empty. NetBSD's *gettext() functions don't do this. 2024-07-19 Bruno Haible doc: Mention a bug in NetBSD's *gettext functions. * doc/glibc-functions/gettext.te

doc: Add references to ISO C23

Some functions are specified in ISO C23, but not yet in POSIX. 2024-07-19 Bruno Haible doc: Add references to ISO C23. * doc/posix-functions/totalorder*.texi: Reference ISO C23. * doc/posix-functions/getpayload*.texi: Likewise. * doc/posix-functions/setpayload*

doc: Mention function that were added in ISO C23

ISO C23 adds a couple of new functions in . See https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2118.pdf This patch adds documentation for them to Gnulib. 2024-07-19 Bruno Haible doc: Mention function that were added in ISO C23. * doc/posix-functions/acospi.texi: New file.

Re: [PATCH v1 0/2] xstrtol() fixes

Thanks, I installed the attached, which should fix the problems you mentioned in a less-invasive way.From 16b33e6649425fcdce095f262da98b539d2f7448 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 19 Jul 2024 10:39:58 -0700 Subject: [PATCH] xstrtol: be more robust against odd failures MIME-Ve

Re: [PATCH v1] xstrtol: Remove dead code

Hi Bruno, On Fri, Jul 19, 2024 at 06:54:40PM GMT, Bruno Haible wrote: > Alejandro Colomar wrote: > > strtod(3) defers to strtol(3) for the example program. > > Is this adequate? strtod() can produce underflow (e.g. for "1e-500"). > In this case all implementations except MSVC set errno to ERANGE.

Re: [PATCH v1 0/2] xstrtol() fixes

Hi Paul, On Fri, Jul 19, 2024 at 10:47:11AM GMT, Paul Eggert wrote: > Thanks, I installed the attached, which should fix the problems you > mentioned in a less-invasive way. Thanks! I'll re-check again later to have a fresh look at the code, but LGTM, I think. Have a lovely night! Alex --

doc: Add documentation about math_errhandling

A test program (attached) reveals the value of math_errhandling and whether various operations behave like math_errhandling says. The result is pretty sobering: math_errhandling is useless. 2024-07-19 Bruno Haible doc: Add documentation about math_errhandling. * doc/posix-func

C23 n3220

Hi Bruno, I've seen your commit adding references to C23. There's a more recent draft (the final one) of C23: n3220 You may want to use that link instead. Have a lovely night! Alex -- signature.

Re: [PATCH v1 0/2] xstrtol() fixes

Hi Paul, On Fri, Jul 19, 2024 at 08:19:07PM GMT, Alejandro Colomar wrote: > Hi Paul, > > On Fri, Jul 19, 2024 at 10:47:11AM GMT, Paul Eggert wrote: > > Thanks, I installed the attached, which should fix the problems you > > mentioned in a less-invasive way. > > Thanks! I'll re-check again later

XMALLOC() et al (was: [PATCH v1] xstrtol: 1 is not a valid base)

[Reduced CC; since I'm changing topic] Hi Bruno, On Fri, Jul 19, 2024 at 06:47:13PM GMT, Bruno Haible wrote: > Alejandro Colomar wrote: > > BTW, does gnulib have documentation for xstrtol()? I couldn't find it. > > And for MALLOC()? I'm interested in reading both. > > Paul added the documentat

Re: XMALLOC() et al

On 2024-07-19 17:13, Alejandro Colomar wrote: Are XMALLOC et al. part of the public API, or are they only internal helper macros? Are there current users of it (apart from gnulib itself)? I'm interested in discussing some details about that set of macros if they're not set in stone. They're n

Re: XMALLOC() et al

Alejandro Colomar wrote: > > Are XMALLOC et al. part of the public API, or are they only internal > > helper macros? They are public API. This can be seen from the fact that - the macro is defined in xalloc.h, - the module description modules/xalloc lists this file as the file to include:

Re: C23 n3220

Hi Alejandro, > There's a more recent draft (the final one) of C23: n3220 > Thanks; I had not noticed this one. > You may want to use that link instead. Done: 2024-07-19 Bruno Haible doc: Reference a newer ISO C23 draft.

gitlog-to-changelog: Improve output of pdf documentation.

I formatted this section of code poorly when I added documentation. Even with '-t @finalout' to remove the black bars on overfilled hboxes it obviously extends past the margin. Committed the attached patch so it isn't ugly anymore. Collin >From 17967b5128a3747a35fa3e7bbc33435f5c1dedc2 Mon Sep 17

Re: XMALLOC() et al

On 2024-07-19 18:59, Bruno Haible wrote: GNU gettext uses the XMALLOC macro in more than 100 places. It's just so convenient to do a memory allocation in 1 line of code: I find it more convenient to write this: context = xmalloc (sizeof *context); than this (taken from GNU gettext): cont