On 09/06/2026 14:17, Janis Papanagnou wrote:Well, I'd do that as it's done in other languages.On 2026-06-08 23:05, Keith Thompson wrote:I think it is just difficult for the syntax to ban certain expressons and not others. How would you express that in the grammar?[...]>
I've discussed this particular glitch before, but it's been a while.
>
N3220 6.5.1 says:
>
An *expression* is a sequence of operators and operands that
specifies computation of a value, or that designates an object
or a function, or that generates side effects, or that performs
a combination thereof.
>
I believe the wording is unchanged from C90 up to the latest C202y
draft. Since the word "expression" is in italics, this is the
standard's definition of the word.
>
This is a flawed definition. The terms "operator" and "operand"
are defined in 6.4.6:
>
*punctuator: one of
[ ] ( )
[snip]
A punctuator is a symbol that has independent syntactic and semantic
significance. Depending on context, it may specify an operation to
be performed (which in turn may yield a value or a function
designator, produce a side effect, or some combination thereof) in
which case it is known as an *operator* (other forms of operator also
exist in some contexts). An *operand* is an entity on which an
operator acts.
>
Consider this expression statement:
>
42;
>
Is `42` an expression? Clearly it's intended to be, but there is no
operator, and therefore there is no operand, so it doesn't meet the
standard's definition of the word "expression".
Above you used the term "expression statement", and then compare the
"42" to an "expression".
>
I know from my earlier C-days that '42;' is a valid statement, and so
the term "expression statement" makes sense to me.
>
I know from various languages' syntax definitions that a number like
'42' is a sensible form for an expression (and no operators required).
It's also depending on the context. Where expressions may be written
(and where not) depends on the concrete language; syntactically and
also semantically.
>
Usually I'd expect above "expression-statement" to serve some purpose,
semantically. I don't recall that in "C" such an expression-statement
would serve any purpose. (Or that they'd show any observable behavior,
if that term fits the C-parlance better?)
>
Or do these stand-alone values (the "expression-statement") have some
practically useful semantics?
>
In other languages such stand-alone values serve a purpose; e.g. they
may determine the result value of a block that can then be used in an
outer context; but in "C" such constructs are obviously not possible.
>
What purpose serve such stand-alone numbers in places where statements
are expected?
Define _statements_ and define _expressions_. And defined expressions
in contexts where a sensible operational semantics can be defined (as
in mathematical formulas, actual function parameter lists, etc.), but
not in places where statements are expected.
If you ramp up the warnings, then you'll get messages like 'statement with no effect' or 'computed value not used', since sometimes there are side-effects that are needed:Right. And I wouldn't allow a mathematical formula where the results
f() + g();
f() and g() both do something, but nothing is done with their sum.
are calculated but not used, here an expression, as a statement.
But your example may indeed lead to the actual answer to my question;
when writing just
f();
There's no distinction of procedures and functions in "C". One cannot
tell whether that f() is a "procedure" (i.e. a function with no return
value, or one with return value but the call just relying on the side
effects). In "C" any value of f() just gets discarded in this context.
That of course doesn't mean that it could be handled by the compilers
and sensibly defined by the language, depending on how f() is actually
defined. After all, 'f();' is not the same case as '42;'.
But okay, we're talking about "C" here - so own design preferences are
anyway irrelevant here.
Janis
[...]
Les messages affichés proviennent d'usenet.