mkelly@cs.uoregon.edu (Michael A. Kelly) (12/24/90)
I've just finished porting a rather simple application from THINK C to MPW C. After changing all the standard header names, the program compiled, but it didn't work quite right. After much deliberation (and a bout with SADE), and finally a trip through the manuals, I discovered that MPW's 'int's are 4 bytes long (whereas THINK's are 2 bytes). There was a small section of code that relied on the size of plain integers. After changing those ints to shorts everything works fine. My question is: What other elusive differences do I have to look forward to when porting from THINK C to MPW C ? Thanks, Mike. -- Michael A. Kelly | "Fish heads, fish heads, Internet: mkelly@cs.uoregon.edu | Roly-poly fish heads, America Online: Michael792 | Fish heads, fish heads, Compu$erve: 73567,1651 | Eat them up, yum!" - Barnes & Barnes
keith@Apple.COM (Keith Rollin) (12/28/90)
In article <1990Dec24.073137.16178@cs.uoregon.edu> mkelly@cs.uoregon.edu (Michael A. Kelly) writes: >I've just finished porting a rather simple application from THINK C to >MPW C. After changing all the standard header names, the program compiled, >but it didn't work quite right. After much deliberation (and a bout with >SADE), and finally a trip through the manuals, I discovered that MPW's 'int's >are 4 bytes long (whereas THINK's are 2 bytes). There was a small section >of code that relied on the size of plain integers. After changing those ints >to shorts everything works fine. > >My question is: What other elusive differences do I have to look forward to >when porting from THINK C to MPW C ? I seem to recall that a shift right of a signed value is implementation dependent, according to ANSI. You can either shift the sign bit and fill it in with a zero or maintain the sign bit (this is the difference between using ASR versus LSR). THINK implements it one way, and MPW implements it another. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
Keith.Rollin@f20.n226.z1.FIDONET.ORG (Keith Rollin) (12/28/90)
Reply-To: keith@Apple.COM In article <1990Dec24.073137.16178@cs.uoregon.edu> mkelly@cs.uoregon.edu (Michael A. Kelly) writes: >I've just finished porting a rather simple application from THINK C to >MPW C. After changing all the standard header names, the program compiled, >but it didn't work quite right. After much deliberation (and a bout with >SADE), and finally a trip through the manuals, I discovered that MPW's 'int's >are 4 bytes long (whereas THINK's are 2 bytes). There was a small section >of code that relied on the size of plain integers. After changing those ints >to shorts everything works fine. > >My question is: What other elusive differences do I have to look forward to >when porting from THINK C to MPW C ? I seem to recall that a shift right of a signed value is implementation dependent, according to ANSI. You can either shift the sign bit and fill it in with a zero or maintain the sign bit (this is the difference between using ASR versus LSR). THINK implements it one way, and MPW implements it another. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions + Organization: Apple Computer Inc., Cupertino, CA -- Keith Rollin - via FidoNet node 1:105/14 UUCP: ...!{uunet!glacier, ..reed.bitnet}!busker!226!20!Keith.Rollin INTERNET: Keith.Rollin@f20.n226.z1.FIDONET.ORG
wdh@well.sf.ca.us (Bill Hofmann) (12/29/90)
In article <47607@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >In article <1990Dec24.073137.16178@cs.uoregon.edu> mkelly@cs.uoregon.edu (Michael A. Kelly) writes: >>My question is: What other elusive differences do I have to look forward to >>when porting from THINK C to MPW C ? > >I seem to recall that a shift right of a signed value is implementation >dependent, according to ANSI. You can either shift the sign bit and >fill it in with a zero or maintain the sign bit (this is the difference >between using ASR versus LSR). THINK implements it one way, and MPW >implements it another. > Ouch. Haven't run into that one yet. I'm doing some development that has to compile and work in both environments, and have an #include file that contains the differences I've found. Obviously, the int size thing bit me *ages* ago, so I *always* use short or long except for an index where I want the compiler to produce best results. After using THINK for quite a while, then reluctantly starting to use MPW C, I was delighted to discover these features in MPW C which **ought** to be in THINK C: 1. MPW C *warns* you when you use something before initializing. 2. MPW C *warns* you when you don't use a parameter or local 3. While THINK 4.0.4 doesn't barf on const, it ought to implement it-it's a great protection mechanism. 4. The code the MPW compiler and linker produces is *dramatically* smaller than THINK's. This may be mostly the THINK linker's fault, although the MPW compiler seems to do a very nice job of optimizing. An example: an XCMD built in MPW is ~22k, in THINK, ~32k. I think in this case it's mostly stupid linking. But it's inexcusable. Speaking as a *professional* developer, I would pay bucks for a post-processor which would optimize and *really* strip the object of unnecessary routines. Obviously, I miss the speed of THINK, and am willing to put up with inferior linking/code generation during the debug cycle, but we'd all serve our customers better with smaller, faster code. Oops. I guess this turned into a flame. I never thought I'd have passionate opinions about compilers and linkers... -Bill PS: Here's the file: /* * MPWandTHINK.h * * Stupid differences in language/data type, etc. * * 10/30/90 wdh created in frustration */ #ifndef __MPWandTHINK__ #define __MPWandTHINK__ #ifdef THINK_C /* C++ and ANSI declarations THINK didn't implement */ #define signed /* as opposed to unsigned */ #define volatile /* don't put in registers */ #define virtual /* C++ stuff */ #define kNewLineChar '\r' #define kBooleanMinus1 -1 #else /* It's MPW */ /* These are MPW frustrations */ #define AuxWinHndl AuxWinHandle /* MPW is wrong here */ #define AuxCtlHndl AuxCtlHandle /* ditto */ #define transIndex ctFlags /* ditto ditto */ #define TRUE true #define FALSE false #define kNewLineChar '\n' #define kBooleanMinus1 0x0ff #endif THINK_C #endif __MPWandTHINK__
bin@primate.wisc.edu (Brain in Neutral) (12/29/90)
From article <22341@well.sf.ca.us>, by wdh@well.sf.ca.us (Bill Hofmann): > Ouch. Haven't run into that one yet. I'm doing some development that has > to compile and work in both environments, and have an #include file that > contains the differences I've found. Obviously, the int size thing bit me > *ages* ago, so I *always* use short or long except for an index where I want > the compiler to produce best results. I tend to #include a file "Compiler.h" which, for THINK C, contains: typedef int Integer; typedef long Longint; and then I use Integer and Longint (i.e., the Pascal names for the 2 and 4 byte integer types) in my code. To port to a different language you change Compiler.h, not your code. -- Paul DuBois dubois@primate.wisc.edu
Bill.Hofmann@f20.n226.z1.FIDONET.ORG (Bill Hofmann) (12/29/90)
Reply-To: wdh@well.sf.ca.us In article <47607@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >In article <1990Dec24.073137.16178@cs.uoregon.edu> mkelly@cs.uoregon.edu (Michael A. Kelly) writes: >>My question is: What other elusive differences do I have to look forward to >>when porting from THINK C to MPW C ? > >I seem to recall that a shift right of a signed value is implementation >dependent, according to ANSI. You can either shift the sign bit and >fill it in with a zero or maintain the sign bit (this is the difference >between using ASR versus LSR). THINK implements it one way, and MPW >implements it another. > Ouch. Haven't run into that one yet. I'm doing some development that has to compile and work in both environments, and have an #include file that contains the differences I've found. Obviously, the int size thing bit me *ages* ago, so I *always* use short or long except for an index where I want the compiler to produce best results. After using THINK for quite a while, then reluctantly starting to use MPW C, I was delighted to discover these features in MPW C which **ought** to be in THINK C: 1. MPW C *warns* you when you use something before initializing. 2. MPW C *warns* you when you don't use a parameter or local 3. While THINK 4.0.4 doesn't barf on const, it ought to implement it-it's a great protection mechanism. 4. The code the MPW compiler and linker produces is *dramatically* smaller than THINK's. This may be mostly the THINK linker's fault, although the MPW compiler seems to do a very nice job of optimizing. An example: an XCMD built in MPW is ~22k, in THINK, ~32k. I think in this case it's mostly stupid linking. But it's inexcusable. Speaking as a *professional* developer, I would pay bucks for a post-processor which would optimize and *really* strip the object of unnecessary routines. Obviously, I miss the speed of THINK, and am willing to put up with inferior linking/code generation during the debug cycle, but we'd all serve our customers better with smaller, faster code. Oops. I guess this turned into a flame. I never thought I'd have passionate opinions about compilers and linkers... -Bill PS: Here's the file: /* * MPWandTHINK.h * * Stupid differences in language/data type, etc. * * 10/30/90 wdh created in frustration */ #ifndef __MPWandTHINK__ #define __MPWandTHINK__ #ifdef THINK_C /* C++ and ANSI declarations THINK didn't implement */ #define signed /* as opposed to unsigned */ #define volatile /* don't put in registers */ #define virtual /* C++ stuff */ #define kNewLineChar '\r' #define kBooleanMinus1 -1 #else /* It's MPW */ /* These are MPW frustrations */ #define AuxWinHndl AuxWinHandle /* MPW is wrong here */ #define AuxCtlHndl AuxCtlHandle /* ditto */ #define transIndex ctFlags /* ditto ditto */ #define TRUE true #define FALSE false #define kNewLineChar '\n' #define kBooleanMinus1 0x0ff #endif THINK_C #endif __MPWandTHINK__ + Organization: Whole Earth 'Lectronic Link, Sausalito, CA -- Bill Hofmann - via FidoNet node 1:105/14 UUCP: ...!{uunet!glacier, ..reed.bitnet}!busker!226!20!Bill.Hofmann INTERNET: Bill.Hofmann@f20.n226.z1.FIDONET.ORG
Brain.in.Neutral@f20.n226.z1.FIDONET.ORG (Brain in Neutral) (12/29/90)
Reply-To: bin@primate.wisc.edu From article <22341@well.sf.ca.us>, by wdh@well.sf.ca.us (Bill Hofmann): > Ouch. Haven't run into that one yet. I'm doing some development that has > to compile and work in both environments, and have an #include file that > contains the differences I've found. Obviously, the int size thing bit me > *ages* ago, so I *always* use short or long except for an index where I want > the compiler to produce best results. I tend to #include a file "Compiler.h" which, for THINK C, contains: typedef int Integer; typedef long Longint; and then I use Integer and Longint (i.e., the Pascal names for the 2 and 4 byte integer types) in my code. To port to a different language you change Compiler.h, not your code. -- Paul DuBois dubois@primate.wisc.edu -- Brain in Neutral - via FidoNet node 1:105/14 UUCP: ...!{uunet!glacier, ..reed.bitnet}!busker!226!20!Brain.in.Neutral INTERNET: Brain.in.Neutral@f20.n226.z1.FIDONET.ORG