Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Null pointer constant Date: Mon, 19 Jun 2017 12:31:22 -0700 Organization: None to speak of Lines: 68 Message-ID: References: <9zM1B.193976$KK7.183000@fx12.am4> <867a18ef-7ae6-2fe1-7f11-563b0572425c@verizon.net> <170019a8-640f-5152-5f98-d0270dc71b47@verizon.net> <97aef68d-40f4-f8ef-6167-f386abe06f2e@verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="6cbb5d51c319bdfdc6c4f737cfea8267"; logging-data="11779"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/vWlnl9v2bjkEIvokVjk4Z" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:zis3NqfIubB8dhPKoxrZWWRgsJM= sha1:EXTt1Y1UiVGEawXQ1QApcfb1Ad8= Xref: csiph.com comp.lang.c:112617 "James R. Kuyper" writes: > On 06/19/2017 01:29 PM, Ike Naar wrote: >> On 2017-06-19, James R. Kuyper wrote: >>> On 06/19/2017 11:51 AM, Ike Naar wrote: >>>> On 2017-06-19, James R. Kuyper wrote: [...] >>>>> While 0+0 is fine, 6-2*3 is not: the right operand of the subtraction >>>>> operator is a multiplication expression, which doesn't fall into any of >>>>> listed categories of allowed operands. >>>> >>>> According to the syntax, the right operand of the subtraction operator >>>> is always a multiplicative-expression. >>> >>> True, but not relevant, which I was trying to hint at by referring to it >>> as a "multiplication expression" (which isn't one of the standard-define >>> grammar terms), rather than "multiplicative-expression". As I'm using >>> the term, a "multiplicative expression" is one that actually has a >>> multiplication as it's operator. >>> >>> For comparison: 5 is a constant. As a result, it is also a >>> primary-expression, a postfix-expression, a unary-expression, and a >>> multiplicative-expression (assuming it occurs in a location where >>> expressions of one of those types are permitted by the grammar). But, as >>> a constant, 5 meets the requirements in 6.6p6 for an operand in an >>> integer constant expression. In contrast, the only one of those terms >>> that describes 2*3 is multiplicative-expression, and that's not enough >>> to qualify it for use in that context. >> >> 6.6 >> constant-expression >> conditional-expression >> >> 6.6p6 >> An integer constant expression shall have integer type and >> shall only have operands that are integer constants, [...] >> >> I take it that the term 'operands' in this sentence refers to the >> operands that appear in the full derivation of the constant-expression, >> that is, in the derivation >> [SNIP] >> >> the term 'operands' in 6.6p6 refers to '6', '2' and '3'. > > That would be another way of fixing this problem, equivalent to one > which I've used internally for several years: 6.6p6 applies only to > "leaf operands", that is, operands which are not themselves expressions > with sub-expressions. However, while preparing my first message for this > thread, I came to the conclusion that a recursive reference to integer > constant expressions would be a cleaner way to fix this problem. > > The point is, these ARE fixes. The wording as it is currently written > doesn't provide any justification for applying 6.6p6 only to > leaf-operands. As written, it applies to all operands, including those > that are expressions with sub-expressions. And one item in the list of allowed "operands" is sizeof expressions whose results are integer constants Given that sizeof is treated as an operator that takes an operand, it can't be a leaf expression. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"