role of semicolon

[Merrill & Michele]

#include <stdio.h>
int main(void)
{
int i = 0;
++ i; ++ i;
printf("i equals %d\n", i);
return 0;
}

I've been trying to determine the great and manifold uses of the semicolon
in c. It's not such an easy thing. Q1) Is the above prog conforming? My
compiler likes it just fine. Q2) If so, how many statements are in main?
MPJ

[Lawrence Kirby]

On Fri, 17 Dec 2004 16:52:40 -0600, Merrill & Michele wrote:

"Lawrence Kirby"

> Alex Fraser wrote: > Part of the definition of main is the compound-statement, from the '{' to > the '}' inclusive. A compound-statement is a statement, so if you count that > too, then the answer is five.

Interestingly this is an example (and the only one) of when a compound
statement ISN'T a statement. Check the grammar.

[uses cordless keyboard+mouse for 1st time and wonders how he endured life
before]

I believe Mr. Kirby refers to a statement such as:
i = 6; ++j;
and calls this a compound statement.

I was just using the Standard's definition of a compound statement which
as others have said has the form { } enclosing a sequence of 0 or more
declarations and statements.

Lawrence

[Lawrence Kirby]

On Sat, 18 Dec 2004 00:49:42 +0000, Keith Thompson wrote:

"Mike Wahler" <mk******@mkwahler.net> writes:
[...]

I'm absolutely sure what he's referring to, but
I think he means that the { and } which delimit
a function body do not comprise a 'compound statement'.
(So I believe my 'didn't think of that' remark elsethread should
be retracted. :-))
Actually, according to the grammar, it is a "compound-statement", but
it's not a "statement".

A "function-definition" consists of:

declaration-specifiers declarator declaration-list(opt) compound-statement

This is the only occurrence of "compound-statement" in the grammar
that's not a "statement".

Note that if the grammar required a "statement" here rather than a
"compound-statement", the following would be legal:

int foo(void)
return 42; /* not legal C */

More problematically

int foo(void);

would be a valid function definition because plain ; is a valid statement.
Instead, we have to write:

int foo(void)
{
return 42;
}
}
The claim that this "compound-statement" is not a "statement" is based
on a painfully literal reading of the grammar. If you want to argue
that a compound statement must be a statement (by the rules of ordinary
English grammar), I won't disagree too strongly.

I originally mentioned it as a curiosity. However forgetting the language
grammar for a second is it actually useful to think of a function body as
a statement? IMO there is too much incorrect baggage with that
association, just think of a function body as a function body and a
compound statement, which are correct.

Lawrence

[Lawrence Kirby]

On Sat, 18 Dec 2004 02:34:53 +0000, Dik T. Winter wrote:

In article <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:

> The claim that this "compound-statement" is not a "statement" is based
> on a painfully literal reading of the grammar.
Depends on which way you wish to go in the grammar.

However you do it there is no way using valid productions in the C grammar
for a statement non-terminal to be produced in the position if a function
body. It can only be a compound-statement.
A compound-statement
is a specific form of a statement (and has been so since the introduction
of the term in Algol 60). So, by all means, the function body is a
statement of particular form (and that was not the case in Algol 60).
No, it isn't a statement of a particular form. It has the same form as a
particular subclass of statement but that doesn't make it a statement.

Now that could be viewed as a defect in the standard if you expect the
semantics of C90 6.6/C99 6.8 (the clause defining a statement) to be
applied to an overall function body, because as it stands they are not. It
looks to me like C99 6.8 p2 and p3 should be moved to 6.8.2 because they
apply specifically to compound statements (you only get a sequence of
statements within a compound statement, and the term "block" specifically
relates to a compound statement).
In my opinion when Lawrence wrote that that particular compound-statement
was not a statement, he was wrong.

