Hi Paul,
Paul Eggert wrote,
> On 2024-08-21 14:25, Waldemar Brodkorb wrote:
> > -#if defined __GLIBC__ && 2 < __GLIBC__ + (2 <= __GLIBC_MINOR__)
> > +#if defined __GLIBC__ && 2 < __GLIBC__ + (2 <= __GLIBC_MINOR__) &&
> > !defined __UCLIBC__
>
> Thanks, I installed the attached into Gnulib.
Than
On 2024-08-21 14:25, Waldemar Brodkorb wrote:
-#if defined __GLIBC__ && 2 < __GLIBC__ + (2 <= __GLIBC_MINOR__)
+#if defined __GLIBC__ && 2 < __GLIBC__ + (2 <= __GLIBC_MINOR__) && !defined
__UCLIBC__
Thanks, I installed the attached into Gnulib.From 9765bc796b3e6ceaa7a10ba07c9c2f1e272a4249 Mon
Paul Eggert writes:
>> that 'return (struct ...) { initializers }'
>> produces particularly good code with modern compilers)
>
> Yeah, that's partly why I weighed in on this seemingly-obscure topic.
> I like the more-functional style and wouldn't want "undefined
> behavior" to get in its way
On 2024-08-21 06:36, Bruno Haible wrote:
In summary, this paragraph makes no sense for structs.
Hmm, well, the paragraph makes sense to me. I suppose somebody could
fire off a question to the C committee about the intent of the paragraph.
In the meantime it's an engineering decision - should
Collin Funk wrote:
> Bruno, can mbszero be used here instead of duplicating the #if
> conditions? Isn't it achieving the same thing?
>
> Assuming that it will be inlined and:
>
> memset (&mbs, 0, 4);
>
> performs the same as:
>
>mbs.__count = 0;
Right, mbszero() could be used here inst
Waldemar Brodkorb writes:
> Would be following trivial patch acceptable, which fixes the issue for me?
>
> diff --git a/lib/mcel.h b/lib/mcel.h
> index 7d92d24601..d000bfeb5d 100644
> --- a/lib/mcel.h
> +++ b/lib/mcel.h
> @@ -226,7 +226,7 @@ mcel_scan (char const *p, char const *lim)
>
>/*
On Linux/riscv64 with musl libc, I see this compilation error in a testdir of
all of gnulib:
In file included from ../gllib/sys/select.h:131,
from /usr/include/sys/time.h:9,
from ../gllib/sys/time.h:46,
from ../gllib/sys/select.h:102,
Hi Gnulib developers,
I tried to update coreutils from 9.4 to 9.5, but it does not compile.
It fails with:
In file included from lib/mcel.c:3:
lib/mcel.h: In function 'mcel_scan':
lib/mcel.h:226:21: error: 'mbstate_t' has no member named '__count'
226 | mbstate_t mbs; mbs.__count = 0;
Paul Eggert wrote:
> > Copying and then discarding an uninitialized value of integer
> > or pointer type (i.e. not a signalling NaN (*)) is not undefined behaviour.
>
> Although that's how typical implementations behave, the C standard says
> that copying from a source variable has undefined beha
