Labels

[BartC]

I keep getting a syntax error such as 'label at the end of a compound
statement', when I have code like this:

{
.....
lab:
}

I can fix it by adding a semicolon, as in lab:;

But can I just do that with every label, just have :; after it instead of a
colon? (And what's wrong with having a label just before } anyway? It
doesn't have any trouble figuring out what it means when I put the semicolon
in!)

 

[jian2587]

I keep getting a syntax error such as 'label at the end of a compound

statement', when I have code like this:



{

.....

lab:

}



I can fix it by adding a semicolon, as in lab:;



But can I just do that with every label, just have :; after it instead of a

colon? (And what's wrong with having a label just before } anyway? It

doesn't have any trouble figuring out what it means when I put the semicolon

in!)

afaiu from the C standard, one should think of a label as a property of a statement, i.e. a label can't exist without a statement which to label. I infer this from C 2011 standard 6.8.6.1 subclause 2, which says:
A goto statement causes an unconditional jump to the statement prefixed by the named label in the enclosing function.
See also 6.8.1 subclause 4, which says: Any statement may be preceded by a prefix that declares an identifier as a label name.

 

[James Kuyper]

I keep getting a syntax error such as 'label at the end of a compound
statement', when I have code like this:

{
.....
lab:
}

I can fix it by adding a semicolon, as in lab:;

But can I just do that with every label, just have :; after it instead of a
colon? (And what's wrong with having a label just before } anyway? It
doesn't have any trouble figuring out what it means when I put the semicolon
in!)

A compound statement can contain only declarations and statements. A
labeled statement is a statement, so is allowed. However, the syntax for
a labeled-statement is:

identifier : statement

You've provided the first two parts, but not the last one. Therefore you
have not constructed a labeled statement.

 

[Keith Thompson]

I keep getting a syntax error such as 'label at the end of a compound
statement', when I have code like this:

{
.....
lab:
}

I can fix it by adding a semicolon, as in lab:;

But can I just do that with every label, just have :; after it instead of a
colon? (And what's wrong with having a label just before } anyway? It
doesn't have any trouble figuring out what it means when I put the semicolon
in!)

The syntax for a labeled-statement (which is the only context in which a
label can appear) is (N1570 6.8.1):

labeled-statement:
identifier : statement
case constant-expression : statement
default : statement

In this:

{
lab:
}

there is no statement following the label (a null statement requires a
semicolon).

Yes, you should be able to fix it by adding a semicolon. There might be
some cases where it could break things, depending on where you can put
your labels.

For example, given:

if (cond)
statement1;
else
statement2;

adding "lab:" after "statement1;" would create a syntax error. You can
avoid that by using braces consistently:

if (cond) {
statement1;
}
else {
statement2;
}

Now you can safely add "lab1:" after "statement1;".

 

[glen herrmannsfeldt]

(snip)

The syntax for a labeled-statement (which is the only context in which a
label can appear) is (N1570 6.8.1):

labeled-statement:
identifier : statement
case constant-expression : statement
default : statement
(snip)

Yes, you should be able to fix it by adding a semicolon. There might be
some cases where it could break things, depending on where you can put
your labels.

For example, given:

if (cond)
statement1;
else
statement2;

It also fails it you wanted something like:

if (cond)
lab1: statement1;
else
lab2: statement2;


Personally, I wouldn't do that, and wouldn't recommend others
do it, but as far as I know it is legal, and fails if you put
in the semicolons.

-- glen

 

[Les Cargill]

I keep getting a syntax error such as 'label at the end of a compound
statement', when I have code like this:

{
.....
lab:
}

I can fix it by adding a semicolon, as in lab:;

Yes. You at least need a null statement after the colon.

But can I just do that with every label, just have :; after it instead of a
colon?
Yes.

(And what's wrong with having a label just before } anyway?

Think of the label as an address in code. There must be at least
a "nothing" for it to point to.

It
doesn't have any trouble figuring out what it means when I put the
semicolon in!)

Compilers are like that.

 

[glen herrmannsfeldt]

BartC wrote:
(snip)

Yes. You at least need a null statement after the colon.
(snip)

Think of the label as an address in code. There must be at least
a "nothing" for it to point to.

Seems like it is more that } isn't a statement.

PL/I uses DO; and END; where C uses { and }, which are actual
statements, and I believe can be labeled.

Seems to me that the syntax could have allowed for labels
on } if someone wanted to do it at the time.

-- glen

 

[James Kuyper]

Seems like it is more that } isn't a statement.

PL/I uses DO; and END; where C uses { and }, which are actual
statements, and I believe can be labeled.

Seems to me that the syntax could have allowed for labels
on } if someone wanted to do it at the time.