As far as the C standard is concerned I don't see any other way to
interpret it. Whether the C standard is defective in that respect (but
the fix I suggested doesn't make a function body a statement) and whether
it makes sense to consider a function body as a statement in more informal
discussion are different issues. My view on the second issue is mostly
"no", it creates more confusion than clarification.

Lawrence

[Lawrence Kirby]

On Sun, 19 Dec 2004 01:26:11 +0000, Dik T. Winter wrote:

In article <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
...

> Clearly a compound-statement is a kind of statement if it appears in a
> statement context. If it appears in a different context, the only
> real basis for claiming that it's a "statement" is that the name of
> the construct ends in "-statement".
Wait a moment. Is 42 an expression?

Good question. It can be but in, for example, the context of

enum { x = 42 };

it is a constant-expression, there is no "expression" language element
here, even though it has the correct form for an expression. Naturally we
would want to consider 42 and things like 40+2 as expressions for the
purposes of normal discussion even in contexts like this. Luckily we can
and be consistent with the standard because it defines the term
"expression" independently of the syntax non-terminal "expression". This
is not the case for "statement".
My reasoning is *not* based on the name, it is based on the production
rules. "statement" is the only production rule that produces
"compound-statement" without anything else. And that is why I say that
it is a particular form of a statement.
To do that you need to run productions forwards to create a
compound-statement and then backwards to derive a statement from that.
That is not a valid application of production rules.
Your point would have been
stronger when the syntax had been:
function-definition:
declaration-specifiers declarator declaration-list(opt)
function-body
function-body:
compound-statement

But that's a distinction that makes no difference.

Lawrence

[Merrill & Michele]

"Lawrence Kirby" <lk****@netactive.co.uk> wrote in message
news:pa***************************@netactive.co.uk ...

On Fri, 17 Dec 2004 16:52:40 -0600, Merrill & Michele wrote:

"Lawrence Kirby"
> Alex Fraser wrote:

> Part of the definition of main is the compound-statement, from the

'{' to

> the '}' inclusive. A compound-statement is a statement, so if you

count that

> too, then the answer is five.

Interestingly this is an example (and the only one) of when a compound
statement ISN'T a statement. Check the grammar.

[uses cordless keyboard+mouse for 1st time and wonders how he endured life before]

I believe Mr. Kirby refers to a statement such as:
i = 6; ++j;
and calls this a compound statement.

I was just using the Standard's definition of a compound statement which
as others have said has the form { } enclosing a sequence of 0 or more
declarations and statements.

There was many things I didn't realize about the simple code I posted. MPJ

[Merrill & Michele]

"Merrill & Michele" <be********@comcast.net> wrote in message
news:vu********************@comcast.com...

"Michael Mair" <Mi**********@invalid.invalid> wrote in message
news:32*************@individual.net...

Merrill & Michele wrote:

"pete" <pf*****@mindspring.com> wrote in message
news:41***********@mindspring.com...

>Merrill & Michele wrote:
>
>>Another nuance. What all belongs to whitespace char family? MPJ
>(space, horizontal tab, new-line, vertical tab, and form-feed)

I'm always glad when pete is the man who has the back of the man who needs to use hemorrhoidal creme. These must have representations not linked to integers. I threw away K&R2 today. MPJ
In reverse order:
Your loss.
The only thing I lost was you. Habe ich Dich verlegt oder verloren?
' ', '\t', '\n', '\v', '\f'; pete forgot '\r' (carriage return); just
read K&R2 -- oh, too late.
I hereby award you the questionable order of the *PLONK*.

Please refrain from using poor English where I have to read it. How could
hemorrhoids be germane to c? Because I've been scratching my ass like
someone possessed for the last few weeks. You try, in polite conversation, to use euphemisms with your snickering wife. Thus, semicolon. Hemorrhoids was a joke but missing a semicolon gets you axed around me. Tschueß,

jens.

Now, seriously fellas, many among us lead other programmers. If you've got
someone working for you who can't seem to sit down and looks like he's got
an acetylene torch on his : , tell him it's not going to get better until he
shoves .h up his butt. It's a bridge that some of us haven't crossed
before.

BTW I hid my K&R at the Kneipe. Sorftiger Eingang. MPJ

[Keith Thompson]

Lawrence Kirby <lk****@netactive.co.uk> writes:

On Sun, 19 Dec 2004 01:26:11 +0000, Dik T. Winter wrote:

[...]

Wait a moment. Is 42 an expression?

Good question. It can be but in, for example, the context of

enum { x = 42 };

it is a constant-expression, there is no "expression" language element
here, even though it has the correct form for an expression. Naturally we
would want to consider 42 and things like 40+2 as expressions for the
purposes of normal discussion even in contexts like this. Luckily we can
and be consistent with the standard because it defines the term
"expression" independently of the syntax non-terminal "expression". This
is not the case for "statement".

Unfortunately, the standard's definition of "expression" is flawed.

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 the token sequence
42
contains no operators or operands, it doesn't strictly satisfy the
definition of "expression", though it's clearly the intent that it is
one, at least if it appears in an expression context.

This was discussed at length in comp.std.c a while ago in the "Is 5 an
expression?" thread. I suggest reviewing that thread before posting
on the subject here; it's very likely that whatever point you want to
make has already been made.

--
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.

[Zax]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Merrill & Michele" <be********@comcast.net> writes:
[...]

Please refrain from using poor English where I have to read it.

[...]

You've become boring. I don't use a killfile, but I will no longer
spend the considerable time and effort necessary to figure out what
you're talking about. If you post something topical and
understandable, I may respond. Otherwise, I give up on you.

Bye.

I disagree. Hello. Zax

[Michael Mair]

Zax wrote:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Merrill & Michele" <be********@comcast.net> writes:
[...]

Please refrain from using poor English where I have to read it.

[...]

You've become boring. I don't use a killfile, but I will no longer
spend the considerable time and effort necessary to figure out what
you're talking about. If you post something topical and
understandable, I may respond. Otherwise, I give up on you.

Bye.

I disagree. Hello. Zax

Hello again MPJ,

and what exactly do you think to gain by this childish game?
Zax meets killfile.

-Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Keith Thompson]

