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: Wed, 21 Jun 2017 09:54:43 -0700 Organization: None to speak of Lines: 79 Message-ID: References: <9zM1B.193976$KK7.183000@fx12.am4> <87shiwc4il.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="8cc19fbd15268f370d21bccaa4b22cfe"; logging-data="16486"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/4pHt7ExPrd+Xk1BeCF6G1" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:JW7V9U9hnorrLRrlCIRMJ3HeYjI= sha1:s3kFVFZGEvCSvVFS1wIEoFP5AAs= Xref: csiph.com comp.lang.c:112806 Tim Rentsch writes: [...] > In comp.lang.c there is a game some people like to play, which > might be called "let's pretend the meaning of English words > and phrases used in the Standard is single-valued (and by the > way uses the values that I think it should)". Usually it's > easy to tell when people are playing it, because there are > giveaway phrases like "literal meaning" or "strictly speaking" > or "what the words actually say" in the comments. It's a fun > game, and I play it myself on occasion. However, please don't > fall into the trap of making it more than it is, because even > though it's fun to play it doesn't match how the authors of > the Standard interpret the text. To some extent, sure, it can be a game, but that's not all it is. For example, when I point out that the definition of "expression" is flawed, I'm not arguing that 0 really isn't an expression. Rather, I'm advocating a change to the wording of the standard to reflect its intent -- and meanwhile, I accept the need to use a bit of common sense, using the obvious intent behind the words rather than the literal words themselves to determine what is and is not an expression. > In an expression-statement like '0;', there is no doubt that '0' > is an expression and also an operand within that expression. Could it be that you're playing the game yourself? We have two inconsistent definitions, a definition of "expression" that requires it to include "operands", and a definition of "operand", "an entity on which an operator acts". The latter seems clear, unambiguous, and consistent with the usual English meaning of the word -- which suggests that it's the definition of "expression" that needs to be fixed. I have no doubt that 0 is an expression. I do not believe that, if it appears as a full expression, it is an "operand", nor do I think it's useful to invent a mythical implicit "operator" to make it one. On the other hand, the term "operand" could be redefined, but I don't think that's the simplest and clearest solution. I'd like a definition of "expression" that does not require it to contain operators and/or operands. Simply deferring to the grammar is one way to do that. [...] > For 6.6 p6, it might seem like "operand" is being used in a way > that is not consistent with its definition. The definition of "constant expression" also needs some work, I think. On the other hand, I've read that definition before and not noticed the problems; I subconsciously glossed over the inconsistencies. > What is actually > going on is more subtle. In most cases where the Standard uses > "operand" there is an abuse of language going on. Consider an > expression like '1+2*3'. The operator '+' does not "act on" the > expression '2*3'. Rather the operation of addition "acts on" the > result of evaluating '2*3'. There is an inherent ambiguity > between results at runtime and their corresponding syntactic > forms at translation time. Yes, glossing over the distinction between constructs that appear in C source and/or at compile time vs. constructs that exist at run time is very common, and may be nearly inevitable. Describing the language in a way that always makes that distinction clearly might be an interesting challange. Doing so in a way that's legible to a typical reader would be even more so. [snip] -- 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"