Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!yale!Horne-Scott
From: Horne-Scott@cs.yale.edu (Scott Horne)
Newsgroups: comp.lang.c
Subject: Re: int divided by unsigned.
Message-ID: <66203@yale-celray.yale.UUCP>
Date: 12 Jul 89 14:51:25 GMT
References: <1989Jul11.215930.9042@jarvis.csri.toronto.edu> <13983@lanl.gov>
Sender: root@yale.UUCP
Reply-To: Horne-Scott@cs.yale.edu (Scott Horne)
Distribution: na
Organization: Yale University Computer Science Dept, New Haven, CT   06520-2158
Lines: 50
In-reply-to: jlg@lanl.gov (Jim Giles)

In article <13983@lanl.gov>, jlg@lanl (Jim Giles) writes:
> From article <1989Jul11.215930.9042@jarvis.csri.toronto.edu>, by flaps@jarvis.csri.toronto.edu (Alan J Rosenthal):
> > jlg@lanl.gov (Jim Giles) writes:
> >>C foolishly doesn't require 'short', 'int', and 'long' to be different data
> >>types.  Oh well.
> > 
> > Sure it does.  It just doesn't require them to be different sizes.  Requiring
> > them to be different sizes would be foolish.
> 
> Requiring them to be different sizes would make sense.  Allowing them to
> be the same size is done for backward compatibility (_both_ meanings of
> the word backward intended).  This failing wouldn't have existed if the
> language had made proper requirements on the data types from the start.

There's nothing ``backward'' about it in either sense.

> Even
> better, distinct data types should differ from each other in predictable
> ways.  What's wrong with short must be twice as precise as char?  Or int
> should be at least twice as precise as short?  Or long must be at least
> twice as precise as int?  Etc..

What's wrong with it?  Architecture is what's wrong with it.  Suppose we were
designing a C compiler for the IBM PC.  Which sizes shall we use?  Well,
according to you, we should make `char', `short', `int', and `long' different
sizes, preferably with each twice the size of the previous (with `long' perhaps
more than twice the size of `int').  Now, it makes sense to let `char' be one
byte, as you'll probably agree.  (Consider the purpose of `char'.)  If we are
to make `short' bigger than `char', and if we accept your rather arbitrary
choice of twice the size, then we shall give it a size of two bytes.  So far,
so good.  You probably don't want to make `int' a three-byte type; thus, make
it four bytes.  (This is consistent with your twice-the-size argument, too.)
What to do with `long'?  Well, you want it to be at least twice the size of
an `int'.  But that's eight bytes--and the machine instructions can't handle
eight-byte integers conveniently!  Heavens above!  I guess it's reasonable
then to do it the way most PC C compilers do:  1-byte `char's, 2-byte `short's
and `int's, and 4-byte `long's.  How coincidental that the language doesn't
make such demands.

Other problems arise, such as alignment.  Anyway, your demands force all
implementations to use 1-byte `char's, 2-byte `short's, and 4-byte `int's.
Doesn't this seem daft?

					--Scott

Scott Horne                              Hacker-in-Chief, Yale CS Dept Facility
horne@cs.Yale.edu                         ...!{harvard,cmcl2,decvax}!yale!horne
Home: 203 789-0877     SnailMail:  Box 7196 Yale Station, New Haven, CT   06520
Work: 203 432-6428              Summer residence:  175 Dwight St, New Haven, CT
Dare I speak for the amorphous gallimaufry of intellectual thought called Yale?