By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,664 Members | 1,970 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,664 IT Pros & Developers. It's quick & easy.

Concept of Statements and Expressions

P: n/a
Hello, i would like to know what the serious definition of statements
and expressions is:

i know an expression are evaluated to a value, i.e:
1 == 2
5+7
foo( 1,2)

and a statement is executed:
break;
5+7;
if( foo(1,2) ){ ... }

but...
How does the C standard define Statements and Expressions??
And what about expression statements?

TIA

May 10 '06 #1
Share this Question
Share on Google+
20 Replies


P: n/a

Neroku wrote:
Hello, i would like to know what the serious definition of statements
and expressions is:

i know an expression are evaluated to a value, i.e:
1 == 2
5+7
foo( 1,2)

and a statement is executed:
break;
5+7;
if( foo(1,2) ){ ... }

but...
How does the C standard define Statements and Expressions??
And what about expression statements?


6.5p1 Expressions
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. [...]

6.8p2 Statements and blocks
A statement specifies an action to be performed. [...]

Look for N1124.pdf to see the rest of the definitions. There's to much
to paste here.

May 10 '06 #2

P: n/a
Vladimir Oka wrote:
6.5p1 Expressions
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. [...]


That includes the invisible operator.

--
pete
May 10 '06 #3

P: n/a
"Vladimir Oka" <no****@btopenworld.com> writes:
Neroku wrote:
Hello, i would like to know what the serious definition of statements
and expressions is:

i know an expression are evaluated to a value, i.e:
1 == 2
5+7
foo( 1,2)

and a statement is executed:
break;
5+7;
if( foo(1,2) ){ ... }

but...
How does the C standard define Statements and Expressions??
And what about expression statements?


6.5p1 Expressions
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. [...]


