svn commit: trunk/uClibc: include

[Denys Vlasenko]

On Monday 12 January 2009 14:07, Bernd Schmidt wrote:
> >> Rules.mak: add -funsigned-char, to forestall future PITA
> 
> Yeah, that's just wrong for all the reasons given in the old thread.
> Please revert if you haven't already.

Old thread said generated code for -fsigned-char is bigger
on ARM. It also said there are no benefits to having char signed.

But unsigned char, on the opposite, does have benefits!

All bugs caused by improper widening of char to int
I ever met were triggering by chars >= 0x80 being negative.
If we make it impossible, we may have a few bugs less.

I do not advocate writing sloppy code. I advocate
using defense in depth: write good code (in this case,
code which will work with either char signedness),
but then use compiler switches which make latent bugs
less likely to bite us.

For example: any macros in headers must not assume
that char type has particular signedness.

I can imagine there is an architecture where making char
unsigned would lead to bigger code. But I also can imagine
architecture with 36-bit words, you know.
Does anyone actually know any architecture we care about
which does not like unsigned chars?
--
vda