Legal C or bug in gcc

Discussion in 'C Programming' started by Boltar, Feb 27, 2008.

  1. Boltar

    Boltar Guest

    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
     
    Boltar, Feb 27, 2008
    #1
    1. Advertising

  2. In article <>,
    Boltar <> wrote:
    >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.
     
    Kenny McCormack, Feb 27, 2008
    #2
    1. Advertising

  3. Boltar

    Boltar Guest

    On 27 Feb, 09:44, (Kenny McCormack)
    wrote:
    > 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
     
    Boltar, Feb 27, 2008
    #3
  4. Boltar wrote:
    > 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
     
    Joachim Schmitz, Feb 27, 2008
    #4
  5. Boltar <> writes:

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

    --
    Ben.
     
    Ben Bacarisse, Feb 27, 2008
    #5
  6. 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 <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Feb 27, 2008
    #6
  7. Boltar said:

    > On 27 Feb, 09:44, (Kenny McCormack)
    > wrote:
    >> 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.


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

    I have already posted a sensible answer.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Feb 27, 2008
    #7
  8. Boltar

    santosh Guest

    Boltar wrote:

    > 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>
     
    santosh, Feb 27, 2008
    #8
  9. In article <>,
    Boltar <> wrote:
    >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
    --
    :wq
     
    Richard Tobin, Feb 27, 2008
    #9
  10. Richard Heathfield wrote:
    >
    > 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!


    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:>
     
    Kenneth Brody, Feb 27, 2008
    #10
  11. Boltar

    CBFalconer Guest

    Richard Heathfield wrote:
    >

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

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Feb 27, 2008
    #11
  12. Boltar

    Boltar Guest

    On 27 Feb, 09:56, Richard Heathfield <> wrote:
    > 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
     
    Boltar, Feb 27, 2008
    #12
  13. Kenneth Brody <> writes:
    [...]
    > 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 (The_Other_Keith) <>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Feb 27, 2008
    #13
  14. Boltar <> writes:
    > 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.

    --
    Keith Thompson (The_Other_Keith) <>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Feb 27, 2008
    #14
  15. Keith Thompson wrote:
    >
    > Kenneth Brody <> writes:
    > [...]
    > > 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


    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:>
     
    Kenneth Brody, Feb 27, 2008
    #15
  16. Boltar

    MisterE Guest


    > if (1 == 1) a = 1;


    The semicolon brings the if to an end.
     
    MisterE, Feb 28, 2008
    #16
  17. Boltar

    CBFalconer Guest

    MisterE wrote:
    >
    >> if (1 == 1) a = 1;

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

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Feb 28, 2008
    #17
  18. CBFalconer said:

    > MisterE wrote:
    >>
    >>> if (1 == 1) a = 1;

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


    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;
    }

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Feb 28, 2008
    #18
  19. Boltar

    Mark Bluemel Guest

    Richard Heathfield wrote:
    > CBFalconer said:
    >
    >> MisterE wrote:
    >>>> if (1 == 1) a = 1;
    >>> 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'.

    >
    > 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".
     
    Mark Bluemel, Feb 28, 2008
    #19
  20. In article <fq6o0g$it7$>,
    Mark Bluemel <> wrote:
    >Richard Heathfield wrote:
    >> CBFalconer said:
    >>
    >>> MisterE wrote:
    >>>>> if (1 == 1) a = 1;
    >>>> 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'.

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


    Ooooooh. It seems Chuck is not clicking with the Clique anymore.
     
    Kenny McCormack, Feb 28, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    8
    Views:
    442
  2. Kevin P. Fleming

    C99 structure initialization in gcc-2.95.3 vs gcc-3.3.1

    Kevin P. Fleming, Nov 6, 2003, in forum: C Programming
    Replies:
    2
    Views:
    651
    Kevin P. Fleming
    Nov 6, 2003
  3. Replies:
    5
    Views:
    370
    Nathan Addy
    Sep 17, 2005
  4. ashnin

    GCC 3.4.3 and GCC 4.1.2

    ashnin, Jul 7, 2008, in forum: C++
    Replies:
    1
    Views:
    536
    Michael DOUBEZ
    Jul 7, 2008
  5. Jonathan Maasland

    Legal syntax, bug or what?

    Jonathan Maasland, Sep 1, 2006, in forum: Ruby
    Replies:
    1
    Views:
    98
Loading...

Share This Page