Xref: utzoo comp.sys.ibm.pc:22946 comp.lang.c:15336 comp.std.c:648
Checksum: 56237
Lines: 29
Path: utzoo!sq!msb
From: msb@sq.uucp (Mark Brader)
Date: Mon, 9-Jan-89 18:38:44 EST
Message-ID: <1989Jan9.183844.1034@sq.uucp>
Newsgroups: comp.sys.ibm.pc,comp.lang.c,comp.std.c
Subject: Re: correct code for pointer subtraction
References: <597@mks.UUCP> <3845@pt.cs.cmu.edu> <18123@santra.UUCP> <142@bms-at.UUCP> <6604@killer.DALLAS.TX.US> <PINKAS.89Jan3082456@hobbit.intel.com> <18683@santra.UUCP> <9301@smoke.BRL.MIL>
Reply-To: msb@sq.com (Mark Brader)
Organization: SoftQuad Inc., Toronto

Someone says:
Of the code:
		static int a[30000];
		printf("%d\n",&a[30000]-a);

Someone says:
> > I have been told that dpANS explicitly states that the address of
> > "one-after-last" element of an array may be taken, and subtractions 
> > like the above are legal and should give correct result.

And Doug Gwyn says:
> Almost. ... the result is of type ptrdiff_t (defined in <stddef.h>).
> The example above assumes that ptrdiff_t is int ...

Right so far.  But in addition, it's possible for a valid expression to
result in an overflow.  This is not a problem in the particular example
since 30000 can't overflow an int, but it's permissible for subscripts to
run higher than the maximum value that ptrdiff_t can contain.  In that
case, the analogous subtraction "like the above" would not work.

Section 3.3.6 in the October dpANS says:
#  As with any other arithmetic overflow, if the result does not fit in
#  the space provided, the behavior is undefined.

Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com
	A standard is established on sure bases, not capriciously but with
	the surety of something intentional and of a logic controlled by
	analysis and experiment. ... A standard is necessary for order
	in human effort.				-- Le Corbusier