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

[Rolf Magnus]

On Sonntag, 8. April 2007, Francesco Sacchi wrote:
> 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.

The underlying integer type is implementation-defined. It need not be int.

> If someone suddenly changes compiler behavior, reducing enums size to be
> less than an int, some code might break and might be not portable.

Then it's an error in that code.

> > 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 :)

I could raise my hand here.

> 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.

Where do those savings come from?