🚀 go-pugleaf

zrm@eddie.MIT.EDU (Zigurd R. Mednieks) writes:
>Most Macintosh code, though, is going nowhere other than a Macintosh. In
>light of that fact, it would have been nice if Apple had specified its
>Apple-label  C compiler to conform more closely to its Pascal compiler
>datatypes.

Well, I just had to comment on this.  Anybody else from the Development
Tools or A/UX groups should probably pitch in too.

     o  Much Macintosh code will be ported to a non-Macintosh
	environment.  That is A/UX with its built in toolbox support.

     o  When having the choice of being compatible with the Pascal or
	the A/UX C-compiler, I personally choose the later.

     o  Why does everyone assume that INTEGER == int when you could as
	well write INTEGER == short?  Yes, I know there are cases when
	having a short int helps, but I have to say that writing
	flexible code for a 16 bit int environment is a royal pain.

     o  16-bit ints break much of the standard C libraries. To give a
	few examples:

		strlen() returns an int.  If your string is longer than
		64K then the value returned (IF IT RETURNS!) is
		undefined.  The result is that I have to hand code
		around this whenever there is even a chance that the
		string is looong.

		read() takes an int as the nbyte-s argument.  This
		means that I can't read more than 64K bytes at a time.
		(Actually 32K since it's normally an int and not
		unsigned.)  This is a real pain since this is a very
		common case.

	there are *many* more.

The following two points are not very important but:
 
     o  Historically, portability is enhanced if sizeof(int) >=
	sizeof(char *).

     o  Some quick hacks are easier if sizeof(int) >= sizeof(char *).
	I really should be ashamed saying this, but it's true, and for
	throwaway code, who cares? (Assuming the code actually gets
	thrown...)

I have used both MPW (I wrote Rez and DeRez) and LightSpeed (my
favorite prototyping environment [sorry DevTools :-)] ) extensively and
I get bit (pun intended) by the 16-bit problem every time.  Not in the
sense of portability (since good coding style takes care of it pretty
much automatically), but in the sense that it's hard to avoid passing
arguments that are greater than 64K to libraries, just so that it will
work even under LightSpeed. As a matter of fact, much of my prototyping
is broken for large data under LightSpeed because I know that I will
run any production code under a *real* C compiler [sorry LightSpeed
:-)] with 32 bit ints (MPW or A/UX).

In general, I think that having an 16-bit int is OK if you have a 64K
address space (such as a PDP-11), or it is very painful to move 32 bit
stuff around (80*86 where the address space isn't that much to talk
about anyway).  The Macintosh though uses the 68xxx architecture where
there are few if any penalties for using 32-bit ints.  The Macintosh is
a megabyte class machine (my Macintosh ][ has 5 meg at the moment, i.e. it's
not even fully stuffed) and the data typically handled is in the n*64K
range where n is >>1.

In conclusion, I think (and this and all the above is *my* opinion,
not Apple Computers) that the 16-bit int is a reminiscence from small
memory spaces (i.e. less than half a megabyte) and I am looking forward
to when we will have 64 bit pointers, 64 bit ints and 128 bit longs.
(Only 16Gig address space, how quaint, I bet it can't even do real time
ray tracing...) although that day might be a few years of yet......

	Sincerely yours,
	Johan
____________________________

	Johan Strandberg
	Toolsmith
	Apple Computer, Inc.

USENET:	{mtxinu!ucbvax,nsc,voder,sun}!apple!johan.UUCP
CSNet:	johan@apple.CSNET