Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!peregrine!elroy!mahendo!wlbr!scgvaxd!ashtate!dbase!awd From: awd@dbase.UUCP (Alastair Dallas) Newsgroups: comp.sys.mac.programmer Subject: Re: Pointer Subtraction in THINK C 3.0 Summary: Same as MS-DOS Message-ID: <442@dbase.UUCP> Date: 12 Aug 88 09:19:03 GMT Article-I.D.: dbase.442 References: <63033@sun.uucp> Organization: Ashton Tate Development Center Glendale Cal. Lines: 45 In article <63033@sun.uucp>, swilson%thetone@Sun.COM (Scott Wilson) writes: > I was a little suprised when I ran this program under THINK C 3.0: > >> > It looks as though THINK C 3.0 is using long as the resulting type for > pointer subtraction. (A long gets pushed on the stack instead > of an int, its upper two bytes are zero so printi prints 0.) > > According to K&R: > > If two pointers to objects of the same type are subtracted, > the result is converted ... to an int ... > > However, K&R 2nd ed. (and I assume ANSI) says: > > If two pointers to objects of the same type are subtracted, ... > The type of the result ... is defined as ptrdiff_t in the > standard header > In an environment where pointers are 32-bit values (such as the Macintosh and Large-Model MS-DOS) and unqualified ints are 16-bits (such as Mac and MS-DOS), what's a compiler to do? Clearly, there is the possibility of data loss if ptr32 - ptr32 gets truncated to int16. So, yes, per K&R LSC renders an int--an int of the minimum size required to hold the result, in this case a 32-bit int. However, since you the programmer know that the difference between the pointers will not be greater than 32767, you can safely cast (i.e., truncate) the ptr expression to an int. I wish THINK C was a little more on the mark when it comes to ANSI C-- I work with Microsoft C and Metaware High C on MS-DOS and they are both full-blown, up-to-the-minute ANSI draft implementations. THINK merely leans in ANSI's direction. There are some nice pre-processor toys from ANSI that I'd like to have, and standard libraries and headers (like ptrdiff_t) would be nice, too. But if you're using Mac libs instead of UNIX-compatible it really doesn't make too much difference. /alastair/ -- /* alastair */