Legal C or bug in gcc

[Boltar]

By accident I came across a bug like this in some Linux code I'd
written today. All that had happened is I forgot the "else" yet the
code still compiled and ran. A simplified example is below.

#include <stdio.h>

main()
{
int a;
if (1 == 1) a = 1;
{
a = 2;
}
printf("a = %d\n",a);
}

When run it will print "a = 2". Should it compile at all or is GCCs
parser broken?

B2003

 

[Kenny McCormack]

By accident I came across a bug like this in some Linux code I'd
written today. All that had happened is I forgot the "else" yet the
code still compiled and ran. A simplified example is below.

#include <stdio.h>

main()
{
int a;
if (1 == 1) a = 1;
{
a = 2;
}
printf("a = %d\n",a);
}

When run it will print "a = 2". Should it compile at all or is GCCs
parser broken?

B2003

Time for me to re-post my "I wrote this hello, world program and it
compiled and ran just fine; why?" post.

 

[Boltar]

Time for me to re-post my "I wrote this hello, world program and it
compiled and ran just fine; why?" post.

I should've known better than to expect a sensible answer from this
group.

Anyway , I just realised its treating the bracketed part as a seperate
block so you can save anymore sarcastic responses.

B2003

 

[Joachim Schmitz]

By accident I came across a bug like this in some Linux code I'd
written today. All that had happened is I forgot the "else" yet the
code still compiled and ran. A simplified example is below.

#include <stdio.h>

main()
{
int a;
if (1 == 1) a = 1;

here you assign 1 to a, always, as 1 always equals 1

{
a = 2;

here you assign 2 to a, always

}
printf("a = %d\n",a);
}

When run it will print "a = 2". Should it compile at all or is GCCs
parser broken?

Why do you think it is broken or should print something else?

Bye, Jojo

 

[Ben Bacarisse]

By accident I came across a bug like this in some Linux code I'd
written today. All that had happened is I forgot the "else" yet the
code still compiled and ran. A simplified example is below.

#include <stdio.h>

main()
{
int a;
if (1 == 1) a = 1;
{
a = 2;
}
printf("a = %d\n",a);
}

When run it will print "a = 2". Should it compile at all or is GCCs
parser broken?

It is entirely legal. A compound statement (braces containing other
statements) is just another valid option where a statement is
required.

 

[Richard Heathfield]

Boltar said:

By accident I came across a bug like this in some Linux code I'd
written today. All that had happened is I forgot the "else" yet the
code still compiled and ran. A simplified example is below.

#include <stdio.h>

main()
{
int a;
if (1 == 1) a = 1;
{
a = 2;
}
printf("a = %d\n",a);
}

When run it will print "a = 2". Should it compile at all or is GCCs
parser broken?

It's legal.

{
a = 2;
}

is a compound statement. You can have these pretty much anywhere you can
have an ordinary statement. If you like, you can do this:

#include <stdio.h>
int main(void)
{
{ printf("Hello, world!\n"); }
{ puts("How are you today?"); }
{ puts("Earthquake in UK - film at 11"); }
{ return 0; }
}

Although the above is a pastiche, this facility is nevertheless useful and
powerful, but does have the unfortunate consequence you have noted -
forgetting an "else" doesn't necessarily give you the syntax error you'd
have hoped for!

 

[Richard Heathfield]

Boltar said:

I should've known better than to expect a sensible answer from this
group.

Mr McCormack is a troll. You get them in any group.

I have already posted a sensible answer.

 

[santosh]

By accident I came across a bug like this in some Linux code I'd
written today. All that had happened is I forgot the "else" yet the
code still compiled and ran. A simplified example is below.

#include <stdio.h>

main()
{
int a;
if (1 == 1) a = 1;
{
a = 2;
}
printf("a = %d\n",a);
}

When run it will print "a = 2". Should it compile at all or is GCCs
parser broken?

No this is legal C. A opening { starts a compound statement or block,
closed by the next }. It's sometimes useful for data confinement.

<OT>
There *is* a related GCC extension which allows a compound statement
enclosed in parenthesis as an expression, but this is not an
illustration of one. This is pure Standard C.
</OT>

 

[Richard Tobin]

By accident I came across a bug like this in some Linux code I'd

main()
{
int a;
if (1 == 1) a = 1;
{
a = 2;
}
printf("a = %d\n",a);
}

Perhaps you should run it through an indenting tool for enlightenment:

main()
{
int a;

if (1 == 1)
a = 1;

{
a = 2;
}

printf("a = %d\n",a);
}

-- Richard

 

[Kenneth Brody]

Boltar said:


It's legal.

{
a = 2;
}

is a compound statement. You can have these pretty much anywhere you can
have an ordinary statement. If you like, you can do this:

#include <stdio.h>
int main(void)
{
{ printf("Hello, world!\n"); }
{ puts("How are you today?"); }
{ puts("Earthquake in UK - film at 11"); }
{ return 0; }
}

Although the above is a pastiche, this facility is nevertheless useful and
powerful, but does have the unfortunate consequence you have noted -
forgetting an "else" doesn't necessarily give you the syntax error you'd
have hoped for!

