warnings from MacOS clang

warnings from MacOS clang

[arnold]

Hi.

I got the below from one of my testers. If y'all feel like updating the
relevant files in GNULIB, that'd be great. If instead you feel like,
well, to heck with that, that's also OK. :-)

Thanks,

Arnold

> From: Pat Rankin <r.pat.rankin@gmail.com>
> Date: Mon, 10 May 2021 18:13:33 -0700
>
> > https://www.skeeve.com/gawk/gawk-5.1.1c.tar.gz
>
> OSX 10.11.6
> Building after using 'touch .developing' for the first time, I get
>
> depbase=`echo dfa.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
> gcc -DGAWK -DHAVE_CONFIG_H -I"./.." -I. -I..   -I/opt/local/include
> -I/opt/local/include -g -O2 -DARRAYDEBUG -DYYDEBUG -DLOCALEDEBUG
> -DMEMDEBUG -Wall -fno-builtin -g3 -ggdb3 -g -O2 -DARRAYDEBUG -DYYDEBUG
> -DLOCALEDEBUG -DMEMDEBUG -Wall -fno-builtin -g3 -ggdb3 -MT dfa.o -MD
> -MP -MF $depbase.Tpo -c -o dfa.o dfa.c &&\
> mv -f $depbase.Tpo $depbase.Po
>
> dfa.c:1627:19: warning: suggest braces around initialization of subobject
>       [-Wmissing-braces]
>   mbstate_t s = { 0 };
>                   ^
>                   {}
> 1 warning generated.
>
> Also two similar warnings from localinfo.c, lines 47 and 103.
> [Note: despite being invoked as 'gcc' the compiler is 'clang'
> and not a particularly recent version.]
>
> Even with warnings, the build completed successfully.
> All tests passed.
>

Re: warnings from MacOS clang

[Bruno Haible]

Hi Arnold,

> > OSX 10.11.6
> > Building after using 'touch .developing' for the first time, I get
> >
> > depbase=`echo dfa.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
> > gcc -DGAWK -DHAVE_CONFIG_H -I"./.." -I. -I..   -I/opt/local/include
> > -I/opt/local/include -g -O2 -DARRAYDEBUG -DYYDEBUG -DLOCALEDEBUG
> > -DMEMDEBUG -Wall -fno-builtin -g3 -ggdb3 -g -O2 -DARRAYDEBUG -DYYDEBUG
> > -DLOCALEDEBUG -DMEMDEBUG -Wall -fno-builtin -g3 -ggdb3 -MT dfa.o -MD
> > -MP -MF $depbase.Tpo -c -o dfa.o dfa.c &&\
> > mv -f $depbase.Tpo $depbase.Po
> >
> > dfa.c:1627:19: warning: suggest braces around initialization of subobject
> >       [-Wmissing-braces]
> >   mbstate_t s = { 0 };
> >                   ^
> >                   {}
> > 1 warning generated.

{ 0 } is the only portable initializer for an mbstate_t. If we were to use
another initializer, it would make assumptions about the structure of an
mbstate_t. That is, #ifdefs.

Another option was to use to portable initializer, but use
memset (&s, '\0', sizeof (s)) to initialize the variable.
This is ugly BSD style of the 1980ies, which we have abandoned
more than 10 years ago.

Bruno

Re: warnings from MacOS clang

[Eric Blake]

On Wed, May 12, 2021 at 12:16:54PM +0200, Bruno Haible wrote:
> > > dfa.c:1627:19: warning: suggest braces around initialization of subobject
> > >       [-Wmissing-braces]
> > >   mbstate_t s = { 0 };
> > >                   ^
> > >                   {}
> > > 1 warning generated.
> 
> { 0 } is the only portable initializer for an mbstate_t. If we were to use
> another initializer, it would make assumptions about the structure of an
> mbstate_t. That is, #ifdefs.

Unfortunately, although C declares { 0 } to be the universal
initializer, there are some compilers (such as older clang versions,
like the one on MacOS) that incorrectly warn for it in certain cases
(gcc used to have problems with it, too).

Using 'mbstate_t s = { };' would work on gcc and clang (even those
older versions that warn on { 0 }), but is not portable C.  Maybe the
compromise is to define a macro that expands to empty on gcc/clang and
to 0 otherwise, as in 'mbstate_t s = { ZERO_INIT };' ?

> 
> Another option was to use to portable initializer, but use
> memset (&s, '\0', sizeof (s)) to initialize the variable.
> This is ugly BSD style of the 1980ies, which we have abandoned
> more than 10 years ago.

Yet another portable solution is:

static mbstate_t s1;
mbstate_t s = s1;

also with its own form of ugliness.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: warnings from MacOS clang

[Paul Eggert]

On 5/27/21 1:46 PM, Eric Blake wrote:

> Yet another portable solution is:
> 
> static mbstate_t s1;
> mbstate_t s = s1;
> 
> also with its own form of ugliness.

I did that years ago, but compilers complained about it when I made s1 
'const', and I vaguely recall complaints even when it wasn't 'const' 
("What? You're declaring a static variable that is always zero and never 
changes? That must be a bug!!").

At this point I wouldn't worry about the older clang and gcc versions 
that complain about {0} as an initializer. We can either let them die 
off noisily, or use the appropriate -Wno-whatever option when using them 
to compile.

Re: warnings from MacOS clang

[arnold]

Paul Eggert <eggert@cs.ucla.edu> wrote:

> On 5/27/21 1:46 PM, Eric Blake wrote:
>
> > Yet another portable solution is:
> > 
> > static mbstate_t s1;
> > mbstate_t s = s1;
> > 
> > also with its own form of ugliness.
>
> I did that years ago, but compilers complained about it when I made s1 
> 'const', and I vaguely recall complaints even when it wasn't 'const' 
> ("What? You're declaring a static variable that is always zero and never 
> changes? That must be a bug!!").
>
> At this point I wouldn't worry about the older clang and gcc versions 
> that complain about {0} as an initializer. We can either let them die 
> off noisily, or use the appropriate -Wno-whatever option when using them 
> to compile.

I've decided to just not worry about it. It's impossible to compile
without warnings on every single C compiler in the world.

Thanks,

Arnold

Re: warnings from MacOS clang

[Simon Josefsson via Gnulib discussion list]

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

arnold@skeeve.com writes:

>> At this point I wouldn't worry about the older clang and gcc versions 
>> that complain about {0} as an initializer. We can either let them die 
>> off noisily, or use the appropriate -Wno-whatever option when using them 
>> to compile.
>
> I've decided to just not worry about it. It's impossible to compile
> without warnings on every single C compiler in the world.

Indeed, and further, I believe that changing code to silence warnings
from any non-modern or preferred compilers is counter-productive.  Even
further, I also believe that if we run into a situation where modern gcc
(or clang?) produces a warning we don't agree with, we should try to get
that fixed in the compiler and not make any code change.

This approach unfortunately implies that we can't add -Werror to the
default flags, something I earlier thought was a nice goal, but have
reconsidered: it is better to have warnings for things we believe the
compiler shouldn't warn about, than to modify code to silence the
compiler, even if it is a modern gcc.  In an ideal world, compilers
shouldn't warn about things we believe it shouldn't warn about, but
we'll never reach it so we shouldn't use -Werror.

/Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]