Unexpected answer, compiler bug?

Discussion in 'C Programming' started by Port Pirie, Dec 25, 2007.

  1. Port Pirie

    Port Pirie Guest

    Hi,

    I ran the program below. It should print out 2 but actually it prints
    out 1. What's going on? Should I report a bug against the compiler?

    Thanks.


    void main()
    {
    int a=1;
    a=a++;
    printf("%d", a);
    }
    Port Pirie, Dec 25, 2007
    #1
    1. Advertising

  2. Port Pirie

    santosh Guest

    Port Pirie wrote:

    > Hi,
    >
    > I ran the program below. It should print out 2 but actually it prints
    > out 1. What's going on? Should I report a bug against the compiler?
    >
    > Thanks.
    >
    >
    > void main()
    > {
    > int a=1;
    > a=a++;
    > printf("%d", a);
    > }


    You have invoked undefined behaviour thrice. Firstly void main is not
    the proper prototype. Proper forms are int main(void) or int main(int,
    char**). Secondly you access an object to modify it's value twice
    within a sequence point. Thirdly you are calling a variadic function
    with no prototype in scope.

    Please read the FAQ at the following link:

    <http://www.c-faq.com/>
    <http://www.clc-wiki.net/>
    santosh, Dec 25, 2007
    #2
    1. Advertising

  3. Port Pirie

    Chris Torek Guest

    In article <fkqn1v$cgq$> Port Pirie <> wrote:
    >I ran the program below. It should print out 2 but actually it prints
    >out 1. What's going on? Should I report a bug against the compiler?
    >
    >void main()
    >{
    > int a=1;
    > a=a++;
    > printf("%d", a);
    >}


    You have asked a variant of Frequently Asked Questions 3.1, 3.2, and 3.3.
    See <http://c-faq.com/expr/index.html>. See also questions 11.12a through
    11.15 at <http://c-faq.com/ansi/index.html>.
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
    Chris Torek, Dec 25, 2007
    #3
  4. "santosh" <> schrieb im Newsbeitrag
    news:fkqnl6$pn7$...
    > Port Pirie wrote:
    >
    >> Hi,
    >>
    >> I ran the program below. It should print out 2 but actually it prints
    >> out 1. What's going on? Should I report a bug against the compiler?
    >>
    >> Thanks.
    >>
    >>
    >> void main()
    >> {
    >> int a=1;
    >> a=a++;
    >> printf("%d", a);
    >> }

    >
    > You have invoked undefined behaviour thrice.

    Four times actually

    > Firstly void main is not
    > the proper prototype. Proper forms are int main(void) or int main(int,
    > char**). Secondly you access an object to modify it's value twice
    > within a sequence point. Thirdly you are calling a variadic function
    > with no prototype in scope.

    and fourth you don't end your output with a \n

    bye, Jojo
    Joachim Schmitz, Dec 25, 2007
    #4
  5. Port Pirie

    Guest

    On Dec 25, 12:46 pm, Port Pirie <> wrote:
    > Hi,
    >
    > I ran the program below. It should print out 2 but actually it prints
    > out 1. What's going on? Should I report a bug against the compiler?
    >
    > Thanks.
    >
    > void main()
    > {
    > int a=1;
    > a=a++;
    > printf("%d", a);
    >
    > }


    The key point to your answer is the line:
    a=a++;

    it evaluates a to 1 in right side, assigns 1 to a in left side, then
    increments a used in right side. Use prefix increment instead, like
    this:

    a = ++a;

    Of course, it's advisable you take into account all other advises
    about prototype of main() and enting output with \n. :)
    , Dec 25, 2007
    #5
  6. On Tue, 25 Dec 2007 14:07:58 +0100, Joachim Schmitz wrote:
    > "santosh" <> schrieb im Newsbeitrag
    >> [...]
    >> You have invoked undefined behaviour thrice.

    > Four times actually
    > [...]
    > and fourth you don't end your output with a \n


    Whether that is required is implementation-defined. When it's not
    required, and your program don't provide one, your program is slightly
    less portable, but still has defined behaviour.
    Harald van Dijk, Dec 25, 2007
    #6
  7. On Tue, 25 Dec 2007 05:23:40 -0800, NicoleaSW wrote:
    > The key point to your answer is the line: a=a++;
    >
    > it evaluates a to 1 in right side, assigns 1 to a in left side, then
    > increments a used in right side. Use prefix increment instead, like
    > this:
    >
    > a = ++a;


    This is exactly as broken as the original code. If you want to increment
    a, write a++, or ++a, or a += 1, or a = a + 1, or any other alternative
    that you can think of that updates a _once_. Even if it were valid C,
    there is no point in saying you want to update a, and then store the
    result in a. Updating a already stores the result in a. Trying to store
    it again makes no sense.
    Harald van Dijk, Dec 25, 2007
    #7
  8. Port Pirie wrote:
    > Hi,
    >
    > I ran the program below. It should print out 2 but actually it prints
    > out 1. What's going on? Should I report a bug against the compiler?


    Your code (below) contains at least three errors (four under the old C89
    standard). It cannot reasonably be expected to have any particular
    behavior. However, if you wanted to guess what the behavior might be of
    this incredibly error-laden code, consider this code block:

    {
    int a = 1;
    int c;
    c = a++; /* a++ has the value 1, that value is assigned to c */
    }

    Does that give you a hint?
    If you do not understand why a++ has the value 1, open any elementary C
    text and read the very first page in which the post-increment operator
    ++ is introduced.

    > void main()
    > {
    > int a=1;
    > a=a++;
    > printf("%d", a);
    > }
    Martin Ambuhl, Dec 25, 2007
    #8
  9. wrote:

    > The key point to your answer is the line:
    > a=a++;
    >
    > it evaluates a to 1 in right side, assigns 1 to a in left side, then
    > increments a used in right side.


    You might think so, but you would be horribly wrong.
    This line has completely undefinied behavior.

    > Use prefix increment instead, like
    > this:
    >
    > a = ++a;


    You might think so, but you would be horribly wrong.
    This line has completely undefinied behavior.

    > Of course, it's advisable you take into account all other advises
    > about prototype of main() and enting output with \n. :)


    Of course, it's advisable for you to learn about sequence points before
    posting "advice".
    Martin Ambuhl, Dec 25, 2007
    #9
  10. Port Pirie

    Chris Dollin Guest

    wrote:

    > On Dec 25, 12:46 pm, Port Pirie <> wrote:
    >> Hi,
    >>
    >> I ran the program below. It should print out 2 but actually it prints
    >> out 1. What's going on? Should I report a bug against the compiler?
    >>
    >> Thanks.
    >>
    >> void main()
    >> {
    >> int a=1;
    >> a=a++;
    >> printf("%d", a);
    >>
    >> }

    >
    > The key point to your answer is the line:
    > a=a++;
    >
    > it evaluates a to 1 in right side, assigns 1 to a in left side, then
    > increments a used in right side.


    Wherever you learned that from, reconsider its educational value;
    it's wrong. It's a /permitted/ implementation, but only because
    the expression `a = a++` has /no/ defined behaviour -- anything
    and everything is permitted.

    There are specific words in the Standard that, amongst other things,
    make undefined the effects of writing to the same location multiple
    times without an intervening "sequence point". Don't Do That.

    --
    Oh Noes! I Has Meltdownz! Hedgehog
    "Life is full of mysteries. Consider this one of them." Sinclair, /Babylon 5/
    Chris Dollin, Dec 25, 2007
    #10
  11. santosh wrote:
    > Port Pirie wrote:
    >
    >> Hi,
    >>
    >> I ran the program below. It should print out 2 but actually it prints
    >> out 1. What's going on? Should I report a bug against the compiler?
    >>
    >> Thanks.
    >>
    >>
    >> void main()
    >> {
    >> int a=1;
    >> a=a++;
    >> printf("%d", a);
    >> }

    >
    > You have invoked undefined behaviour thrice. Firstly void main is not
    > the proper prototype. Proper forms are int main(void) or int main(int,
    > char**). Secondly you access an object to modify it's value twice
    > within a sequence point. Thirdly you are calling a variadic function
    > with no prototype in scope.
    >
    > Please read the FAQ at the following link:
    >
    > <http://www.c-faq.com/>
    > <http://www.clc-wiki.net/>
    >


    Why don't you answer his question? If his complier isn't issuing warnings about
    these things he may indeed need to report a bug, just not the one he thinks.
    Golden California Girls, Dec 25, 2007
    #11
  12. Port Pirie

    Mike Wahler Guest

    "Golden California Girls" <> wrote in message
    news:...
    > santosh wrote:
    >> Port Pirie wrote:
    >>
    >>> Hi,
    >>>
    >>> I ran the program below. It should print out 2 but actually it prints
    >>> out 1. What's going on? Should I report a bug against the compiler?
    >>>
    >>> Thanks.
    >>>
    >>>
    >>> void main()
    >>> {
    >>> int a=1;
    >>> a=a++;
    >>> printf("%d", a);
    >>> }

    >>
    >> You have invoked undefined behaviour thrice. Firstly void main is not
    >> the proper prototype. Proper forms are int main(void) or int main(int,
    >> char**). Secondly you access an object to modify it's value twice
    >> within a sequence point. Thirdly you are calling a variadic function
    >> with no prototype in scope.
    >>
    >> Please read the FAQ at the following link:
    >>
    >> <http://www.c-faq.com/>
    >> <http://www.clc-wiki.net/>
    >>

    >
    > Why don't you answer his question?


    The first question ("What's going on?") was answered: The
    behavior is undefined, thus *anything* is possible, including the
    reported result.

    > If his complier isn't issuing warnings about
    > these things he may indeed need to report a bug, just not the one he
    > thinks.


    And above the second question ("Should I report a bug against the
    compiler?")
    was also answered.

    AFAIK, there's nothing in his code for which the
    standard requires a diagnostic. Warnings might
    be nice, but that's simply a quality-of-implementation
    issue, not a 'bug'.

    -Mike
    Mike Wahler, Dec 25, 2007
    #12
  13. Mike Wahler wrote:
    > "Golden California Girls" <> wrote in message
    > news:...
    >> Why don't you answer his question?

    >
    > The first question ("What's going on?") was answered: The
    > behavior is undefined, thus *anything* is possible, including the
    > reported result.
    >
    >> If his complier isn't issuing warnings about
    >> these things he may indeed need to report a bug, just not the one he
    >> thinks.

    >
    > And above the second question ("Should I report a bug against the
    > compiler?")
    > was also answered.
    >
    > AFAIK, there's nothing in his code for which the
    > standard requires a diagnostic. Warnings might
    > be nice, but that's simply a quality-of-implementation
    > issue, not a 'bug'.
    >


    So the standard doesn't require some message or action when you depart from it.
    Interesting. I'd say not a good standard, in fact not a standard at all. Why
    even have it?
    Golden California Girls, Dec 26, 2007
    #13
  14. Port Pirie

    santosh Guest

    Golden California Girls wrote:

    > Mike Wahler wrote:
    >> "Golden California Girls" <> wrote in message
    >> news:...
    >>> Why don't you answer his question?

    >>
    >> The first question ("What's going on?") was answered: The
    >> behavior is undefined, thus *anything* is possible, including the
    >> reported result.
    >>
    >>> If his complier isn't issuing warnings about
    >>> these things he may indeed need to report a bug, just not the one he
    >>> thinks.

    >>
    >> And above the second question ("Should I report a bug against the
    >> compiler?")
    >> was also answered.
    >>
    >> AFAIK, there's nothing in his code for which the
    >> standard requires a diagnostic. Warnings might
    >> be nice, but that's simply a quality-of-implementation
    >> issue, not a 'bug'.
    >>

    >
    > So the standard doesn't require some message or action when you depart
    > from it. Interesting. I'd say not a good standard, in fact not a
    > standard at all. Why even have it?


    Syntax errors and constraint violations must produce a diagnostic but
    other issues can be left undiagnosed by an implementation. It must also
    document it's behaviour for all issues the Standard tags
    as "implementation defined". It need not document undefined behaviour.
    santosh, Dec 26, 2007
    #14
  15. On Tue, 25 Dec 2007 16:05:56 -0800, Golden California Girls wrote:
    > So the standard doesn't require some message or action when you depart
    > from it.
    > Interesting. I'd say not a good standard, in fact not a standard at
    > all. Why
    > even have it?


    The standard requires messages for the types of departures that can be
    realistically diagnosed in the general case at compile time. If it
    mandated anything beyond that, I doubt the standard would be more useful
    than now; we would merely have more implementations that don't conform to
    it.
    Harald van Dijk, Dec 26, 2007
    #15
  16. santosh wrote:
    > Golden California Girls wrote:
    >
    >> Mike Wahler wrote:
    >>> "Golden California Girls" <> wrote in message
    >>> news:...
    >>>> Why don't you answer his question?
    >>> The first question ("What's going on?") was answered: The
    >>> behavior is undefined, thus *anything* is possible, including the
    >>> reported result.
    >>>
    >>>> If his complier isn't issuing warnings about
    >>>> these things he may indeed need to report a bug, just not the one he
    >>>> thinks.
    >>> And above the second question ("Should I report a bug against the
    >>> compiler?")
    >>> was also answered.
    >>>
    >>> AFAIK, there's nothing in his code for which the
    >>> standard requires a diagnostic. Warnings might
    >>> be nice, but that's simply a quality-of-implementation
    >>> issue, not a 'bug'.
    >>>

    >> So the standard doesn't require some message or action when you depart
    >> from it. Interesting. I'd say not a good standard, in fact not a
    >> standard at all. Why even have it?

    >
    > Syntax errors and constraint violations must produce a diagnostic but
    > other issues can be left undiagnosed by an implementation. It must also
    > document it's behaviour for all issues the Standard tags
    > as "implementation defined". It need not document undefined behaviour.
    >


    I'm assuming the "It" you mention in your second sentence should read "The
    implementation".

    Your third sentence the "It" could stand for either "The standard" or "The
    implementation".

    In any case I'm not talking about some hypothetical implementation, I'm talking
    about the standard itself.

    My point is that the standard should not allow undefined behavior. It should
    either tag it implementation defined so it gets documented or tag it as a syntax
    or constraint violation.

    Leaving things undefined is like how houses used to be wired in the USA. There
    was a plug and you knew there was a neutral pin and a hot pin but had no clue
    which pin had which, because the standard left it undefinable. People died
    because of that. [1]

    Perhaps the standard had better start with big bold face caps "This standard
    leaves things undefined and therefore must not be used in any case where harm
    (economic or physical) might come to anyone such as any real world application."



    [1] It is Christmas time so a perfect example. Strings of lights used to have
    fuses on each lead. Why? Because the person making the string of lights didn't
    know which lead was hot. He had to hope the short tripped both fuses so the
    string went cold. Fuses however don't all open at the same point. Sometimes
    the one in the line that was cold opened first and the string was left hot. Now
    there is a big safety issue on a fake metal Christmas tree or a real one that
    tipped over and spilled water all over the floor. Today however because the
    designer knows which lead is hot there is only one fuse and it is in the hot
    lead. It opens and the string is safe. Standards should not leave things
    undefined!
    Golden California Girls, Dec 26, 2007
    #16
  17. Port Pirie

    Chris Torek Guest

    In article <>,
    Golden California Girls <> wrote:
    >My point is that the standard should not allow undefined behavior. ...


    In general, the more you pin things down, the slower they will have to
    go. As we see over and over again in computing, it is more important to
    get the wrong answer as fast as possible. :)

    Seriously, there *are* languages that have no undefined behavior, and
    languages that are much better specified than C (Ada, for instance, falls
    into the latter category). If that is what you want, you should consider
    these languages. There is a price to pay for this, though.

    As for defining all behavior precisely, consider the following function:

    void f(int *p, int *q) {
    *p = (*q)++;
    }

    The semantics of this function, as defined by the C standard, say that
    *p will be set to whatever *q used to have, and *q will be incremented,
    so that:

    int a, b = 42;
    ...
    f(&a, &b);

    leaves a set to 42, and b set to 43.

    But what happens if we do:

    f(&b, &b);

    ? The "C answer" is: "the effect is undefined". This makes it
    easy for a compiler to generate code for f() that runs as fast as
    possible, even if that means that this has some strange effect on
    b() in a call like the last one.

    Now, you might argue that the compiler should be able to detect
    that p and q both point to b, so that the call to f() should draw
    a diagnostic. In some languages, it is possible to specify this
    -- but C is not one of those languages. In C, f() can be compiled
    separately from the call to f(), and by the time you go to join
    the two together (the "link phase"), the information needed is
    allowed to have been, and usually has been, discarded.

    Alternatively, you might argue that the compiler should be required
    to generate code for f() that does something "well defined" even if
    p and q both point to b. Some languages take such an approach --
    but C is not one of those languages either; C allows compilers to
    generate the fastest possible code, as long as it gets the right
    answer whenever p and q point to different variables.

    The original C standardization effort, which by most accounts was
    wildly successful, attempted -- for the most part at least -- to
    standardize existing practice, without inventing new features like
    detecting invalid calls to f(). The C89 standard was rapidly
    adopted quite widely. The later standardization effort, resulting
    in C99, was clearly less successful: and it took the approach of
    improving the language in various ways, inventing new features to
    make programming easier and/or safer, instead of sticking with
    existing practice.

    I leave it to the reader to draw conclusions. (Well, one of mine --
    not 100% serious, admittedly -- is at the top of this article. :) )
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
    Chris Torek, Dec 26, 2007
    #17
  18. On Tue, 25 Dec 2007 16:05:56 -0800, Golden California Girls wrote:

    > So the standard doesn't require some message or action when you depart
    > from it.


    Not correct.
    Many classes of error e.g. syntax errors and constraint violations,
    require a diagnostic.
    Others are left to the implementation to decide how to handle because the
    result is implementation dependent. For example some implementations
    support a startup function signature void main(), so forcing an
    implementation to error this would be wrong.
    Mark McIntyre, Dec 26, 2007
    #18
  19. Mark McIntyre said:

    > On Tue, 25 Dec 2007 16:05:56 -0800, Golden California Girls wrote:
    >
    >> So the standard doesn't require some message or action when you depart
    >> from it.

    >
    > Not correct.
    > Many classes of error e.g. syntax errors and constraint violations,
    > require a diagnostic.


    In fact, those are two of only three classes of error for which the
    Standard requires a diagnostic message during translation. The third is
    deliberately programmer-induced: #error.

    --
    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, Dec 26, 2007
    #19
  20. On Tue, 25 Dec 2007 20:01:42 -0800, Golden California Girls wrote:

    >
    > My point is that the standard should not allow undefined behavior.


    That's a foolish point. If it did not allow some behaviour to be
    undefined, then it would have to document all behaviour on all platforms
    now and as-yet uninvented. Thats obviously impossible. Furthermore it
    would proscribe implementations from providing extensions since if
    everything is defined, nothing can be added.

    > Perhaps the standard had better start with big bold face caps "This
    > standard leaves things undefined and therefore must not be used in any
    > case where harm (economic or physical) might come to anyone such as any
    > real world application."


    Perhaps it could start with "this standard expects its readers to have
    common sense, if you're too stoopid to wire up a 3-pin plug, then stop
    now".

    > [1] It is Christmas time so a perfect example. Strings of lights used
    > to have fuses on each lead. Why?


    Because if the cable broke half way along, both halves would be carrying
    current and you could get fried off each half.

    >Because the person making the string
    > of lights didn't know which lead was hot.


    Euh? Do you guys use DC in the states? If not, it doesn't matter which is
    live, they're both carrying 240/110 V. Follow 'em back to the pole where
    the phases split out....
    Mark McIntyre, Dec 26, 2007
    #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. FrigginMook
    Replies:
    3
    Views:
    585
    Mohamad Elarabi [MCPD]
    Dec 29, 2007
  2. Replies:
    5
    Views:
    289
  3. Unknownmat
    Replies:
    9
    Views:
    506
    James Kanze
    Jul 15, 2008
  4. benny
    Replies:
    2
    Views:
    89
    benny
    Jan 17, 2005
  5. Daniel Harple

    [BUG] Unexpected syntax error

    Daniel Harple, Feb 20, 2006, in forum: Ruby
    Replies:
    3
    Views:
    129
    Yukihiro Matsumoto
    Feb 20, 2006
Loading...

Share This Page