volatile expression

[John Temples]

Given this code:

extern volatile unsigned char v;

int main(void)
{
v;

return 0;
}

My understanding is that that "v;" is an expression statement which
should be "evaluated" as a void expression for side effects, but that
"evaluation " requires an operator. Does changing the statement to

v + 0;

or

(v);

change this?

I have some compilers which do and some compilers which do not access
"v" with the above code.

--
John W. Temples, III

[Tim Rentsch]

Keith Thompson <ks***@mib.or g> writes:

John Temples <us****@xargs-spam.com> writes:

My understanding is that that "v;" is an expression statement which
should be "evaluated" as a void expression for side effects,

[...]

Why do you think that evaluation requires an operator?

There is a flaw in the standard's definiion of "expression ".
C99 6.5p1 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.

which, taken literally, implies that v is not an expression, since it
contains no operators or operands.

It seems true that "v" by itself is an operand, and specifies
computation of a value. Consider

return v;

It also seems true that "v" is a sequence of { operators, operands },
if you get my meaning. So although the wording is a little funny,
the language here could be read to say that "v;" is an expression
and so must be evaluated.

[Keith Thompson]

Tim Rentsch <tx*@alumnus.ca ltech.edu> writes:

Keith Thompson <ks***@mib.or g> writes:

John Temples <us****@xargs-spam.com> writes:

>
> My understanding is that that "v;" is an expression statement which
> should be "evaluated" as a void expression for side effects,
[...]

Why do you think that evaluation requires an operator?

There is a flaw in the standard's definiion of "expression ".
C99 6.5p1 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.

which, taken literally, implies that v is not an expression, since it
contains no operators or operands.

It seems true that "v" by itself is an operand, and specifies
computation of a value. Consider

return v;

An operand is defined, in C99 6.4.6p2, as "an entity on which an
operator acts". return is not an operator.
It also seems true that "v" is a sequence of { operators, operands },
if you get my meaning. So although the wording is a little funny,
the language here could be read to say that "v;" is an expression
and so must be evaluated.

If there's no operator, there's no operand.

To be clear, there is no doubt in my mind that "v" by itself is
(intended to be) an expression. My quibble is with the wording of the
standard's definition; the intent is clear.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Tim Rentsch]

Keith Thompson <ks***@mib.or g> writes:

Tim Rentsch <tx*@alumnus.ca ltech.edu> writes:

Keith Thompson <ks***@mib.or g> writes:

John Temples <us****@xargs-spam.com> writes:
>
> My understanding is that that "v;" is an expression statement which
> should be "evaluated" as a void expression for side effects,

[...]

Why do you think that evaluation requires an operator?

There is a flaw in the standard's definiion of "expression ".
C99 6.5p1 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.

which, taken literally, implies that v is not an expression, since it
contains no operators or operands.

It seems true that "v" by itself is an operand, and specifies
computation of a value. Consider

return v;

An operand is defined, in C99 6.4.6p2, as "an entity on which an
operator acts". return is not an operator.

If I'm not mistaken, 6.4.6p2 also says "other forms of operators also
exist in some contexts".

Is "v" by itself an expression? 6.5.1p2, "An identifier is a primary
expression, provided it has been declared as designating an object
[...]".

Does the appearance of "v" in a return statement make it an
expression? 6.8p2, "A full expression is an expression that is not
part of another expression or declarator. Each of the following is a
full expression: an initializer; the expression in an expression
statement; the controlling expression of a selection statement ('if'
or 'switch'); the controlling expression of a 'while' or 'do'
statement; each of the (optional) expressions of a 'for' statement;
the (optional) expression in a 'return' statement.

It also seems true that "v" is a sequence of { operators, operands },
if you get my meaning. So although the wording is a little funny,
the language here could be read to say that "v;" is an expression
and so must be evaluated.

If there's no operator, there's no operand.

If the notion of operator in 6.4.6p2 were defined exhaustively then it
might be reasonable to conclude that there's no operator. But it's
specifically not exhaustive.

What follows 'return' _is_ an expression; hence the "v" must be an
operand (unless you want to argue that "v" is an operator :); hence
there must be an operator. We can only conclude that the operator
here is one of the "other forms of operators [that] also exist in some
contexts".

Don't get me wrong, I think the wording is poor. But the language
does allow us to conclude that (in an appropriate context) an
identifier by itself is indeed an expression.

[Keith Thompson]

Tim Rentsch <tx*@alumnus.ca ltech.edu> writes:

Keith Thompson <ks***@mib.or g> writes:

Tim Rentsch <tx*@alumnus.ca ltech.edu> writes:

