Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site peora.UUCP
Path: utzoo!utcs!lsuc!pesnta!peora!jer
From: jer@peora.UUCP (J. Eric Roskos)
Newsgroups: net.micro.mac
Subject: Re: Re: C Compiler Benchmarks
Message-ID: <122@peora.UUCP>
Date: Sat, 2-Mar-85 16:57:39 EST
Article-I.D.: peora.122
Posted: Sat Mar  2 16:57:39 1985
Date-Received: Sat, 2-Mar-85 19:17:04 EST
References: <5124@ucbvax.ARPA> <189@cadtroy.UUCP>
Organization: Perkin-Elmer SDC, Orlando, Fl.
Lines: 38

>>     Someone told me that the C
>>     standard stipulates that an integer's worth of bits must be able
>>     to span the entire address space.
> 
> Hmmm,  the 68000 inside the MAC has a 24bit address space.  A AT&T
> 68010 UNIX distribution C compiler believes that ints are 16bits.
> 

A very lengthy, and ultimately unfruitful, discussion along these lines
occurred in the ARPA UNIX-WIZARDS conference last Spring.  The underlying
problem is that many programmers earnestly want to write portable code,
yet vehemently believe that the C "standard" should support various
programming tricks they have discovered which just as surely prevent
portable code from ever being written.

What's at issue here is that the C language will allow you to assign
pointers to integers.  The K&R language standard (which is in Appendix A
of the book) states "Certain conversions involving pointers are permitted
but have implementation-dependent aspects. ... A pointer may be converted
to any of the integral types large enough to hold it.  Whether an int or
long is required is machine dependent.  The mapping function is also
machine dependent, but is intended to be unsurprising to those who
know the addressing structure of the machine."

The essence of this statement is that assigning pointers to integers is
"implementation dependent," i.e., if you do it, the resulting programs
will be nonportable; and, although the standard uses the word "machine,"
it is far wiser to read "compiler" dependent instead.

The moral of this story is this.  If you are writing programs for yourself,
or for a particular compiler, you can do whatever you want; but if you are
writing portable programs, you should avoid such features altogether.  Doing
so prevents C from losing its expressiveness and flexibility, while avoiding
surprises when porting programs.

					Eric Roskos
					Perkin-Elmer Corp. SDC