Re: [avr-gcc-list] New GCC warning - how to silence?

[Joerg Wunsch]

As Eric Weddington wrote:

> > Please don't.  Consistency is more important now.  This change
> > might have been appropriate about 7 years ago.

> What?! To be consistent?!

Sure.  After all, there's the slight chance that *someone* out there
(not a WinAVR user, likely) could have written code that relies on the
signedness of the default char.  Sure, he *should* not do this, and
GCC 4.x basically tells that everybody now, but by changing it right
now, you would break that user's code without reason.

> The makefile template that has been shipping with WinAVR since 2002
> has consistently had -funsigned-char and -fshort-enums in the
> compiler flags.

So what?  WinAVR users will neither be affected nor benefit in any way
from your suggested changes.  Moot point.  Please leave it as it is
then.

> What I don't understand is why -funsigned-char doesn't seem to work
> like it did in 3.4.x.

It does.

> > Rather not.  You can always force an enum to its shortest form by
> > using __attribute__((packed)), but there's nothing like
> > __attribute__((nopacked)) which you could use to turn the enum
> > into an int type when it defaults to a smaller size.

> No. See my comment above about -fshort-enums. The user can, and most
> likely has, been using this.

Then, what's the point to change the compiler's defaults?

> We always talk about how code size matters, and complain about how
> GCC always wants to use int for everything when it can use a byte,
> but now you advocate the exact opposite: to use an int for enums
> when it can be made smaller.

After all, in C, an enum is first of all an int.  (This is one of the
things where C++ is different.)

> If that target hook is defined, it just means that it will use the
> smallest size needed.

With no way to make it a realy int, even if the programmer wants it
that way.  At least, not with an individual (per-enum) way, only
-fno-short-enums will probably do it, but then, it would change
everything.

> Right now, they're dealing with all the idiocy
> of "char versus uint8_t" that 4.x is creating.

This is not an "idiocy", it's a portability warning.  If someone mixes
an unqualified char with an either signed or unsigned char, he's
simply beyond any guarantees of the standard.  That's all the warning
is going to tell the users: just don't do that.  Use typecasts if you
have to convert between an unqualified and a qualified char.

> All of the avr-libc functions
> (the string functions in particular) use char.

Sure, because they are working on printable characters.

> Many end users have now gotten so used to creating strings as
> "uint8_t *" that now they're getting all these warnings.

They are getting warnings not because they are using uint8_t (they
would get the *same* warnings if they were using int8_t, mind you),
but because they have been careless about their char types.

You can call that an idiocy of the C language itself, and I'll
probably agree with you on that: for all other integer types, they are
implicitly signed unless the "unsigned" keyword is written, not so for
char.  That one is either implicitly signed *or* unsigned, and has to
be qualified signed explicitly.

> I say, be done with it, make these two changes, rebuild everything
> and have it Just Work, like the way the end-users expect.

Again, I'm against it.  You WinAVR users won't be affected by the
suggested changes anyway (and won't benefit from them either), and as
they are saying: ``If it ain't broken, don't fix it.''

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)