Re: sys_un: New module.

Hi Bruno, The warnings say: > ../gllib/string.h:809:20: error: declaration of 'memchr' has a different > language linkage > 809 | _GL_CXXALIASWARN1 (memchr, void *, > |^ > /usr/include/string.h:94:1: note: previous definition is here >94 | memc

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

On 2024-07-25 14:27, Bruno Haible wrote: I have a hard time understanding the point and purpose of what you are saying: - In you removed the validation of 'base', saying: "strtol can support base 1 as an extensi

Re: sys_un: New module.

Bruno Haible writes: > Forgot to say: The continuous integration uses a testdir of all modules. > But probably a testdir of 'sys_un' and 'memchr' will be sufficient to > reproduce it. Thanks, that reproduces it on my Fedora 40 machine. I had assumed GNULIB_NAMESPACE was supposed to be defined i

Re: sys_un: New module.

I wrote: > The continuous integration detected a compilation failure on > Ubuntu 22.04, with clang 18 as compiler: Forgot to say: The continuous integration uses a testdir of all modules. But probably a testdir of 'sys_un' and 'memchr' will be sufficient to reproduce it. Bruno

Re: sys_un: New module.

Hi Bruno, Bruno Haible writes: > The continuous integration detected a compilation failure on > Ubuntu 22.04, with clang 18 as compiler: [...] > Can you please find a workaround? Thanks for letting me know. I'll have a look in a bit. Collin

Re: sys_un: New module.

Hi Collin, > Here is the sys_un module as promised + typical C/C++ header checks. The continuous integration detected a compilation failure on Ubuntu 22.04, with clang 18 as compiler: clang++ -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -I. -I../../gltests -I.. -DGNULIB_STRICT_CHECKING=1 -DIN_G

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

> xstrtol, xstrtoll tests: Test behaviour for an invalid base. The CI reported a failure on FreeBSD (not on NetBSD, not on OpenBSD). This patch makes the test succeed. 2024-07-25 Bruno Haible xstrtol, xstrtoll tests: Avoid test failure on FreeBSD. * tests/test-xstrtol.

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

Hi Paul, > > +strtol_error s_err = __xstrtol (input, &endp, -1, &val, "k"); > > +ASSERT (s_err == LONGINT_INVALID); > > +ASSERT (endp == NULL); > > +ASSERT (val == -17); > > This isn't a valid test case. If the base is -1, the underlying strtol > can support any b

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

Paul Eggert writes: > If the documentation doesn't make it sufficiently clear that the > behavior is not fully specified with an invalid base, we can do that. > But let's not waste time testing corner cases that don't matter. +1. I don't see why anyone would ever pass -1 as a base to strtol. Usu

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

On 2024-07-25 13:11, Bruno Haible wrote: +strtol_error s_err = __xstrtol (input, &endp, -1, &val, "k"); +ASSERT (s_err == LONGINT_INVALID); +ASSERT (endp == NULL); +ASSERT (val == -17); This isn't a valid test case. If the base is -1, the underlying strtol can s

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

Alejandro Colomar wrote: > > > Assuming that the string matches a valid suffix, it'd succeed, but the > > > call should have failed early. > > > > No, because that code is dealing with the case where the number's text is > > missing. And if the number's text is missing it doesn't matter what the b

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

On 2024-07-25 09:39, Alejandro Colomar wrote: So, we have arrived there, tmp is 1, and the suffix is "k", so it will be multiplied by 1000. That's the expected behavior. I passed a base of -1. Fine, so don't do that. When you use base -1, it doesn't matter whether the behavior differs on

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, even if it wasn't in the string. > > > > I

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 multiplication of BASE by 1 in "tmp = 1;". D'oh, sorr

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

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 multiplication of BASE by 1 in "tmp = 1;". I don't understand too much the rest of xstrtol(), but I think it will successfully pars

Re: sys_un: New module.

Looks all good. Thanks! Bruno

Re: continuous integrations pipeline frameworks

Bruno Haible writes: > By now, I've completed a "many platforms" CI for several GNU packages: > > https://github.com/gnu-gnulib/ci-testdir-check/actions > https://github.com/gnu-diffutils/ci-check/actions > https://github.com/gnu-gettext/ci-check/actions > https://github.com/gnu-libsigsegv/ci-che

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) that does what I wrote above, the > > test `