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...