Re: (un)signed char (was Re: wmappl)

["Albert D. Cahalan" <acahalan@cs.uml.edu>]

Bastien Nocera writes:

> For kicks, read paragraph I there:
> http://www.alumni.caltech.edu/~pje/soskr.html

That rant is wrong in many ways.

The "if (x=5)" problem would best be fixed by
using ":=" for assignment. Typing is strong enough
as it is, annoyingly so when trying to align pointers
with bit operations. You don't need a bool.

The "char" type was signed. It did not need to be
specified; it could not be anything but signed
since the "signed" keyword did not exist.

For performance, the default should have been that
the compiler could mix signed and unsigned operations
as desired. (you get a 7-bit char with 1 padding bit,
a range of 0..127, overflow behavior is random, and
no this doesn't really prevent using that extra bit
when dealing with text)

This isn't Pascal. C supports Duff's device for
unrolling loops:

tmp = counter >> 2;
switch(counter & 3){
  while(x--){
    foo();
case 3:
    foo();
case 2:
    foo();
case 1:
    foo();
case 0:
  }
}

In keeping with the spirit of C, a "missing" case
should invoke undefined behavior. (letting the compiler
optimize a bit more, not needing to check for boundry
conditions)




-- 
To UNSUBSCRIBE, email to debian-powerpc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org