spector@acf4.UUCP (03/29/87)
more MPW-isms: This is one that will most likely be a religious point, but here goes: What is with Apple? I just bought all of MPW. Although its a little too Unixy for a development environment on a Macintosh, I an learning to like it.. but MPW C has been broken by Apple, for why I don't understand! Heres the story, taken from page 17, table 2-1 of the MPW C Reference Manual: Size and range of data types: ----------------------------------------------------------------------------- Data type Bits Description ----------------------------------------------------------------------------- Char 8 Range -128 to 127 unsigned Char 8 Range 0 to 225 short 16 Range -32768 to 32767 unsigned short 16 Range 0 to 65535 int 32 Range -2,147,483,648 to ..... (the rest of the chart details the obvious...) Now, what's wrong with this picture? Well, for starters, someone should have tried to read the motorola manual for the 68000 family of microprocessors. Integers on the 680x0 family are 16 (sixteen) bits wide, longs are 32bits. Whats more is that Apple (!!), in Inside Macintosh states that integers are *16 bits*! (see Inside Macintosh, Vol. I, Pg.86, "Pascal Data Types") I know, we're talking about C and not Pascal, but if it weren't for the fact that all of the toolbox routines that expect integers, expect 16 bit integers I wouldn't be upset. Of course Apple does the type coercion for the toolbox traps, but why do they violate their own spec? Why am I as a programmer forced to rewrite (read: change) thousands of lines of code that make the (correct) assumption that integers on a Macintosh are 16bits?!? I mean, I may be too touchy, but this is really annoying. Bill Duvall started this silly trend of 32bit ints on a Mac with MacC, and he was wrong too. Hmmph! Grumble, grumble. David HM Spector NYU/acf Systems Group
zrm@mit-eddie.UUCP (03/30/87)
In article <12500007@acf4.UUCP> spector@acf4.UUCP (David HM Spector) writes: >Char 8 Range -128 to 127 >unsigned Char 8 Range 0 to 225 >short 16 Range -32768 to 32767 >unsigned short 16 Range 0 to 65535 >int 32 Range -2,147,483,648 to ..... > >Integers on the 680x0 family are 16 (sixteen) bits wide, longs are 32bits. >Whats more is that Apple (!!), in Inside Macintosh states that integers are >*16 bits*! (see Inside Macintosh, Vol. I, Pg.86, "Pascal Data Types") > Indeed! I think it is a sinister plot by a Pascalist cabal within Apple. I can picture the scenario: The evil Pascalist intercepts a call from Green Hills... "Uh yeah, 32 bit integers, that's what we want, yeah, that's the ticket. Oh you know, the only people who will use C are those Unix weenies, they'll probably even use printf and stdio file i/o." Actually, I don't know if any version of Green Hills C (a.k.a. MPW C) has 16 bit ints. The two compilers that seem to do everything right are Aztec C, by Manx Software, and LightspeedC, by Think Technologies. The first has a Unix-like environment, the latter a Macintosh oriented one. I use the latter. (Somewhat self serving plug follows) For a discussion of what to look for in a Macintosh C compiler, and why you should look for those things, see "C Programming Techniques for the Macintosh" published by Howard W. Sams & Co. If somebody from Apple will tell me who the product manager for MPW is, I'll make sure they get a copy. Last year I did a presentation for the Boston Computer Society MacTech group comparing a all the C compilers I knew of at the time. Since then I have worked with MPW too. If people out there would like for me to write and post a summary of that talk, I will do that. -Zigurd
jww@sdcsvax.UUCP (03/30/87)
In article <12500007@acf4.UUCP>, spector@acf4.UUCP (David HM Spector) writes: > Size and range of data types: > int 32 Range -2,147,483,648 to ..... > > > Now, what's wrong with this picture? Well, for starters, someone should > have tried to read the motorola manual for the 68000 family of microprocessors. > Integers on the 680x0 family are 16 (sixteen) bits wide, longs are 32bits. > Whats more is that Apple (!!), in Inside Macintosh states that integers are > *16 bits*! (see Inside Macintosh, Vol. I, Pg.86, "Pascal Data Types") Actually, integers on the MC68020 and later are 32 bits wide, not 16 bits wide. The only thing that keeps the 68000 and 68010 from being a true 32-bit machine is the lack of the multiply/divide in 32 bit size. A convincing case can be made for 16 bit integers (speed, Pascal compatibility), but most C compilers for real machines nowadays (and I think the Mac II is intended to be a real machine) assume int is 32 bits. There's even the crappy code around that assumes sizeof(int) = sizeof(char *), and in fact, Apple uses this to shorten the header files for MPW C. I think the concern is less severe, because Apple has a provision to automatically coerce the size of Toolbox traps and even do a little type checking (finally! my one gripe about C.) > Why am I as a programmer forced to rewrite > (read: change) thousands of lines of code that make the (correct) assumption > that integers on a Macintosh are 16bits?!? Because you are masochist who likes to write non-portable code. :-) Every Macintosh C programmer should start his code with typedef Byte char; typedef Half short; typedef Full long; (or pick other names you like better) and expect int to be either size. The only case I can think of to use int is if you always pass an integer constant as an argument and are too lazy to coerce it each time (which can be easily solved by a macro, btw). Take a look at the news software, or kermit, two large public domain programs available in source. They run on all sorts of machines, because they make no assumptions in certain areas, such as the size of an int, or the representation of value NULL. Anyone who wants to keep their C code for more than six months starts out by programming defensively for portability; this is true for the Mac and any other machine with a C compiler, since you never know where you'll go next (compiler or machine). -- Joel West {ucbvax,ihnp4}!sdcsvax!jww (ihnp4!gould9!joel once I fix news) jww@sdcsvax.ucsd.edu if you must
jordan@apple.UUCP (03/30/87)
Follow up to messages on MPW C Compiler: I don't know why the decision was made to use 32 bit integers, other than the possibility that Green Hills is a Unix shop, and decided to use the 32 bit quanity as is used on the Vaxen. Paul Zemlin is the product manager for MPW. Paul can be reached at the following address: Paul Zemlin Apple Computer, Inc. Tools & Languages Product Management 20525 Mariani Avenue, MS: 27S Cupertino, CA 95014 -- Jordan Mattson UUCP: ucbvax!mtxinu!apple!jordan Apple Computer, Inc. CSNET: jordan@apple.CSNET Tools & Languages Product Management 20525 Mariani Avenue, MS 27S Cupertino, CA 95014 408-973-4601 "Joy is the serious business of heaven." C.S. Lewis
spector@acf4.UUCP (03/30/87)
I agree. LightSpeed is a nifty product. I have had it for a while and like it very much. I bought MPW in order to tie my universe together with a 'standard' APPLE SUPPORTED development evnironment. I am just disappointed that they chose to violate their own specification. DHMS
stew@endor.UUCP (03/31/87)
To: spector@acf4.UUCP Subject: Re: MPW C annoyances.... Newsgroups: comp.sys.mac In-Reply-To: <12500007@acf4.UUCP> Organization: Aiken Computation Lab Harvard, Cambridge, MA Cc: Bcc: I agree with you... I tell myself that good coding practice uses typedef short INT16; typedef unsigned long UINT32; etc. But this loses because of the "usual arithmetic conversions" that waste time doing a ton of conversions and 32 bit arithmetic with 16 bit operands. The code generator in MPW is far, far superior to that in LightSpeed C, but because of all the stupid conversions, the net result is a wash. I also cursed and swore for a while when I found out that the MPW C library routines expect null terminated strings instead of pascal style. grumble...
zrm@mit-eddie.UUCP (03/31/87)
In article <2926@sdcsvax.UCSD.EDU> jww@sdcsvax.UCSD.EDU (Joel West) writes: > >Every Macintosh C programmer should start his code with > > typedef Byte char; > typedef Half short; > typedef Full long; > >(or pick other names you like better) and expect int to be either size. >The only case I can think of to use int is if you always pass an >integer constant as an argument and are too lazy to coerce it >each time (which can be easily solved by a macro, btw). Creating datatypes that are guaranteed to be a certain size does make a lot of sense for code that has to be very portable, e.g. b*-tree libraries and other highly system and processor independent code. 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. That would have, by the way, obviated the need to coerce types in arguments to Toolbox calls, which is not really standard C. The style of C programming suggested by Joel is laid out in great detail in a Plum Hall book on C programming. In most cases I think that style is too rigid and makes for code which is hard to read, partly because it is difficult to tell the difference between defined types that are aggregates (e.g. structures) and those that are not, without always checking the header files. By minimizing the number of alterations made to bare-bones C, you minimize the number of things a new maintainer must learn before he can begin improving or porting the code. -Zigurd
jimc@iscuva.UUCP (03/31/87)
In article <2926@sdcsvax.UCSD.EDU> jww@sdcsvax.UCSD.EDU (Joel West) writes: >> Integers on the 680x0 family are 16 (sixteen) bits wide, longs are 32bits. >Actually, integers on the MC68020 and later are 32 bits wide, not 16 >bits wide. The only thing that keeps the 68000 and 68010 from being >a true 32-bit machine is the lack of the multiply/divide in 32 bit size. > >A convincing case can be made for 16 bit integers (speed, Pascal compat...), Certainly speed! For non-68020's, interesting longword instructions generally take longer (and are sometimes larger) than the equivalent word instructions. What bothers me about C is not that, say, an int is 32 bits and a short is 16 bits since I can declare variables either way I want, but that ALL EXPRESSIONS AND STACK PARAMETERS ARE COERCED TO BE INTS! Thus, for a 32-bit int compiler any multiply/divide MUST use a subroutine (including array subscripting operations), every simple int(char)- taking subroutine takes longer to call, etc... I am also bothered about the coersion of float to double, but since I never use floating point I'm not bothered too much. According to K&R, an int is supposed to be the most natural sized operation for any given machine, which, face it, for a 68000/68010 is 16 bits. Personally I am fond of compilers that have switches that allow you to generate code either way suits your needs (and/or fancy). +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC Systems Corp. ! II CC ! Spokane, WA ! IISSSS CC ! UUCP: ihnp4!tektronix!reed!iscuva!jimc ! II CCCCCC ! (509)927-5757 +----------------+ "Speed kills (your competitors)."
jwhitnel@csib.UUCP (03/31/87)
In article <12500007@acf4.UUCP> spector@acf4.UUCP (David HM Spector) writes: > >more MPW-isms: > ... >int 32 Range -2,147,483,648 to ..... > >Whats more is that Apple (!!), in Inside Macintosh states that integers are >*16 bits*! (see Inside Macintosh, Vol. I, Pg.86, "Pascal Data Types") > >I mean, I may be too touchy, but this is really annoying. Bill Duvall started >this silly trend of 32bit ints on a Mac with MacC, and he was wrong too. > >Hmmph! Grumble, grumble. >David HM Spector David, 32 bit ints for C on the 68K started when UNIX was ported over. All of the UNIX C compilers use 32 bits so that's the defacto standard. Since MPW is a port of the Greenhills C compiler which used 32 bits int, it's not surpising that they kept it for MPW. So the mac compilers that use 16 bits are the exception, not the rule for 68K C compilers. I agree it is a pain and in the future I'm going to use typedefs wherever the size of the int is important. Jerry Whitnell Communications Solutions, Inc.
johan@apple.UUCP (04/01/87)
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
jww@sdcsvax.UUCP (04/02/87)
In article <498@iscuva.UUCP>, jimc@iscuva.UUCP (Jim Cathey) writes: > Certainly speed! For non-68020's, interesting longword instructions > generally take longer (and are sometimes larger) than the equivalent word > instructions. What bothers me about C is not that, say, an int is 32 > bits and a short is 16 bits since I can declare variables either way I > want, but that ALL EXPRESSIONS AND STACK PARAMETERS ARE COERCED TO BE > INTS! Nope. Simply not true for expressions. > Thus, for a 32-bit int compiler any multiply/divide MUST use a > subroutine (including array subscripting operations), every simple > int(char)- taking subroutine takes longer to call, etc... I can't speak to the accuracy of that claim for all compilers, but clearly it is possible to do 16-bit arithmetic in MPW C. I was upset at having to link a library (not speed) for one example in my book, so I coerced it to 16-bit arithmetic with buff[0] = '0' + (ashort / (short) 10); buff[1] = '0' + (ashort % (short) 10); > I am also > bothered about the coersion of float to double, but since I never use > floating point I'm not bothered too much. float to double is, of course, standard K&R, although the ANSI committee seems inclined to modify it for speed freaks. > According to K&R, an int is supposed to be the most natural sized operation > for any given machine, which, face it, for a 68000/68010 is 16 bits. As Johan Strandberg points out, you have many problems with sizeof(int) != sizeof(char *). This was also discovered by people moving code around like news. > Personally I am fond of compilers that have switches that allow you to > generate code either way suits your needs (and/or fancy). This is the best possible solution, as long as you correctly handle the Macintosh interfaces with either setting. -- Joel West {ucbvax,ihnp4}!sdcsvax!jww (ihnp4!gould9!joel once I fix news) jww@sdcsvax.ucsd.edu if you must
huxham@apple.UUCP (04/07/87)
In article <1535@husc6.UUCP> stew@endor.UUCP (Stew Rubenstein) writes: >I also cursed and swore for a while when I found out that the MPW C >library routines expect null terminated strings instead of pascal >style. grumble... MPW C 2.0 will offer the option to link to libraries that do string conversion for you (accept C strings), or let you do it yourself (accept Pascal strings). Enough people grumbled. Fred