Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!utfyzx!sq!msb
From: msb@sq.UUCP
Newsgroups: comp.lang.c
Subject: Re: standardizing integral type sizes
Message-ID: <1987Apr20.132629.8292@sq.uucp>
Date: Mon, 20-Apr-87 13:26:29 EST
Article-I.D.: sq.1987Apr20.132629.8292
Posted: Mon Apr 20 13:26:29 1987
Date-Received: Wed, 22-Apr-87 03:28:45 EST
References: <101@umich.UUCP> <791@xanth.UUCP> <1987Apr9.155110.28398@sq.uucp> <652@edge.UUCP>
Reply-To: msb@sq.UUCP (Mark Brader)
Organization: SoftQuad Inc., Toronto
Lines: 27
Checksum: 59156
Summary: sizeof(int) should not necessarily == sizeof(something*)

> > The second thing is, yes, efficiency.  The Draft Standard DOES specify
> > MINIMUM ranges for the different types.  In effect it guarantees...
> > ... with the further presumption, which has been part of C for a long
> > time, that int operations are at least as efficient as other types.
> 
> I dunno about this last presumption having been part of C for a long time.
> (I take that to mean K&R spec).  The closest I can find is in K&R sec. 2.2,
> which says (twice) that "int" reflects the "natural size of integers on
> the host machine."

This is what I meant; much the same language is in the Draft (sec. 3.1.2.5).
I think there's a general presumption that "natural" implies "most efficient".

> I bring this up because on the C compilers I've used on the 68000, "int"
> has always been a 32-bit quantity.  This is almost a necessity, because
> of the well-known bad habit of assuming that a pointer will fit in an int.
> But 32-bit ints on the 68000 are nowhere near as efficient as 16-bit ints.

If this is accurate, it means that the compiler writers had to choose
between making existing "well-known" badly-written code run at all
without being fixed, and making well-written code run more slowly than
it should.  The decision strikes me as -- no pun intended -- short-sighted.
But my assumption is that proper typing will become more widespread in
the future, which may be wrong; and, as someone else pointed out recently,
getting the right answer certainly beats getting the wrong answer fast.

Mark Brader