signed/unsigned char/short/int/long

[Piercarlo Grandi]

In article <254 at twwells.uucp> bill at twwells.UUCP (T. William Wells) writes:

#    This is a far better statement about what your intention and desire
#    is than any of your previous postings on the subject.

Bizarrely enough somebody else did understand them. Ah, by the way, hadn't
you promised to ignore my further postings? :->. I don't complain, though, you
are an almost ideal illustration of my point about the confusion the current
syntax/semantics gap generates :->.

#    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... ;-{

    I realize that at this point most readers will be already fairly
    disgusted, and I want to point out that I am sickened myself a bit by
    these sweeping, very kind allegations.

    Most readers will not want to deal with any more of this, and will not
    need to see the technical arguments I am going to use to try to make Mr.
    Wells understand my points (lies, if you wish :->).

    You have an opportunity to type n.

#    Your previous postings have adduced falsehoods to support what is, after
#    all, just an expression of your intuitions about the language.

Excellent: start by calling liars those that disagree with you, then you will
attack them for what they have never said. Have you ever thought of getting
into politics? :-) :-) :-)

Lies?? Maybe I am too thick as you say, but somebody else may start to think
that your allegations so far have been misrepresentations of my critique of
dpANS C or maybe are just the result of your lack of basic understanding of
such critique.

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?

I refuse to be faulted for your problems with your ingrained habits.
You may not agree with my arguments, but they happen to be well
founded, even if unconventional.

#   It is this adducing, not your ideas themselves, which have caused several
#   of us to liberally flame you.

No, it is your inability to think in terms other than those you are familiar
with.

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

Indeed, that is exactly WHY I say "char" should be described as a *length*
and not a type; its base type may be either "int" or "unsigned" if not
specified explicitly.  There is no weirdness in this, just a matter of
repecting existing conventions.

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

Still I would have liked X3J11 to have simplified matters as much as possible,
instead of adopting as a rule the easy and more complicated solution.

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

Not really, you have missed that 'char int' was a mere illustration of the
straightening out the syntax. By itself it *is* just a wart, and I have never
claimed otherwise; I have used it only to introduce the argument that it is
the description of the syntax of integral types that ought to be
restructured, and as a nice side effect this solves the signed char problem
without requiring keywords.

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

This is entirely bogus. Please try to understand what I write. My proposal
*is* backwards compatible and has a very simple 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.

Absolutely not. Did I really have to say, to intelligent readers, that as an
obsolescent feature, "unsigned int" ought to be allowed to stand  as a synonym
of "unsigned", because that is the only glaring incompatibility?

Also, I never advocated deleting the existing rule that if only the length
modifier is given in a declaration, the base type is int, except for
char where it may be either unsigned or not.

My, I had tried to sketch an alternative, in the interests of conciseness.  I
didn't want to have to write ten page articles to cover all points that you
may have difficulties with.

As to my concise type tables, here they are:

[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

With the obvious defaults as applicable to each case.

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

Absolutely not! Again. Did I have to spell out that the usual defaults would
still apply? Did I have to spell out that the (rightly) obsolescent rule that
allows type keywords to appear in "any" order would still have to exist? Did
I have ever write anything to the contrary? Shouldn't I have expected you
to fill in the obviously missing details?

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

In summary, your understanding has improved, but you are still fighting with
things I have never written, and you fault me in fairly abusive terms for
ideas that you have invented yourself.

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

I have not presented any fact, only reasonable arguments, including the
arguable point that you are so highly prejudiced that you haven't yet been
able to really understand what I have been talking about, a very soft,
clearer and simpler, reinterpretation of existing keywords and syntax.

#    When you do this kind of thing, all you do is damage your reputation and
#    waste bandwidth.

You may not realize that the only reputation you are really damaging is
*yours*; maybe this isn't even a waste of bandwidth.
-- 
Piercarlo "Peter" Grandi			INET: pcg at cs.aber.ac.uk
Sw.Eng. Group, Dept. of Computer Science	UUCP: ...!mcvax!ukc!aber-cs!pcg
UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK)