Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!att!cbnewsl!dfp
From: dfp@cbnewsl.ATT.COM (david.f.prosser)
Newsgroups: comp.lang.c
Subject: Re: "do ... while ((NULL + 1) - 1);" -- valid C?
Message-ID: <1447@cbnewsl.ATT.COM>
Date: 11 Aug 89 17:59:24 GMT
References: <1043@levels.sait.edu.au> <961@virtech.UUCP> <10684@smoke.BRL.MIL> <940@lakesys.UUCP> <18996@mimsy.UUCP>
Reply-To: dfp@cbnewsl.ATT.COM (david.f.prosser)
Organization: AT&T Bell Laboratories
Lines: 34

In article <18996@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>
>	ip = (int *)((char *)0);
>
>On *most* machines, this `just happens' to work.  But if we look very
>closely at the language definition, we find that it is not *required*
>to work.  The version of this that is required to work is instead
>
>	ip = (int *)(char *)(int *)0;
>
>We are not allowed (outside of machine-dependent code) to change a
>pointer-to-char into a pointer-to-int unless the pointer-to-char itself
>came into existence as the result of a cast from a pointer-to-int.  The
>only way to *create* a nil-pointer-to-int in the first place is to
>write (int *)0, or (in the proposed ANSI C) (int *)(void *)0.

The pANS does guarantee that, for example,

	0 == (void *)(int *)(char *)0

[3.2.2.3: "Two null pointers, converted through possibly different sequences
of casts to pointer types, shall compare equal."]

Therefore, I interpret the pANS as requiring

	(int *)(char *)0

to have the same value as

	(int *)0

(the nil-pointer-to-int, in your terminology)--not `just happening' to work.

Dave Prosser	...not an official X3J11 answer...