signed/unsigned char/short/int/long
T. William Wells
bill at twwells.uucp
Sun Dec 18 17:54:37 AEST 1988
In article <371 at aber-cs.UUCP> pcg at cs.aber.ac.uk (Piercarlo Grandi) writes:
: To me that is syntax. The semantics is that functionally C types are still
: essentially "words", albeit of different lengths (to me, lengths do not change
: the semantics of operations, and thus do not really introduce new "types").
: Unsigned was a significant departure, especially in that it was defined
: to obey the rules of modular arithmetic.
This is a far better statement about what your intention and desire
is than any of your previous postings on the subject. Your previous
postings have adduced falsehoods to support what is, after all, just
an expression of your intuitions about the language. It is this
adducing, not your ideas themselves, which have caused several of us
to liberally flame you.
Now, I'll be the first to agree that C's types are kludgey. The
notion of a type where the sign is unspecified is more than a bit
wierd. However, there it is, in the language; we have to live with it.
X3J11, bowing to the desire to have a definitely signed character, did
something about it.
That something should have been done about it, I think we both agree
on. However, where you disagree with most everyone else is in how it
ought to be done. The committee decided that the way to solve the
problem was to add a new keyword. Your suggestion is to use `char
int' instead.
Your method has the drawback of either requiring every C program in
existence to be rewritten or requiring that programmers memorize a
wholly nonintuitive type table.
Let's draw up a table:
char char char
signed char char int char int
unsigned char char unsigned unsigned char
short (int) short int short (int)
unsigned short (int) short unsigned unsigned short (int)
int int int
unsigned (int) unsigned unsigned (int)
long (int) long int long (int)
unsigned long (int) long unsigned unsigned long (int)
These are the columns:
1) Existing practice, either in common use, or the dpANS
`signed char', the wart you aspire to remove.
2) A type scheme using using int and unsigned as the base
types, char, short, and long as modifiers. This looks
pretty, except for the unavoidable `char' wart.
3) A fudged version of the existing method, substituting char
int for signed int. The wart in this is its incoherency.
Choice 1 is existing practice, to be preferred unless there is a good
reason to change it. Its primary drawback is that the use of signed
will break any program using `signed' as an identifier. (Grep will
fix that, however.)
Choice 2 requires modification of almost every existing program.
These are the changes that one would have to make:
short short int
unsigned short int short unsigned
unsigned int unsigned
long long int
unsigned long int unsigned long
Now, everyone who routinely leaves out the unnecessary words in a type
is going to be stuck fixing `short' and `long'. Those who routinely
put them in will have to remove them for `unsigned short int',
`unsigned int', and `unsigned long int'. Those who don't have any
habits either way will be left totally at C.
In other words, this change would screw over every C programmer.
Choice 3 does not require the extra keyword as choice 1 does;
however, the type scheme is incoherent. There is no way, other than
memorizing the wierd syntax for `char' types, that a programmer can
use this.
So, in summary, your idea is fundamentally flawed: if carried out
consistently will break almost every program, if carried out
inconsistently will add to the confusion about C types.
Let's kill this discussion. Your feelings on the subject are
irrelevant; the "facts" you have presented to back up your position
have been false. When you do this kind of thing, all you do is damage
your reputation and waste bandwidth.
---
Bill
{uunet|novavax}!proxftl!twwells!bill
More information about the Comp.lang.c
mailing list