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

[Eric Weddington]

> > > It is interesting, what was a reason to declare
> > > default char as signed for AVR port?
> 
> Right now, there *is* a reason: consistency.  We've always had it that
> way.
> 
> > > Many other GCC ports use unsigned.
> 
> I guess Denis "inherited" it from the i386 port that also defaults to
> signed chars.

Fair enough.
 
> > So this means that the AVR defaults to a signed char. Can we change
> > this to be unsigned?:
> 
> Please don't.  Consistency is more important now.  This change might
> have been appropriate about 7 years ago.

What?! To be consistent?!

The makefile template that has been shipping with WinAVR since 2002 has
consistently had -funsigned-char and -fshort-enums in the compiler flags.
These are two of the few flags that are exposed in the GCC plugin to AVR
Studio. It's almost ridiculous to have a signed char on an 8-bit embedded
micro. I can understand that it was possibly an oversight when the port was
initially created, so I certainly don't blame Denis at all. What I don't
understand is why -funsigned-char doesn't seem to work like it did in 3.4.x.
If we can fix it by changing the target definition then all the better. See
more below.


> > For that matter, can we also define this target hook:
> 
> > TARGET_DEFAULT_SHORT_ENUMS
> 
> > And have it return true?
> 
> 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. 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. If that target hook is defined, it just means
that it will use the smallest size needed. If somebody decides to declare a
256 element enumeration, then it will use an int.

Joerg, you mention "backwards compatibility" a lot regarding being
conservative on changes, and I respect that. But show me how these changes
will so greatly impact "backwards-compatibility" that it will be difficult
for the end-user to swallow. Right now, they're dealing with all the idiocy
of "char versus uint8_t" that 4.x is creating. All of the avr-libc functions
(the string functions in particular) use char. Many end users have now
gotten so used to creating strings as "uint8_t *" that now they're getting
all these warnings. And, if I may remind you, that even a certain 802.15.4
stack we know uses these "uint8_t *" strings. ;-)

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

Eric Weddington