-fsigned-char on all arches

[Will Newton]

On 4/12/07, Rob Landley <rob at landley.net> wrote:

> > I count 10 warnings in 3 source files (all printf/scanf related).

My point was that this required only approx. 10 casts to fix these warnings btw.

> To clarify: C strings are "char *", with no signed or unsigned specifier, and
> standards like POSIX say that headers have to use "char *" in a bunch of
> places.  If it wasn't for this, we could explicitly specify "signed"
> or "unsigned" every time we declared a char or char *, which would be exactly
> the same result but you wouldn't notice the compiler flag to complain about
> it.  So we specify it at the compiler flag level, to get consistent behavior.

I believe this ambiguity in the definition of "char" was intended to
allow the implementation to choose the most efficient implementation
of the datatype. Pulling -fsigned-char on all architectures disallows
this efficiency.

Is there a reason why signed char has been made the default rather
than unsigned char? Because i386 is signed? Almost all embedded (i.e.
modern RISC type) architectures default to unsigned chars. ARM saves
approx 1k of text size on libuClibc.so if built without -fsigned-char.

> > > Which architecture are you referring to?
> >
> > http://www.imgtec.com/metagence/products/
>
> Never heard of it.

I don't work for the PR department. ;-)

We're an IP vendor so our name is very rarely on the box.

> The "target architecture" menu of uClibc lists alpha, arm, bfin, cris, hppa,
> i386, ia64, m68k, mips, nips, nips2, powerpc, superh, sh64, sparc, vax, and
> x86_64.  It also lists the following as broken: v850, microblaze, i960,
> h8300, frv, and e1.
>
> Which one are you referring to?

We have our own tree based on uClibc svn. We hope to merge it into
mainline uClibc at some point in the future.