"Zax" <za*****@comcast.net> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Merrill & Michele" <be********@comcast.net> writes:
[...]

> Please refrain from using poor English where I have to read it.

[...]

You've become boring. I don't use a killfile, but I will no longer
spend the considerable time and effort necessary to figure out what
you're talking about. If you post something topical and
understandable, I may respond. Otherwise, I give up on you.

Bye.

I disagree. Hello. Zax

Judging from the article headers, I believe that "Merrill & Michele"
and "Zax" are the same person.

"Merrill & Michele", or whoever you are, you have gone beyond being
boring and become an actively obnoxious troll. Actually, you've been
a troll for a while, but I've tried to give you the benefit of the
doubt. Though I still prefer not to use a killfile, if I reply to
another of your articles it will be either to correct misinformation
for the benefit of others or to warn people about your behavior.

--
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.

[Zax]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Zax" <za*****@comcast.net> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Merrill & Michele" <be********@comcast.net> writes:
[...]
> Please refrain from using poor English where I have to read it.
[...]

You've become boring. I don't use a killfile, but I will no longer
spend the considerable time and effort necessary to figure out what
you're talking about. If you post something topical and
understandable, I may respond. Otherwise, I give up on you.

Bye.

I disagree. Hello. Zax

Judging from the article headers, I believe that "Merrill & Michele"
and "Zax" are the same person.

"Merrill & Michele", or whoever you are, you have gone beyond being
boring and become an actively obnoxious troll. Actually, you've been
a troll for a while, but I've tried to give you the benefit of the
doubt. Though I still prefer not to use a killfile, if I reply to
another of your articles it will be either to correct misinformation
for the benefit of others or to warn people about your behavior.

Statement: K&R2 does not have ; in the index. MPJ

[Zax]

"Michael Mair" <Mi**********@invalid.invalid> wrote in message
news:32*************@individual.net...

Zax wrote:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Merrill & Michele" <be********@comcast.net> writes:
[...]

Please refrain from using poor English where I have to read it.

[...]

You've become boring. I don't use a killfile, but I will no longer
spend the considerable time and effort necessary to figure out what
you're talking about. If you post something topical and
understandable, I may respond. Otherwise, I give up on you.

Bye.

I disagree. Hello. Zax

Hello again MPJ,

and what exactly do you think to gain by this childish game?
Zax meets killfile.

Verloren.

[Lawrence Kirby]

On Mon, 20 Dec 2004 21:32:48 +0000, Keith Thompson wrote:

....

Since the token sequence
42
contains no operators or operands, it doesn't strictly satisfy the
definition of "expression", though it's clearly the intent that it is
one, at least if it appears in an expression context.

This was discussed at length in comp.std.c a while ago in the "Is 5 an
expression?" thread. I suggest reviewing that thread before posting
on the subject here; it's very likely that whatever point you want to
make has already been made.

That may be the point Dik was making, in which case I missed it. My
point, and what I thought Dik was referring to, was different but IMO more
relevant to the discussion about statements and compound statements.

Lawrence

[Mike Wahler]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

Unfortunately, the standard's definition of "expression" is flawed.

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 the token sequence
42
contains no operators or operands,

Why is 42 not an operand?

-Mike

[Keith Thompson]

"Mike Wahler" <mk******@mkwahler.net> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

Unfortunately, the standard's definition of "expression" is flawed.

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 the token sequence
42
contains no operators or operands,

Why is 42 not an operand?

C99 6.4.6p2 (with underscores indicating italics, i.e., definitions):

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.

The "other forms of operator" include things like sizeof that aren't
puctuators. Since 42 is not acted on by an operator, it's not an
operand.

It could be argued that there's an implicit invisible unary operator,
but there's no support for this idea in the standard -- and if there
is such an operator, you could as easily argue that there are an
arbitrary, or even infinite, number of them.

Again, it's clearly intended that 5 is an expression; the problem is
with the wording of the definition, not with our understanding of what
an expression is. The issue is therefore more appropriate for
comp.std.c than for comp.lang.c. I'd redirect followups, but we
already discussed it there some months ago in the "Is 5 an expression?"
thread.

--
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.