Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!uflorida!novavax!proxftl!twwells!bill
From: bill@twwells.uucp (T. William Wells)
Newsgroups: comp.lang.c
Subject: Re: signed/unsigned char/short/int/long
Summary: let's kill this issue, once and for all!
Message-ID: <254@twwells.uucp>
Date: 18 Dec 88 07:54:37 GMT
References: <264@aber-cs.UUCP> <8982@smoke.BRL.MIL> <8983@smoke.BRL.MIL> <277@aber-cs.UUCP> <225@twwells.uucp> <330@aber-cs.UUCP> <9086@smoke.BRL.MIL> <347@aber-cs.UUCP> <839@quintus.UUCP> <371@aber-cs.UUCP>
Reply-To: bill@twwells.UUCP (T. William Wells)
Distribution: eunet,world
Organization: None, Ft. Lauderdale
Lines: 93
Expires:
Sender:
Followup-To:
Keywords:

In article <371@aber-cs.UUCP> pcg@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