> Keith Thompson <ks***@mib.or g> writes:
>> John Temples <us****@xargs-spam.com> writes:
>> >
>> > My understanding is that that "v;" is an expression statement which
>> > should be "evaluated" as a void expression for side effects,
>>
>> [...]
>>
>> Why do you think that evaluation requires an operator?
>>
>> There is a flaw in the standard's definiion of "expression ".
>> C99 6.5p1 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.
>>
>> which, taken literally, implies that v is not an expression, since it
>> contains no operators or operands.
>
> It seems true that "v" by itself is an operand, and specifies
> computation of a value. Consider
>
> return v;
An operand is defined, in C99 6.4.6p2, as "an entity on which an
operator acts". return is not an operator.

If I'm not mistaken, 6.4.6p2 also says "other forms of operators also
exist in some contexts".

Yes, it does. Section 6.4.6 is about "punctuator s". The "other
forms" clause refers to operators that don't have the form of a single
punctuator, such as the sizeof, cast, and array indexing operators.
You're right, the definition of "operator" in C99 6.4.6p2 is
explicitly not exhaustive. That just means that there are other
things that the standard explicitly refers to as operators.
Is "v" by itself an expression? 6.5.1p2, "An identifier is a primary
expression, provided it has been declared as designating an object
[...]".

Does the appearance of "v" in a return statement make it an
expression? 6.8p2, "A full expression is an expression that is not
part of another expression or declarator. Each of the following is a
full expression: an initializer; the expression in an expression
statement; the controlling expression of a selection statement ('if'
or 'switch'); the controlling expression of a 'while' or 'do'
statement; each of the (optional) expressions of a 'for' statement;
the (optional) expression in a 'return' statement.
In "return v;", yes, v is an expression (or else the statement is
illegal). It's obviously the intent of the standard that v, by
itself, is a legal expression (assuming there's an appropriate
declaration in scope). The only problem is that the standard's
definition of "expression " doesn't correctly express this fact.

(Incidentally, the presence of "v" in "return v;" isn't what implies
that "v" is an expression, any more than the presence of "int" in
"return int;" implies that "int" is an expression. The implication
goes the other way; the fact that "v" is a valid expression implies
that "return v;" is a valid return statement.)

> It also seems true that "v" is a sequence of { operators, operands },
> if you get my meaning. So although the wording is a little funny,
> the language here could be read to say that "v;" is an expression
> and so must be evaluated.

If there's no operator, there's no operand.

If the notion of operator in 6.4.6p2 were defined exhaustively then it
might be reasonable to conclude that there's no operator. But it's
specifically not exhaustive.

If there were any indication in the standard that there's an operator
in either
v;
or
return v;
it would be reasonable to conclude that there is an operator. There
is no such indication.
What follows 'return' _is_ an expression; hence the "v" must be an
operand (unless you want to argue that "v" is an operator :); hence
there must be an operator. We can only conclude that the operator
here is one of the "other forms of operators [that] also exist in some
contexts".

Don't get me wrong, I think the wording is poor. But the language
does allow us to conclude that (in an appropriate context) an
identifier by itself is indeed an expression.

Yes, the wording is poor, but I think your suggested fix requires a
strained interpretation.

C99 6.5p1 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.

Since _expression_ is in italic type, this is the standard's
definition of the term. There is no statement that it's not
exhaustive (and if it's not exhaustive, it's not a definition). It
implies that anything that doesn't consist of "operators and operands"
is not an expression. Of course an identifier that refers to an
object is an expression, but there's no visible operator (and no
justification for assuming that there's an invisible operator), and
therefore no operand (see the definition of "operand").

I suggest that this problem should be fixed by improving the wording
of the definition of "expression ", to acknowledge explicitly that not
all expressions consist of operators and operands. You suggest
leaving the definition as it is, and inventing invisible implicit
operators (which the standard does not mention anywhere) to force
certain cases to fit the definition. Sorry, but I like my idea
better.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[lawrence.jones]

Keith Thompson <ks***@mib.or g> wrote:

In "return v;", yes, v is an expression (or else the statement is
illegal). It's obviously the intent of the standard that v, by
itself, is a legal expression (assuming there's an appropriate
declaration in scope). The only problem is that the standard's
definition of "expression " doesn't correctly express this fact.

Most definitions are incomplete in one way or another -- check any
dictionary for numerous examples. That fact that the English definition
of "expression " in the standard misses the degerate case that's included
in the formal (BNF) definition doesn't bother me at all; I don't expect
that any reader will be seriously confused or think that the informal
definition somehow overrides the formal one. Trying to enhance the
current definition to be more complete strikes me as errant pedantry.

-Larry Jones

The living dead don't NEED to solve word problems. -- Calvin