Path: csiph.com!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: James Kuyper Newsgroups: comp.std.c Subject: Re: null pointer constant, address constant Date: Thu, 20 Dec 2012 12:28:41 -0500 Organization: A noiseless patient Spider Lines: 51 Message-ID: <50D34AC9.4040907@verizon.net> References: <89afe21d-1a8b-4749-8ad1-ec98cc65a818@a8g2000vby.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Info: mx04.eternal-september.org; posting-host="d8fef572ea43a1acd556896aa70d63af"; logging-data="27569"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18/UmjT3xZ3Qhzpsvyf0+cKz92B5n2onCA=" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: Cancel-Lock: sha1:W2i43k8EmgTBxHdeAAaW0i2IWBY= Xref: csiph.com comp.std.c:1770 On 12/20/2012 10:33 AM, James Kuyper wrote: > On 12/20/2012 08:34 AM, christian.bau wrote: >> On Dec 18, 11:52�pm, Keith Thompson wrote: >> >>> The standard says that a constant arithmetic expression with the value >>> 0, converted to a pointer type, yields a null pointer. �It does *not* >>> say the same thing about a non-constant arithmetic expression with the >>> value 0. >> >> It doesn't have to. The standard doesn't have to state something >> explicitly if it follows from other rules that are stated. >> >> Converting _any_ integer to _any_ pointer gives an implementation- >> defined result. > > Not so. "An integer may be converted to any pointer type. Except as > previously specified, the result is implementation-defined, ..." > 6.3.2.3p5. Since null pointer constants are described in 6.3.2.3p4, they > are covered by "Except as previously specified". Conversion of > non-constant arithmetic expressions with a value of 0 is NOT covered by > that exception. This means that the implementation-defined result of > such a conversion need not match the standard-defined result for null > pointer constants. After thinking about it a little while, I realized I hadn't worded that quite right, and that my citation was incorrect. Here's a corrected version: Since null pointers are described in 6.3.2.3p3, they are covered by "Except as previously specified". Conversions of integer expressions with a value of 0 to pointer types which are not covered by 6.3.2.3p3 are therefore not covered by that exception, and need not be defined by the implementation to produce the same result. I think that you're assuming that there's some kind of consistency requirement imposed by the standard on the implementation's definition of the result. For instance, that it is determined solely by the integer's value and the type of the pointer. The standard imposes no such requirement. The result could depend upon the type of the integer. It could depend upon the kind of expression used to produce that integer. It could depend upon the phase of the moon, and whether or not today is Friday the 13th. It could be completely random. I can't come up with a good reason for any of those things to be true, but it would not render the implementation non-conforming if they were. If there were such a consistency requirement, it would depend upon the precise wording of that requirement whether or not it requires consistency between the result, when it's implementation-defined, and the result when the implementation has no obligation to provide a definition, because it's standard-defined (by 6.3.2.3p3). However, that issue doesn't come up, because there is no such consistency requirement.