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

[Francesco Sacchi]

Eric Weddington ha scritto:
> And if the end-user doesn't have those flags, or isn't aware of them, then
> they will get signed chars and enums that take up 16-bits.

Sorry Eric but I am totally disagree with you.
Chars can be signed or unsigned, but if you write correct portable code 
signedness is not an issue. In my code I never noticed the warning which 
you are talking about. I know the -funsigned-char flag but I don't use 
it, and if I'll decide to use nothing will break.

So if the end-user doesn't know the flags but write good code I can't 
see the problem: when he will discover the flag he could shrink a bit 
code size.

Now let's talk about enums.
By C standards, enums are threated as ints and I write portable code 
with this statement in mind. If someone suddenly changes compiler 
behavior, reducing enums size to be less than an int, some code might 
break and might be not portable.

> I concede the point about the warnings in 4.x; the warnings are correct and
> they should be there. But it still doesn't make sense for the AVR port to
> have signed chars and 16-bit enums. Changing the port to be otherwise will
> not incur widespread application failure; we'll be lucky to get 1 or 2 minor
> complaints. I'd rather change the port, then to constantly remind end-users
> to use those flags in their Makefiles.

Trust me Eric, there are a lot of people that don't use WinAVR, not 
because is bad, but because they don't use windows at all :)

So, WinAVR users will get no benefits from this change cause the flags 
are already included in makefile you supply. To the rest of the world 
this change can suddenly break code, so I agree with Joerg when he says 
that consistency now is more important that a few hundred of code bytes 
saved.

I made a simple test, I took a large ATMega64 project and recompiled 
with -funsigned-char and -fshort-enums.

The code shrinks only about 200 bytes on an a total size of 59800.
This is only a 0.33% gain. It doesn't definitely worth the effort.

--
_|/ Francesco Sacchi - Develer S.r.l., R&D dept.
 |\ http://www.develer.com/