This definition is actually inaccurate. For example,
42
is clearly an expression, but it contains no operators and therefore
no operands. (No, there's no implicit invisible operator.)

--
Keith Thompson (The_Other_Keith) 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.
May 10 '06 #4

P: n/a
On 2006-05-10, Neroku <n3****@gmail.com> wrote:
Hello, i would like to know what the serious definition of statements
and expressions is:

i know an expression are evaluated to a value, i.e:
1 == 2
5+7
foo( 1,2)
Yes exactly.
and a statement is executed:
break;
5+7;
if( foo(1,2) ){ ... }
[...]


This is a good question. One way to think of the difference is in terms
of "functional" versus "imperative" programming.

An expression is, in a sense, an implicit formulation of the result you
want, a statement is more like an explicit instruction to the computer to
do something.

int a = b + c / d;

This is a statement, that initializes a with the result of evaluating
the expression "b + c / d".

We tell the computer explicitly to initialize a. We tell it that what we
want to initialize a with is "whatever b + c / d" comes to. The computer
can work out b + c / d however it wants to. This is a much more
"implicit" way of talking to the computer.

We could achieve the same result with a series of statements:

int a = c;
a /= d;
a += b;

You could say this is a "more imperative" and "less functional"
version of the program.

Expressions sometimes have side-effects.

printf("Hello\n")

is an expression. It evaluates to 5 (provided there were no errors). But
it also has a side-effect-- while the machine is evaluating it, it also
writes the string "Hello" to the terminal.

Usually with an expression like this we aren't interested in the value,
only in the side-effect. In C you can even define "void" valued
functions. A void valued function would be useless if it weren't for the
side-effects.

In "pure functional" (or nearly pure anyway) languages, like Scheme for
example, there are no statements, only expressions.

Assembly language on the other hand is much closer to a "pure"
imperative language-- the program is a series of statements each of
which tells the computer to do something.

These are just some thoughts on the concepts of expression and
statement. You could say that an assembly language program was a series
of void-valued functions with side-effects, but that would be a slightly
odd way to look at it. The underlying idea seems to be, are we telling
the machine what to do step by step, or are we expressing the result we
want and telling the machine to go away and work it out. We see this
kind of duality reflected all over the place whenever we go near a
computer. What's known as a "function" in C is called a "procedure" in
other languages, or sometimes a "subroutine". "Function" is an implicit,
expression type of word, "procedure" and "routine" are explicit,
statement type of words. But they come to mean pretty much the same
thing. All this is probably a consequence of the "Church-Turing Thesis".

Anyway, C, like many languages, is a mix of both imperative and
functional styles; it's also a property of C that any expression can be
used as a statement (this is true of some other popular languages, but
untrue of others-- in Python for example you cannot use any expression
as a statement). But every statement is not an expression:

break;

for example is a statement but not an expression. Most of the time in C
you will see ; between statements, so that's an easy way to spot them.

In terms of the grammar of C, a program is a series of statements, and
some kinds of statements may be made up of expressions. Expressions
themselves may be recursively defined (an "arithmetic expression" for
example might be defined as something like "an expression followed by an
operator followed by another expression"). Really for the serious
definitions of what statement and expression mean in C, the C grammar is
the place to start.
May 10 '06 #5

P: n/a
Keith Thompson wrote:
"Vladimir Oka" <no****@btopenworld.com> writes:
Neroku wrote:
Hello, i would like to know what the serious definition of statements
and expressions is:

i know an expression are evaluated to a value, i.e:
1 == 2
5+7
foo( 1,2)

and a statement is executed:
break;
5+7;
if( foo(1,2) ){ ... }

but...
How does the C standard define Statements and Expressions??
And what about expression statements?

6.5p1 Expressions
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. [...]


This definition is actually inaccurate. For example,
42
is clearly an expression, but it contains no operators and therefore
no operands. (No, there's no implicit invisible operator.)

Right. My reasoning is that "42" is an rvalue expression (where an
expression is defined as "one or more terms and zero or more operators")
consisting of a single term which is an integer constant.

Now, in this context is the rvalue expression dropped via a class
conversion to result in a void expression?
May 10 '06 #6

P: n/a
Ben C wrote:
int a = b + c / d;

This is a statement


No, it isn't.
It's a declaration and a definition and an initialization,
but it isn't a statement.

In C, all simple statements occur
inside of compound statements, {a.k.a. blocks}.
The bodies of function definitions, are compound statements.
Compound statements can also occur
inside of other compound statements.

In C89,
no statements may precede any object or function declarations,
within the same compound statement.

--
pete
May 10 '06 #7

P: n/a

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Vladimir Oka" <no****@btopenworld.com> writes:
Neroku wrote:
Hello, i would like to know what the serious definition of statements
and expressions is:

i know an expression are evaluated to a value, i.e:
1 == 2
5+7
foo( 1,2)

and a statement is executed:
break;
5+7;
if( foo(1,2) ){ ... }

but...
How does the C standard define Statements and Expressions??
And what about expression statements?


6.5p1 Expressions
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. [...]


This definition is actually inaccurate. For example,
42
is clearly an expression, but it contains no operators and therefore
no operands. (No, there's no implicit invisible operator.)


From what I see of 6.5p1, 42 is clearly not an expression (Iocane powder
anyone?). Therefore, it must be a statement. But, it performs no action...

6.8 Statements and blocks
2 A statement specifies an action to be performed.

Annex I (informative) Common warnings
* A statement with no apparent effect is encountered (6.8).
Rod Pemberton
May 10 '06 #8

P: n/a
void * clvrmnky() wrote:

Keith Thompson wrote:
"Vladimir Oka" <no****@btopenworld.com> writes:
6.5p1 Expressions
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. [...]
This definition is actually inaccurate. For example,
42
is clearly an expression,
but it contains no operators and therefore no operands.
(No, there's no implicit invisible operator.)


Not really.
Right. My reasoning is that "42" is an rvalue expression
(where an expression is defined as
"one or more terms and zero or more operators")
consisting of a single term which is an integer constant.
You just made that up.

The standard says:
What is sometimes called ‘‘rvalue’’
is in this International Standard
described as the ‘‘value of an expression’’.
Now, in this context is the rvalue expression dropped via a class
conversion to result in a void expression?


There is no context provided. 42 is just 42.
The expression statement
42;
is executed and evaluated as
(void)42;

N869
6.8.3 Expression and null statements
Semantics
[#2] The expression in an expression statement is evaluated
as a void expression for its side effects.

--
pete
May 10 '06 #9

P: n/a
Rod Pemberton wrote:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Vladimir Oka" <no****@btopenworld.com> writes:
Neroku wrote:
> Hello, i would like to know what the serious definition of statements
> and expressions is:
>
> i know an expression are evaluated to a value, i.e:
> 1 == 2
> 5+7
> foo( 1,2)
>
> and a statement is executed:
> break;
> 5+7;
> if( foo(1,2) ){ ... }
>
> but...
> How does the C standard define Statements and Expressions??
> And what about expression statements?

6.5p1 Expressions
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. [...]


This definition is actually inaccurate. For example,
42
is clearly an expression, but it contains no operators and therefore
no operands. (No, there's no implicit invisible operator.)


From what I see of 6.5p1, 42 is clearly not an expression (Iocane powder
anyone?). Therefore, it must be a statement. But, it performs no action...


6.5.1p3:
A constant is a primary expression.

Robert Gamble

May 10 '06 #10

P: n/a
Rod Pemberton wrote:
From what I see of 6.5p1, 42 is clearly not an expression
It's a good thing that it isn't.
If it was, 42 would be an lvalue,
and evaluating it would cause undefined behavior.

ISO/IEC 9899:1999

6.3.2 Other operands
6.3.2.1 Lvalues, arrays, and function designators

1 An lvalue is an expression with an object type or an incomplete type
other than void;
if an lvalue does not designate an object when it is evaluated,
the behavior is undefined.
(Iocane powder anyone?).


The standard committee,
is usually more concerned with fixing wording
that causes actual problems,
than with fixing wording
just because the wording doesn't make sense.

--
pete
May 10 '06 #11

P: n/a
On 2006-05-10, pete <pf*****@mindspring.com> wrote:
Ben C wrote:
int a = b + c / d;

This is a statement
No, it isn't.
It's a declaration and a definition and an initialization,
but it isn't a statement.

In C, all simple statements occur
inside of compound statements, {a.k.a. blocks}.
The bodies of function definitions, are compound statements.
Compound statements can also occur
inside of other compound statements.


You're quite right, my bad. I checked the grammar in Annex A of N1124

int a = b + c / d

is a declaration, and a declaration isn't a statement.
In C89,
no statements may precede any object or function declarations,
within the same compound statement.


Yes, it seems to make more sense for declarations not to be statements
in C89 because it's a parse-error to have a declaration half-way down a
block.

But also, as you indicate, there's another reason to distinguish which
is that declarations can be outside blocks.

Anyway, if you change what I wrote to

int a;
a = b + c / d;

The second line is a statement, made up of an expression followed by a
semicolon.
May 10 '06 #12

P: n/a
pete wrote:
void * clvrmnky() wrote:
Keith Thompson wrote:
"Vladimir Oka" <no****@btopenworld.com> writes: 6.5p1 Expressions
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. [...]
This definition is actually inaccurate. For example,
42
is clearly an expression,
but it contains no operators and therefore no operands.
(No, there's no implicit invisible operator.)

Not really.
Right. My reasoning is that "42" is an rvalue expression
(where an expression is defined as
"one or more terms and zero or more operators")
consisting of a single term which is an integer constant.


You just made that up.

J'Accuse!

Made what up, specifically? The definition of an expression? Well
/someone/ made it up, but it sure wasn't me! I (unfortunately) do not
have the real Standard in front of me, and find it painfully obtuse when
I do. I mostly make do with the brief discussion here:
<http://www-ccs.ucsd.edu/c/express.html>

Is there something wrong with this general discussion of C expressions?
The standard says:
What is sometimes called ‘‘rvalue’’
is in this International Standard
described as the ‘‘value of an expression’’.
Now, in this context is the rvalue expression dropped via a class
conversion to result in a void expression?
There is no context provided. 42 is just 42.
The expression statement
42;
is executed and evaluated as
(void)42;

Isn't this, then, an rvalue subcontext where an rvalue expression is
converted to a void expression? I cheerfully admit I'm unclear on what
is referred to as "[sub]context", and we may be speaking about two or
more different things.
N869
6.8.3 Expression and null statements
Semantics
[#2] The expression in an expression statement is evaluated
as a void expression for its side effects.

Which is sort of where I ended up, along a different path. Close enough
for me if I read the code as a parser (and not a lawyer).
May 10 '06 #13

P: n/a
"Rod Pemberton" <do*********@bitfoad.cmm> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Vladimir Oka" <no****@btopenworld.com> writes:
> Neroku wrote:
>> Hello, i would like to know what the serious definition of statements
>> and expressions is:
>>
>> i know an expression are evaluated to a value, i.e:
>> 1 == 2
>> 5+7
>> foo( 1,2)
>>
>> and a statement is executed:
>> break;
>> 5+7;
>> if( foo(1,2) ){ ... }
>>
>> but...
>> How does the C standard define Statements and Expressions??
>> And what about expression statements?
>
> 6.5p1 Expressions
> 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. [...]


This definition is actually inaccurate. For example,
42
is clearly an expression, but it contains no operators and therefore
no operands. (No, there's no implicit invisible operator.)


From what I see of 6.5p1, 42 is clearly not an expression (Iocane powder
anyone?). Therefore, it must be a statement. But, it performs no action...


Your reasoning is faulty on several levels.

You're assuming that 42 must be either an expression or a statement.
There is no basis for this assumption.

The language grammar for "expression" very clearly shows that 42 is an
expression (the sequence of steps is lengthy but straightforward).

If you assume that the standard's definition of "expression" in 6.5p1
is to be taken literally, it doesn't just imply that 42 is not an
expression; it leads to contradictions with other, equally normative,
parts of the standard itself. The *only* way to resolve this is to
accept that the definition of "expression" in 6.5p1 is faulty. The
standard was written by imperfect mortals; these things happen.
(Similar considerations apply to the standard's definition of
"lvalue".)

--
Keith Thompson (The_Other_Keith) 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.
May 10 '06 #14

P: n/a
pete wrote:
Rod Pemberton wrote:
From what I see of 6.5p1, 42 is clearly not an expression


It's a good thing that it isn't.
If it was, 42 would be an lvalue,
and evaluating it would cause undefined behavior.

ISO/IEC 9899:1999

6.3.2 Other operands
6.3.2.1 Lvalues, arrays, and function designators

1 An lvalue is an expression with an object type or an incomplete type
other than void;


42 is a constant and a primary expression but it is not an object.

Robert Gamble

May 10 '06 #15

P: n/a
void * clvrmnky() wrote:

pete wrote:
void * clvrmnky() wrote:
Keith Thompson wrote:
"Vladimir Oka" <no****@btopenworld.com> writes:
> 6.5p1 Expressions
> 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. [...]
This definition is actually inaccurate. For example,
42
is clearly an expression,
but it contains no operators and therefore no operands.
(No, there's no implicit invisible operator.)


Not really.
Right. My reasoning is that "42" is an rvalue expression
(where an expression is defined as
"one or more terms and zero or more operators")
consisting of a single term which is an integer constant.


You just made that up.

J'Accuse!

Made what up, specifically? The definition of an expression?


Yes.
Well
/someone/ made it up, but it sure wasn't me! I (unfortunately) do not
have the real Standard in front of me,
and find it painfully obtuse when I do.
I mostly make do with the brief discussion here:
<http://www-ccs.ucsd.edu/c/express.html>

Is there something wrong
with this general discussion of C expressions?


Not too bad.
A few nits here and there:

"A function-designator subcontext designates a function.
Hence, its expression has a function type.
You create a function-designator subcontext
wherever you need to call a function or determine its address."

You can use an expression of function type to make a function call,
but a pointer to a function expression,
which itself has an object type,
is really what's needed to make a function call.
If a function call is made with an expression of function type,
then that expression is converted to a pointer first.

There's some original vocabulary in there.
Later down this post, where you use the phrase "a class conversion",
I assume it means the same thing as "a type conversion",
or what I would just refer to as "a conversion".
The standard says:
What is sometimes called ‘‘rvalue’’
is in this International Standard
described as the ‘‘value of an expression’’.
Now, in this context is the rvalue expression dropped via a class
conversion to result in a void expression?


There is no context provided. 42 is just 42.
The expression statement
42;
is executed and evaluated as
(void)42;

Isn't this, then, an rvalue subcontext where an rvalue expression is
converted to a void expression?


The classes of subcontext are not familiar to me
and I believe they are irrelevant
to the issue of expression statement evaluation.
N869
6.8.3 Expression and null statements
Semantics
[#2] The expression in an expression statement is evaluated
as a void expression for its side effects.

Which is sort of where I ended up, along a different path.
Close enough
for me if I read the code as a parser (and not a lawyer).


--
pete
May 10 '06 #16

P: n/a
"Robert Gamble" <rg*******@gmail.com> writes:
pete wrote:
Rod Pemberton wrote:
> From what I see of 6.5p1, 42 is clearly not an expression


It's a good thing that it isn't.
If it was, 42 would be an lvalue,
and evaluating it would cause undefined behavior.

ISO/IEC 9899:1999

6.3.2 Other operands
6.3.2.1 Lvalues, arrays, and function designators

1 An lvalue is an expression with an object type or an incomplete type
other than void;


42 is a constant and a primary expression but it is not an object.


42 is an expression of type int. int is an object type. Therefore 42
is an expression with an object type.

The *intent* is that an lvalue is an expression that (potentially)
refers to an object. (I say "potentially" because *ptr is an lvalue
even if ptr==NULL.) The C99 standard's definition, unfortunately,
does not express that intent.

--
Keith Thompson (The_Other_Keith) 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.
May 10 '06 #17

P: n/a
Robert Gamble wrote:

pete wrote:
Rod Pemberton wrote:
From what I see of 6.5p1, 42 is clearly not an expression


It's a good thing that it isn't.
If it was, 42 would be an lvalue,
and evaluating it would cause undefined behavior.

ISO/IEC 9899:1999

6.3.2 Other operands
6.3.2.1 Lvalues, arrays, and function designators

1 An lvalue is an expression with
an object type or an incomplete type
other than void;


42 is a constant and a primary expression but it is not an object.


Yes, and evaluating 42 doesn't cause undefined behavior.
It's in the "but everyone knows clause".
You can google that phrase on comp.std.c, for one hit.

--
pete
May 10 '06 #18

P: n/a
On 2006-05-10, Robert Gamble <rg*******@gmail.com> wrote:
pete wrote:
Rod Pemberton wrote:
> From what I see of 6.5p1, 42 is clearly not an expression


It's a good thing that it isn't.
If it was, 42 would be an lvalue,
and evaluating it would cause undefined behavior.

ISO/IEC 9899:1999

6.3.2 Other operands
6.3.2.1 Lvalues, arrays, and function designators

1 An lvalue is an expression with an object type or an incomplete type
other than void;


42 is a constant and a primary expression but it is not an object.


But it has an object type - specifically, int. or const int. it doesn't
really matter since it's not an lvalue.
May 10 '06 #19

P: n/a
On 2006-05-10, pete <pf*****@mindspring.com> wrote:
Robert Gamble wrote:

pete wrote:
> Rod Pemberton wrote:
>
> > From what I see of 6.5p1, 42 is clearly not an expression
>
> It's a good thing that it isn't.
> If it was, 42 would be an lvalue,
> and evaluating it would cause undefined behavior.
>
> ISO/IEC 9899:1999
>
> 6.3.2 Other operands
> 6.3.2.1 Lvalues, arrays, and function designators
>
> 1 An lvalue is an expression with
> an object type or an incomplete type
> other than void;


42 is a constant and a primary expression but it is not an object.


Yes, and evaluating 42 doesn't cause undefined behavior.
It's in the "but everyone knows clause".
You can google that phrase on comp.std.c, for one hit.


A hit which omits the obvious, and IMO more likely to be problematic
than others,

extern int main(int argc, char *argv[argc+1]);
May 10 '06 #20

P: n/a
Jordan Abel wrote:
more likely to be problematic than others,

extern int main(int argc, char *argv[argc+1]);


What do you mean?

--
pete
May 10 '06 #21

This discussion thread is closed

Replies have been disabled for this discussion.