In case the OP (or anyone else) is wondering where this would be
useful, consider:

#if ENABLE_SOME_FEATURE
if ( new_feature_is_enabled() )
{
do_it_the_new_way();
do_another_thing_the_new_way();
}
else
#endif
{
do_it_the_old_way();
do_the_other_thing_the_old_way();
}

Compare this "clean" version to how you would have to write it if
compound statements weren't legal on their own.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[CBFalconer]

.... snip ...

Although the above is a pastiche, this facility is nevertheless
useful and powerful, but does have the unfortunate consequence
you have noted - forgetting an "else" doesn't necessarily give
you the syntax error you'd have hoped for!

Which is where the Pascal syntax of never preceding an else with a
semi is useful.

 

[Boltar]

I have already posted a sensible answer.

Yes , thanks for that. I realised what it was happening with the code
about 10 seconds after I posted. That'll teach me to post when I'm
half asleep instead of attempting to think.

B2003

 

[Keith Thompson]

In case the OP (or anyone else) is wondering where this would be
useful, consider:

#if ENABLE_SOME_FEATURE
if ( new_feature_is_enabled() )
{
do_it_the_new_way();
do_another_thing_the_new_way();
}
else
#endif
{
do_it_the_old_way();
do_the_other_thing_the_old_way();
}

Compare this "clean" version to how you would have to write it if
compound statements weren't legal on their own.

It's not *that* bad:

#if ENABLE_SOME_FEATURE
if ( new_feature_is_enabled() )
{
do_it_the_new_way();
do_another_thing_the_new_way();
}
else
{
#endif
do_it_the_old_way();
do_the_other_thing_the_old_way();
#if ENABLE_SOME_FEATURE
}
#endif

It also has the advantage that if you delete all the
#if ENABLE_SOME_FEATURE
...
#endif
sections, the remaining code still looks ok (apart from the
indentation).

 

[Keith Thompson]

By accident I came across a bug like this in some Linux code I'd
written today. All that had happened is I forgot the "else" yet the
code still compiled and ran. A simplified example is below.

#include <stdio.h>

main()
{
int a;
if (1 == 1) a = 1;
{
a = 2;
}
printf("a = %d\n",a);
}

When run it will print "a = 2". Should it compile at all or is GCCs
parser broken?

Your question has already been answered to death (and BTW "Kenny
McCormack" is at least annoying to us as he is to you), but let me
offer a suggestion that can avoid such problems.

Whenever I write an if, while, for, or do-while statement, I always
use blocks for the controlled statements. For example:

if (1 == 1) {
a = 1;
}
else {
a = 2;
}

It's a habit I picked up from Perl, which requires it, but I find that
it's useful in C as well.

Strictly speaking you'll still have the same problem if you drop the
"else", but with a more uniform layout I think you're less liketly to
do so. This style also avoids problems like:

if (condition)
statement;
another_statement_added_later;

Of course, plenty of smart people don't like this style.

 

[Kenneth Brody]

It's not *that* bad:

#if ENABLE_SOME_FEATURE
if ( new_feature_is_enabled() )
{
do_it_the_new_way();
do_another_thing_the_new_way();
}
else
{
#endif
do_it_the_old_way();
do_the_other_thing_the_old_way();
#if ENABLE_SOME_FEATURE
}
#endif

I've seen code like that, and it looks "ugly" to me. Plus, I think
mine is earier to maintain. Consider what happens with you start to
#define ENABLE_ANOTHER_FEATURE and ENABLE_YET_ANOTHER_FEATURE, and
start having multiple if/elseif's along the way.

It also has the advantage that if you delete all the
#if ENABLE_SOME_FEATURE
...
#endif
sections, the remaining code still looks ok (apart from the
indentation).

Then what about debugging code, with local variables?

#if DO_MY_LOGGING
{
int i;
for ( i=0 ; i < LengthOfSomething ; i++ )
{
DoMyLogging(something);
}
}
#endif

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[MisterE]

if (1 == 1) a = 1;

The semicolon brings the if to an end.

 

[CBFalconer]

The semicolon brings the if to an end.

In Pascal. Not in C. In C the definitive thing is the presence of
a following 'else'.

 

[Richard Heathfield]

CBFalconer said:

In Pascal. Not in C. In C the definitive thing is the presence of
a following 'else'.

If that is true, the following code will compile, and will *not* print
"Hmmm". Otherwise, the compilation will fail.

#include <stdio.h>

int main(void)
{
int a = 0;
if(1 == 1)
a = 1;
printf("Hmmm\n");
else
NULL;
return 0;
}

 

[Mark Bluemel]

CBFalconer said:


If that is true,

It's presumably true for the version of C that Chuck imagines...

I _think_ his intentions are reasonably sound, but his bombastic
attitude combined with his being simply wrong far too often means
that I've "tuned him out".

 

[Kenny McCormack]

It's presumably true for the version of C that Chuck imagines...

I _think_ his intentions are reasonably sound, but his bombastic
attitude combined with his being simply wrong far too often means
that I've "tuned him out".

Ooooooh. It seems Chuck is not clicking with the Clique anymore.