It certainly would have been possible to do that. However, it would have
saved a grand total of 1 character in an extremely uncommon corner case.

 

[Les Cargill]

Seems like it is more that } isn't a statement.

It isn't; it's a block delimiter.

the null statement in 'C' is

;

all by itself.

PL/I uses DO; and END; where C uses { and }, which are actual
statements, and I believe can be labeled.

Nossir . They're just delimiters for blocks of
code or data.

Doesn't PL/1 require a "WHILE...DO;...END;" or "IF...
DO;...END;" - my PL/M ( which isn't even PL/1 ) is rusty.

Seems to me that the syntax could have allowed for labels
on } if someone wanted to do it at the time.

Perhaps, but the grammar certainly doesn't allow for it.

For that matter, simply textually substituting ";}" for
"}" would have had the same effect - long as it's a code
block. Ah, there's the rub...

char byteses[] = {0,0,0,1,0;};

is Bad 'C' but

if (aBool) { ; }

isn't.

 

[Noob]

I keep getting a syntax error such as 'label at the end of a compound
statement', when I have code like this: [snip]

What you need to do is get a copy of N1570, the final draft
of C11, and read it thoroughly.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

You keep trying to write language tools without having a firm
grasp of your target language!

 

[BartC]

BartC wrote:

You keep trying to write language tools without having a firm
grasp of your target language!

I'd rather see how far I can get without doing so! And one reason for
writing such tools is that, once done, I don't need to know the target
language so well!

