signed/unsigned char/short/int/long

T. William Wells bill at twwells.uucp
Fri Dec 23 20:37:32 AEST 1988


In article <440 at aber-cs.UUCP> pcg at cs.aber.ac.uk (Piercarlo Grandi) writes:
: #    Your previous postings have adduced falsehoods to support what is, after
: #    all, just
:
: Falsehoods: what a big word.  You cannot just disagree with my arguments, you
: call them lies. I could be proud of this... ;-{

A deliberate word. If I wanted to call them lies, I would. A falsehood
is just that: something not true. I don't know why you said them. It
could be that you are repeating rumors. Or that you have formed your
conclusions without reasons. Or that you have a bad memory. Or that
you misunderstood what you have read. Or that you have been mislead
by someone else. Or that you were on drugs. Or that you invent things
and convince yourself of the reality of your invention; I have a
brother with this almost-psychosis. Or something else. I don't know.
What I do know is that many "facts" that you have supplied just
aren't so.

: I have tried to persuade you that I have read Ritchie's work, that it is
: sufficiently precise in some points and ambiguous in others (save for one
: critical point) to support my interpretation. Isn't that enough?

Well, to repeat what damn near everyone else has said: your
interpretation of K&R is inconsistent with every informed person's
interpretation of K&R. Not only that, but it is inconsistent with C
practice. So, what we have seen is that your interpretation is
essentially word games and logic chopping; thus your contentions are
not supported, no matter what you may wish.

: [Classic C]           (unsigned) char
:                       (unsigned) (short|long) int
:
: [dpANS C]             (signed|unsigned) char
:                       (signed|unsigned) (short|long) int
:
: [My proposal]         (char|short|long) unsigned
:                       (char|short|long) int

Ok, I see that I missed something in your postings.  And, BTW, you
could have saved yourself lots of typing had you stopped at this
point. Having shown that my premise was incorrect, refuting the rest
of my posting was a waste of time.

Now, back to tables.

dpANS C                 Your proposal           comment

char                    char
signed char             char int                different
unsigned char           unsigned char
short (int)             short (int)
unsigned short (int)    unsigned short          unsigned short int is illegal
int                     int
unsigned (int)          unsigned                unsigned int is illegal
long (int)              long (int)
unsigned long (int)     unsigned long           unsigned long int is illegal

OK, this is not outrageously bad. But:

1) It requires a complete reorganization of the way that C programmers
   think. And no, you can't say that C programmers should just
   (re)learn thinking that way. Older compilers will exist for a long
   time; that requires that both be understood. If you think the
   current system is confusing, consider the situation with two
   different systems!

2) It obsoletes existing code. Admittedly, these are not quiet
   changes. So does `signed'. And it is not a quiet change either.
   Note, however, that there are a lot more programs that use
   unsigned short, unsigned int, and unsigned long than there are
   programs that use the word `signed'. Evidence? Scanning several
   megabytes of source code, finding not one instance of `signed' and
   many hundreds of `unsigned int'.

3) To avoid further obsoleting programs, you have to have elision
   rules that permit long and short to stand by themselves. Another
   wart.

In other words, not only would your change have the same drawback as
the signed keyword, it would have the additional drawback of creating
a long period of confusion.

And it's advantages? Diddly. There is no positive change to be had.
Oh, you might say that your type scheme is simpler, but that is a
personal judgement. Me, all I see is a different set of warts.

---
Bill
{uunet|novavax}!proxftl!twwells!bill



More information about the Comp.lang.c mailing list