Re: [g.branden.robin...@gmail.com: macOS 12.6.3 and vasnprintf compilation failure]

Hi all, On 2/7/23 02:06, Bruno Haible wrote: Hi Branden, A problem immediately arose on macOS 12.6.3. It's our good friend vasnprintf again. Logs are available on Savannah[2]. lib/vasnprintf.c:411:16: error: expected parameter declarator static_assert (sizeof (mp_limb_t) * CHAR_BIT == GMP_L

Re: macOS 12.6.3, static_assert, and vasnprintf compilation failure

Hi Branden, On 2/7/23 14:43, G. Branden Robinson wrote: [trimming and recasting subject] Hi Alex, At 2023-02-07T14:04:54+0100, Alejandro Colomar wrote: I don't know if groff is supposed to be compatible with non-GNU compilers, or if it has a dependency to GNU C compilers (GCC, Clang

Re: macOS 12.6.3, static_assert, and vasnprintf compilation failure

Hi Bruno and Branden, On 2/7/23 15:13, Bruno Haible wrote: G. Branden Robinson wrote: groff's had an assert.h header since version 1.01 (1991), but I don't know why. In 2020 I expanded it to support C99-style assertions (i.e., assertions that communicate meaning instead of the nearly useless f

Re: macOS 12.6.3, static_assert, and vasnprintf compilation failure

Hi Bruno, On 2/7/23 15:20, Bruno Haible wrote: Alejandro Colomar wrote: the last reducts of GCC defaulting to gnu89 The default standard version of GCC doesn't matter. The AC_PROG_CC macro invocation in configure.ac arranges to add the suitable command-line options, so that the C com

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

/void-linux/void-packages/issues/51261#issuecomment-2237013621> Cc: Paul Eggert Cc: Đoàn Trần Công Danh Cc: Eli Schwartz Cc: Sam James Cc: Serge Hallyn Cc: Iker Pedrosa Cc: "Andrew J. Hesford" Cc: Michael Vetter Cc: Signed-off-by: Alejandro Colomar --- Range-diff against v0

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

Hi Bruno, On Thu, Jul 18, 2024 at 08:06:07PM GMT, Bruno Haible wrote: > Alejandro Colomar wrote: > > If xstrtol() was being called with a base of 1, under some conditions it > > would invoke Undefined Behavior. > > Yes, sure. A numeric base of 1 makes no sense, mathematic

[PATCH v1] xstrtol: Remove dead code

c: Sam James Cc: Serge Hallyn Cc: Iker Pedrosa Cc: "Andrew J. Hesford" Cc: Michael Vetter Cc: Signed-off-by: Alejandro Colomar --- Range-diff against v0: -: -- > 1: 1af702673f xstrtol: Remove dead code lib/xstrtol.c | 4 +--- 1 file changed, 1 insertion(+), 3 del

Re: [PATCH v1] xstrtol: Remove dead code

On Thu, Jul 18, 2024 at 11:09:40PM GMT, Bruno Haible wrote: > Hi Alejandro, Hi Bruno, > > strtol(3) has a limited set of possible states: > > ... > > The condition '*endp != s && errno != 0 && errno != ERANGE' is > > unreachable. The only errno possible if '*endp != s' is ERANGE. > > Such a sta

Re: [PATCH v1] xstrtol: Remove dead code

[CC -= Andrew, per explicit request] On Thu, Jul 18, 2024 at 11:25:11PM GMT, Alejandro Colomar wrote: > On Thu, Jul 18, 2024 at 11:09:40PM GMT, Bruno Haible wrote: > > Hi Alejandro, Hi Bruno, > > > strtol(3) has a limited set of possible states: > > > ... >

Re: [PATCH v1] xstrtol: Remove dead code

Hi Bruno, On Fri, Jul 19, 2024 at 12:34:39AM GMT, Bruno Haible wrote: > Alejandro Colomar wrote: > > > - Some systems return "wrong" errno values. Example: [1] > > > - Some systems fail with ENOMEM when memory is tight. Who says that > > > an impl

Re: [PATCH v1] xstrtol: Remove dead code

On Fri, Jul 19, 2024 at 12:14:19AM GMT, Alejandro Colomar wrote: > [CC -= Andrew, per explicit request] > > On Thu, Jul 18, 2024 at 11:25:11PM GMT, Alejandro Colomar wrote: > > On Thu, Jul 18, 2024 at 11:09:40PM GMT, Bruno Haible wrote: > > > Hi Alejandro, > > Hi B

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 > > beha

[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

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

stray less from strtol") Cc: Paul Eggert Cc: Bruno Haible Cc: Đoàn Trần Công Danh Cc: Eli Schwartz Cc: Sam James Cc: Serge Hallyn Cc: Iker Pedrosa Cc: Michael Vetter Cc: Signed-off-by: Alejandro Colomar --- lib/xstrtol.c | 35 +-- 1 file changed, 21 i

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

rt Cc: Bruno Haible Cc: Đoàn Trần Công Danh Cc: Eli Schwartz Cc: Sam James Cc: Serge Hallyn Cc: Iker Pedrosa Cc: Michael Vetter Cc: Signed-off-by: Alejandro Colomar --- lib/xstrtol.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/xstrtol.c b/lib/xstrtol.c index

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" (w

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 "

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 exc

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 --

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. > > T

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 rea

[PATCH] lib/xstrtol.c: Fix xstrtol() on EINVAL (invalid base)

ot;xstrtol: document and stray less from strtol") Fixes: 16b33e664942 (2024-07-19, "xstrtol: be more robust against odd failures") Link: <https://mail-index.netbsd.org/tech-misc/2024/07/20/msg000412.html> Reported-by: Robert Elz Cc: Paul Eggert Cc: Bruno Haible Signed-off-by: Alejand

Re: [PATCH] lib/xstrtol.c: Fix xstrtol() on EINVAL (invalid base)

On Wed, Jul 24, 2024 at 09:27:14PM GMT, Alejandro Colomar wrote: > POSIX leaves the value of *endptr unspecified if the base is invalid; > it is not unmodified. > > glibc and musl libc leave the object unmodified. However, the BSDs and > Bionic libc modify it to be nptr. > >

Re: [PATCH] lib/xstrtol.c: Fix xstrtol() on EINVAL (invalid base)

Hi Paul, On Wed, Jul 24, 2024 at 01:11:33PM GMT, Paul Eggert wrote: > On 2024-07-24 12:27, Alejandro Colomar wrote: > > POSIX leaves the value of *endptr unspecified if the base is invalid; > > it is not unmodified. > > Fine, we can let xstrtol do the same. > > >

Re: [PATCH] lib/xstrtol.c: Fix xstrtol() on EINVAL (invalid base)

On Wed, Jul 24, 2024 at 10:54:52PM GMT, Alejandro Colomar wrote: > Hi Paul, > > On Wed, Jul 24, 2024 at 01:11:33PM GMT, Paul Eggert wrote: > > On 2024-07-24 12:27, Alejandro Colomar wrote: > > > POSIX leaves the value of *endptr unspecified if the base is invalid; &g

Re: [PATCH] lib/xstrtol.c: Fix xstrtol() on EINVAL (invalid base)

Hi Paul, On Wed, Jul 24, 2024 at 05:09:09PM GMT, Paul Eggert wrote: > On 2024-07-24 14:07, Alejandro Colomar wrote: > > > I forgot to reply to the last part: "Why isn't that [current gnulib] > > good enough? > > > > With an implementation of strtol(3) th

Re: [PATCH] lib/xstrtol.c: Fix xstrtol() on EINVAL (invalid base)

Hi Paul, On Thu, Jul 25, 2024 at 07:55:15AM GMT, Paul Eggert wrote: > On 2024-07-25 02:27, Alejandro Colomar wrote: > > - tmp = 1; > > > > We will multiply the base by 1, even if it wasn't in the string. > > I don't see that. There's no multip

Re: [PATCH] lib/xstrtol.c: Fix xstrtol() on EINVAL (invalid base)

On Thu, Jul 25, 2024 at 06:39:53PM GMT, Alejandro Colomar wrote: > Hi Paul, > > On Thu, Jul 25, 2024 at 07:55:15AM GMT, Paul Eggert wrote: > > On 2024-07-25 02:27, Alejandro Colomar wrote: > > > - tmp = 1; > > > > > > We will multiply the base by 1, e

parse_datetime() and RFC 9557 suffixes

Hi Paul, As reported earlier today in parse_datetime() cannot handle the suffix specified in RFC 9557. $ date --date='2023-09-20[+0200]' date: invalid date ‘2023-09-20[+0200]

Re: parse_datetime() and RFC 9557 suffixes

Hi Paul, Bruno, On Thu, Aug 01, 2024 at 03:10:29PM GMT, Paul Eggert wrote: > The whole business of time zone offsets is a mess. :) > Third, RFC 9557 does not allow either "2023-09-20[+02:00]" or > "2023-09-20[+0200]". It requires a time before the timezone. (This issue is > minor; I've already m

Re: date without time

Hi Bruno, On Fri, Aug 02, 2024 at 10:42:03AM GMT, Bruno Haible wrote: > Alejandro Colomar wrote: > > However, I'd say that's more likely to be that the authors of RFC 9557 > > didn't think of dates without time (maybe they didn't think of a case > > where

Re: date without time

Hi Bruno, On Fri, Aug 02, 2024 at 12:50:59PM GMT, Bruno Haible wrote: > Alejandro Colomar wrote: > > A day-precission timestamp is a timestamp at any point of that day. > s/precission/precision/ (note that precession is yet another thing). Thanks! There are several words wh

Re: date without time

Hi Serge, On Fri, Aug 02, 2024 at 01:47:40PM GMT, Alejandro Colomar wrote: > Hi Bruno, > > On Fri, Aug 02, 2024 at 12:50:59PM GMT, Bruno Haible wrote: > > Alejandro Colomar wrote: > > > A day-precission timestamp is a timestamp at any point of that day. > > s/pr

Re: [PATCH v1] realloc: Be consistent with malloc

Hi Paul, On Fri, Oct 18, 2024 at 04:24:32PM GMT, Paul Eggert wrote: > [cutting the cc list down to bug-gnulib] > > Surely that's not enough; we'd need to replace realloc on current glibc > platforms, and not replace realloc on hypothetical future glibc platforms > that behave more compatibly with

Re: [PATCH v1] realloc: Be consistent with malloc

Hi Bruno, On Sat, Oct 19, 2024 at 10:25:52AM GMT, Bruno Haible wrote: > Paul Eggert wrote: > > For gnulib readers: this new bug-gnulib thread is following up on this > > long libc-alpha thread: > > > > https://sourceware.org/pipermail/libc-alpha/2024-October/160645.html > > Thanks for the conte

Re: realloc: Improve documentation

Hi Bruno, On Sat, Oct 19, 2024 at 02:23:50PM GMT, Bruno Haible wrote: > I wrote: > >According to our doc, there are three possible behaviours of the realloc > >function: > >With a non-NULL pointer argument p, C17 says that it is > >implementation-defined whether realloc (p,

Re: [PATCH v1] realloc: Be consistent with malloc

Hi Paul, On Sat, Oct 19, 2024 at 11:24:08AM GMT, Paul Eggert wrote: > On 2024-10-19 09:14, Alejandro Colomar wrote: ... > > On Sat, Oct 19, 2024 at 10:25:52AM GMT, Bruno Haible wrote: ... > > > What I would therefore suggest — if we want to change Gnulib at all > >

[PATCH v1] realloc: Be consistent with malloc

li.xyz/content/blogn_t/017-malloc0.html> Link: <https://inbox.sourceware.org/libc-alpha/t7low35raw7dodsie7umqbnddpm7q2eenkbv5lafesrqrisudn@zqvuq3izem6t/T/#t> Suggested-by: Alejandro Colomar Suggested-by: наб Suggested-by: Douglas McIlroy Suggested-by: Paul Eggert Cc: Siddhesh Poyarekar Cc: Joseph Myers Signed-off-by: Alejandro Colo

Re: realloc: Improve documentation

On Sat, Oct 19, 2024 at 02:23:44PM GMT, Paul Eggert wrote: > Thanks. Some further improvements: > > * Document whether realloc can fail when not growing a region. > > * Mention what happens to errno. > > * Mention how the ISO C standard has evolved here. > > * Give more details as to which glib

gnulib-manywarnings: Enable -Wzero-as-null-pointer-constant

Hi Bruno, Link: Link: GCC 15 has added -Wzero-as-null-pointer-constant for C (or actually, will, once it's released). We're planning a path for deprecation of 0 as a null point

Re: NULL with xlc

Hi Paul, On Thu, Nov 14, 2024 at 07:51:24PM GMT, Bruno Haible wrote: > Paul Eggert wrote: > > > Maybe we should override NULL on this platform (where it is defined as 0)? > > > > I wouldn't mess with NULL, as too much oddball stuff depends on it. > > I would mess with it only when a configure te

Re: gnulib-manywarnings: Enable -Wzero-as-null-pointer-constant

Hi Bruno, On Thu, Nov 14, 2024 at 04:14:26PM GMT, Bruno Haible wrote: > I promised: > > - see how this new warning behaves on the Gnulib source code Thanks! > The two good news are: > - The warning is really helpful. With it, I could find all relevant uses of > '0' quickly. Patch attache

Re: [PATCH] fix descriptions for AT_NO_AUTOMOUNT

(7) for when to put a number and when not: Formatting conventions for manual pages describing functions [...] Any reference to the subject of the current manual page should be written with the name in bold followed by a pair of parentheses in Roman (normal) font. For exampl

Re: [PATCH] fix descriptions for AT_NO_AUTOMOUNT

On 3/14/22 19:02, Pádraig Brady wrote: > On 14/03/2022 13:24, Alejandro Colomar (man-pages) wrote: >> On 3/10/22 14:46, Pádraig Brady wrote: >>> Subject: [PATCH] fix descriptions for AT_NO_AUTOMOUNT >>> >>> Don't mention AT_NO_AUTOMOUNT for fstatat

Re: [PATCH] fix descriptions for AT_NO_AUTOMOUNT

Hi Pádraig, On 3/14/22 20:56, Alejandro Colomar (man-pages) wrote: > Please send the patch inline (or both inline and attached), > if you don't mind. > However, if it's a big hassle for you, > I can apply it from an attachment. Thanks for the inline patcx. > --- >