Anyway, in the case of labels, I have a source syntax (it's not a language)
where labels are treated as statements, they can only occur within a block
of statements, and might well be the last one in a block.

In C, they will invariably end up somewhere inside {...} braces, as {lab: s;
s;} or {s; s; lab:} or {s; lab: s;} or {lab:}. So if writing labels as lab:;
will shut the compiler up, then that's all I need. (Although it would be a
nice touch to suppress the ; when it's not needed.)

(There might also be targets other than C; I don't want to become an expert
in all of them, and many compiled targets work the same way. Briefly testing
C++, C#, Java and Go, they all have an issue with {... lab:} except Go, but
all are happy to accept {... lab:;}.)

 

[glen herrmannsfeldt]

(snip, I wrote)

Nossir . They're just delimiters for blocks of
code or data.

Doesn't PL/1 require a "WHILE...DO;...END;" or "IF...
DO;...END;" - my PL/M ( which isn't even PL/1 ) is rusty.

In PL/I, DO; is used in a similar way to { in C, to group
statements, especially with IF.

IF I=1 THEN DO;
PUT LIST(I);
END;

DO can also be used for loops, also paired with END.

DO I=1 TO 10;
PUT LIST(I);
END;

DO WHILE(J>10);
PUT LIST(J);
J=J/10;
END;

You can combine iteration and WHILE tests, too.

Perhaps, but the grammar certainly doesn't allow for it.

There was discussion in the past on which C features were
adapted from PL/I, the language of MULTICS, the ancestor
to Unix. The most obvious being comment delimeters.

-- glen

 

[James Kuyper]

I'd rather see how far I can get without doing so!

That approach works slightly better for programming languages than it
does for parachutes, but it doesn't work very well.

In C, they will invariably end up somewhere inside {...} braces, as {lab: s;
s;} or {s; s; lab:} or {s; lab: s;} or {lab:}. So if writing labels as lab:;
will shut the compiler up, then that's all I need. (Although it would be a
nice touch to suppress the ; when it's not needed.)

The only case where a ';' is not needed is when the label is followed by
some other statement instead.

 

[BartC]

That approach works slightly better for programming languages than it
does for parachutes, but it doesn't work very well.

If I was creating a 100% conforming implementation, then yes, I would need
to know the language inside out.

Most people only need to know to a reasonably sized subset to do a huge
amount of useful work.

While those using the language indirectly (like me), might only need to
check out the finer points once (then the automatic tools will take care of
the thousands of instances where they are relevant).

 

[Keith Thompson]

I'd rather see how far I can get without doing so! And one reason for
writing such tools is that, once done, I don't need to know the target
language so well!

You don't need to read N1570 from cover to cover if you don't want
to. But it would have taken you less than a minute to download
it, and just a few minutes to use it to find out the grammar for
a labeled statement.

Your alternative seems to be to ask questions here. I suggest that
that's a poor use of your time (which is your concern) and of ours.
Questions that are likely to be useful to others are great, but I
don't think this particular question about label syntax qualifies.

For similar questions in the future, I may just re-post the URL
for N1570 and suggest you look it up.

[...]

 

[BartC]

"BartC" <[email protected]> writes:

Your alternative seems to be to ask questions here. I suggest that
that's a poor use of your time (which is your concern) and of ours.
Questions that are likely to be useful to others are great, but I
don't think this particular question about label syntax qualifies.

OK, I'm sorry that my throwaway question about label syntax wasn't very
exciting, and that I somehow forced you to read and answer my OP.

 

[James Harris]

....

You don't need to read N1570 from cover to cover if you don't want
to. But it would have taken you less than a minute to download
it, and just a few minutes to use it to find out the grammar for
a labeled statement.

Your alternative seems to be to ask questions here. I suggest that
that's a poor use of your time (which is your concern) and of ours.
Questions that are likely to be useful to others are great, but I
don't think this particular question about label syntax qualifies.

You seem critical of the OP and not just the question. Is that fair? The
answer that folks gave may not have been useful to someone writing C but it
was nonetheless interesting and was informative showing that a label was not
an independent concept as it is in, say, assembly. The OP's question was one
that hadn't been asked here recently, if at all. As such it doesn't seem to
be a bad question for this newsgroup.

The answer also seemed potentially useful for someone else generating C code
from software.

For similar questions in the future, I may just re-post the URL
for N1570 and suggest you look it up.

Not disagreeing with your intention but two potential objections occur to
me. First, N1570 doesn't define all versions of C and the original post, at
least, didn't specify the version being used. And second, if a person
doesn't think a question is appropriate he doesn't have to respond to it. Do
folks here feel an obligation to help rather than just to use this as a
discussion group?

James

 

[Keith Thompson]

OK, I'm sorry that my throwaway question about label syntax wasn't very
exciting, and that I somehow forced you to read and answer my OP.

Part of my point (which I probably didn't express very well) is
that it would be easier *for you* to get a copy of (a draft of)
the standard. You don't have to be an expert on all the arcane
corners of the language, but if you have a question like this I
really think it would be easier and faster *for you* to just look
it up.

The standard is not always crystal clear, and when it isn't if
course you should ask here.

Quoting from upthread:

I'd rather see how far I can get without doing so! And one reason
for writing such tools is that, once done, I don't need to know
the target language so well!

I just don't think that's a good approach. (If it were, you probably
wouldn't have had to ask your question here.)

 

[Keith Thompson]

...


You seem critical of the OP and not just the question. Is that fair?
No.

The
answer that folks gave may not have been useful to someone writing C but it
was nonetheless interesting and was informative showing that a label was not
an independent concept as it is in, say, assembly. The OP's question was one
that hadn't been asked here recently, if at all. As such it doesn't seem to
be a bad question for this newsgroup.

The answer also seemed potentially useful for someone else generating C code
from software.

I agree.

Not disagreeing with your intention but two potential objections occur to
me. First, N1570 doesn't define all versions of C and the original post, at
least, didn't specify the version being used. And second, if a person
doesn't think a question is appropriate he doesn't have to respond to it. Do
folks here feel an obligation to help rather than just to use this as a
discussion group?

I believe I overreacted in my earlier response to BartC.

I still think that downloading a copy of (a draft of) the Standard would
make his questions easier *for him* to answer. Drafts of the 1990,
1999, and 2011 versions of the standard can be found at:

C90: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/
(gzipped PDF, PostScript, and plain text)
C99: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
(includes the standard with all three Technical Corrigenda
merged into it)
C11: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
(last draft, shortly before the official standard)

The 1999 and 2011 drafts have well organized tables of contents, which
(usually) make it easy to find specific information.

BartC: I'm sorry, and I hope this is more helpful.

 

[glen herrmannsfeldt]

I'd rather see how far I can get without doing so! And one reason for
writing such tools is that, once done, I don't need to know the target
language so well!

So you are writing a program that will generate C code?

Anyway, in the case of labels, I have a source syntax (it's not a language)
where labels are treated as statements, they can only occur within a block
of statements, and might well be the last one in a block.

In C, they will invariably end up somewhere inside {...} braces,
as {lab: s; s;} or {s; s; lab:} or {s; lab: s;} or {lab:}.
So if writing labels as lab:; will shut the compiler up, then
that's all I need. (Although it would be a nice touch to
suppress the ; when it's not needed.)

As I wrote, it will also fail if the statement is used where
a single statement is allowed, such as with if(), for(), etc.

if(x==y) lab: printf("hi!");

vs.

if(x==y) lab:; printf("hi!");

It is probably better not to do that at all, and, for machine
generate code, always generate the { and } in those cases.

(There might also be targets other than C; I don't want to
become an expert in all of them, and many compiled
targets work the same way. Briefly testing C++, C#, Java and Go,
they all have an issue with {... lab:} except Go, but all
are happy to accept {... lab:;}.)

Note that Java allows labels on for() and other loops, along
with the label form of continue and break. That won't work if
the label is not on the actual statement.

-- glen