-fsigned-char on all arches

[Rob Landley]

On Friday 13 April 2007 7:29 am, Will Newton wrote:
> 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. 

It's still wrong.  You're just pointing out it's a finite wrong.

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

And back in the 1970's when that was relevant, "char" wasn't guaranteed to be 
8 bits either.  On some platforms it was 12 bits.  These days, such crappy 
platforms have gone the way of the dodo.

You could make the exact same argument for short, int, and long.  And yet 
those data types don't have a built-in indeterminacy.  Instead for current 
32-bit and 64-bit systems we actually have a standard 
(http://www.unix.org/whitepapers/64bit.html with rationale 
http://www.unix.org/version2/whatsnew/lp64_wp.html) specifying how many bits 
each type has.  This is because most modern chips aren't crap, and can 
actually support all this reasonably.

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

I don't know, ask Mike.  As I said, I chose unsigned for busybox.  I suspect 
he wanted to make "char" behave the same way as "short", "int", and "long", 
which is a reasonable approach.  For Busybox, I liked our string handling 
being naturally 8-bit clean and that this didn't bloat arm (and with only 
43,000 transistors arm has to be the minimal bar to compare other chips to.  
If they can't do as good a job as arm, they really shouldn't be bothering).  
It also didn't bloat x86/x86-64, and between arm and x86/x86-64 that covers 
something like 90% of all processors ever produced.  (And I believe the next 
biggest category, by volume, is variants of the Z80...)

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

So you have a currently closed source, undistributed, out-of-tree fork.  If it 
had been merged, Mike might have noticed the change inconvenienced you when 
he made it, but it wasn't, so he didn't.

Wake me when you have public code.  Until then, I don't care enough to 
continue this conversation.  (Not that I'm the person you'd need to convince 
anyway: Mike is.)

Rob
-- 
Penguicon 5.0 Apr 20-22, Linux Expo/SF Convention.  Bruce Schneier, Christine 
Peterson, Steve Jackson, Randy Milholland, Elizabeth Bear, Charlie Stross...