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