Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.arch Subject: Re: C pointers in longs (was Re: looking for >32-bit address space) Message-ID: <1437@auspex.auspex.com> Date: 15 Apr 89 07:07:42 GMT References: <2569@elxsi.UUCP> <28200298@mcdurb> <1422@auspex.auspex.com> <11274@tekecs.GWD.TEK.COM> Reply-To: guy@auspex.auspex.com (Guy Harris) Organization: Auspex Systems, Santa Clara Lines: 20 >But an int must still accommodate the result of subtracting two >pointers into the same array, No, the (d)pANS has also nuked the idea that the difference between two pointers must fit into an "int". It must fit into *some* integral type, and the implementation must supply an include file that, among other things, must define a "typedef" named "ptrdiff_t" that is the integral type in question. >so, if you're going to permit arrays of more than 2GB, you'll need >wider ints. No, you need wider "long"s at most. It's not clear from a quick reading of the standard whether an implementation that supports "long long int", say, and that typedefs "ptrdiff_t" as "long long int", would be conforming. A conforming implementation implementation can, as I read it, support "long long int", since I don't see any way for that extension to cause a strictly conforming program to become invalid. In any case, it's quite possible that an implementation with 64-bit pointers may well have 64-bit "long"s, and thus could have 32-bit "int"s.