printf output

Discussion in 'C Programming' started by Keep Asking, Feb 17, 2009.

  1. Keep Asking

    Keep Asking Guest

    What is output of following printf should be?

    i=0;
    printf("i=%d i++=%d i++=%d", i, i++, i++)?

    I was surprised when I was the print out.
     
    Keep Asking, Feb 17, 2009
    #1
    1. Advertising

  2. >>>>> "KA" == Keep Asking <> writes:

    KA> What is output of following printf should be?
    KA> i=0; printf("i=%d i++=%d i++=%d", i, i++, i++)?

    It *should* cause a baseball bat to come out of the back of the monitor
    and whack the programmer who wrote it about the head and shoulders until
    enlightenment is attained.

    See the FAQ at http://c-faq.com/, questions 3.1, 3.2, and 3.3

    Charlton


    --
    Charlton Wilbur
     
    Charlton Wilbur, Feb 17, 2009
    #2
    1. Advertising

  3. Keep Asking

    Nelu Guest

    On 2009-02-17, Keep Asking <> wrote:
    > What is output of following printf should be?
    >
    > i=0;
    > printf("i=%d i++=%d i++=%d", i, i++, i++)?


    Undefined behavior as i is modified multiple times between sequence points.
    The C standard doesn't specify a well defined behavior for this.

    You can't have any expectations.

    > I was surprised when I was the print out.


    What print out did you expect?


    --
    Ioan - Ciprian Tandau
    tandau _at_ freeshell _dot_ org
     
    Nelu, Feb 17, 2009
    #3
  4. Keep Asking

    Richard Guest

    Jack Klein <> writes:

    > On Mon, 16 Feb 2009 19:32:37 -0800 (PST), Keep Asking
    > <> wrote in comp.lang.c:
    >
    >> What is output of following printf should be?

    >
    > There is nothing that it "should be".


    But it would not be a leap of faith for a programmer to think that, like
    AND statements, that the components are evaluated left to right.

    >
    >> i=0;
    >> printf("i=%d i++=%d i++=%d", i, i++, i++)?
    >>
    >> I was surprised when I was the print out.

    >
    > You have no business being surprised, because you had no right to
    > expect anything. You have broken the rules and generated undefined
    > behavior.


    Are all bugs or silly mistakes dealt with so harshly in Jack town? And
    the perpetrators slapped, gestapo style, while being reminded of their
    "rights"?

    Possibly you should reconsider your position as a guide if you are so
    rude in reply to such simple questions?

    Flexibility, patience and consideration for others thought processes are
    often the sign of a good teacher. Unless it's Bill who is a troll.
     
    Richard, Feb 17, 2009
    #4
  5. Keep Asking

    jaysome Guest

    On Mon, 16 Feb 2009 19:32:37 -0800 (PST), Keep Asking
    <> wrote:

    >What is output of following printf should be?
    >
    >i=0;
    >printf("i=%d i++=%d i++=%d", i, i++, i++)?
    >
    >I was surprised when I was the print out.


    I get the following output, which is acceptable as far as the C
    Standard is concerned:

    #define PI 3.1415926535897931
    Press any key to continue

    Coincidentally, I get the same output from this Standard C program
    that runs on my hosted environment:

    #include <math.h>
    #include <stdio.h>
    int main(void)
    {
    printf("#define PI %.16f\n", acos(-1.0));
    return 0;
    }

    Enjoy!
    --
    jay
     
    jaysome, Feb 17, 2009
    #5
  6. Keep Asking

    Guest

    On 17 Feb, 03:50, Jack Klein <> wrote:
    > On Mon, 16 Feb 2009 19:32:37 -0800 (PST), Keep Asking
    > <> wrote in comp.lang.c:
    >
    > > What is output of following printf  should be?

    >
    > There is nothing that it "should be".
    >
    > > i=0;
    > > printf("i=%d i++=%d i++=%d", i, i++, i++)?

    >
    > > I was surprised when I was the print out.

    >
    > You have no business being surprised, because you had no right to
    > expect anything.  You have broken the rules and generated undefined
    > behavior.


    I actually wrote code like that once, and I was surprised.
    My DNA didn't come with the C Standard embedded in it.

    <snip>
     
    , Feb 17, 2009
    #6
  7. Keep Asking

    Kaz Kylheku Guest

    On 2009-02-17, Charlton Wilbur <> wrote:
    >>>>>> "KA" == Keep Asking <> writes:

    >
    > KA> What is output of following printf should be?
    > KA> i=0; printf("i=%d i++=%d i++=%d", i, i++, i++)?
    >
    > It *should* cause a baseball bat to come out of the back of the monitor
    > and whack the programmer who wrote it about the head and shoulders until
    > enlightenment is attained.


    This whacking should be first applied to the designers of the language and
    those who maintain the status quo. Then, if there is energy left, to the
    programmer.
     
    Kaz Kylheku, Feb 17, 2009
    #7
  8. Keep Asking

    Keep Asking Guest

    On Feb 16, 9:32 pm, Keep Asking <> wrote:
    > What is output of following printf should be?
    >
    > i=0;
    > printf("i=%d i++=%d i++=%d", i, i++, i++)?
    >
    > I was surprised when I was the print out.


    The C-FAQ answered my question.

    The comma operator does guarantee left-to-right evaluation, but the
    commas separating the arguments in a function call are not comma
    operators. The order of evaluation of the arguments to a function call
    is unspecified.
     
    Keep Asking, Feb 17, 2009
    #8
  9. >>>>> "KK" == Kaz Kylheku <> writes:

    KK> On 2009-02-17, Charlton Wilbur <> wrote:

    >>>>>>> "KA" == Keep Asking <> writes:


    KA> What is output of following printf should be? i=0; printf("i=%d
    KA> i++=%d i++=%d", i, i++, i++)?

    >> It *should* cause a baseball bat to come out of the back of the
    >> monitor and whack the programmer who wrote it about the head and
    >> shoulders until enlightenment is attained.


    KK> This whacking should be first applied to the designers of the
    KK> language and those who maintain the status quo. Then, if there
    KK> is energy left, to the programmer.

    Suppose that C1x were to completely eliminate all instances of undefined
    behavior, so that the language were completely deterministic. How long
    do you think it would take before we saw a strictly conforming C1x
    compiler?

    For extra credit, mention as many strictly conforming C99 compilers as
    you can for supporting evidence.

    (Hint: the designers of the language do not need to be whacked about the
    head and shoulders with a baseball bat, because they are banging their
    heads on brick walls.)

    Charlton


    --
    Charlton Wilbur
     
    Charlton Wilbur, Feb 17, 2009
    #9
  10. Keep Asking

    Kaz Kylheku Guest

    On 2009-02-17, Charlton Wilbur <> wrote:
    >>>>>> "KK" == Kaz Kylheku <> writes:

    >
    > KK> On 2009-02-17, Charlton Wilbur <> wrote:
    >
    > >>>>>>> "KA" == Keep Asking <> writes:

    >
    > KA> What is output of following printf should be? i=0; printf("i=%d
    > KA> i++=%d i++=%d", i, i++, i++)?
    >
    > >> It *should* cause a baseball bat to come out of the back of the
    > >> monitor and whack the programmer who wrote it about the head and
    > >> shoulders until enlightenment is attained.

    >
    > KK> This whacking should be first applied to the designers of the
    > KK> language and those who maintain the status quo. Then, if there
    > KK> is energy left, to the programmer.
    >
    > Suppose that C1x were to completely eliminate all instances of undefined
    > behavior, so that the language were completely deterministic.


    http://en.wikipedia.org/wiki/False_dilemma

    ``Either we eliminate all undefined behavior, or it's not worth it.''

    > How long
    > do you think it would take before we saw a strictly conforming C1x
    > compiler?


    Probably exactly as long as that will take anyway.

    > For extra credit, mention as many strictly conforming C99 compilers as
    > you can for supporting evidence.


    If we were to take C90, and change it only by restricting order of
    evaluation, we would see conformance in no time.
     
    Kaz Kylheku, Feb 17, 2009
    #10
  11. Kaz Kylheku <> writes:
    > On 2009-02-17, Charlton Wilbur <> wrote:

    [...]
    >> Suppose that C1x were to completely eliminate all instances of undefined
    >> behavior, so that the language were completely deterministic.

    >
    > http://en.wikipedia.org/wiki/False_dilemma
    >
    > ``Either we eliminate all undefined behavior, or it's not worth it.''
    >
    >> How long
    >> do you think it would take before we saw a strictly conforming C1x
    >> compiler?

    >
    > Probably exactly as long as that will take anyway.
    >
    >> For extra credit, mention as many strictly conforming C99 compilers as
    >> you can for supporting evidence.

    >
    > If we were to take C90, and change it only by restricting order of
    > evaluation, we would see conformance in no time.


    I'm skeptical. I suspect that a lot of compilers lose information
    about evaluation order fairly early. Retaining that information and
    forcing a specified order might take a substantial amount of work.

    This isn't necessarily a strong argument against the idea; I just
    think it might take considerable work to implement it.

    Most user-written code, on the other hand, would be unaffected.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Feb 17, 2009
    #11
  12. >>>>> "KK" == Kaz Kylheku <> writes:

    >> Suppose that C1x were to completely eliminate all instances of
    >> undefined behavior, so that the language were completely
    >> deterministic.


    KK> http://en.wikipedia.org/wiki/False_dilemma

    KK> ``Either we eliminate all undefined behavior, or it's not worth
    KK> it.''

    Okay. Suppose it eliminated only the undefined behavior that results
    from modifying the same variable multiple times between sequence points.

    Does that change your answer? It doesn't change mine.

    >> How long do you think it would take before we saw a strictly
    >> conforming C1x compiler?


    KK> Probably exactly as long as that will take anyway.

    Indeed. In other words, the designers of the language are relatively
    powerless compared to the implementors of the language, and each
    individual implementation is free to define any behavior that the
    standard leaves undefined.

    >> For extra credit, mention as many strictly conforming C99
    >> compilers as you can for supporting evidence.


    KK> If we were to take C90, and change it only by restricting order
    KK> of evaluation, we would see conformance in no time.

    And if it started to rain gold $20 pieces, in no time I would be rich.

    Charlton



    --
    Charlton Wilbur
     
    Charlton Wilbur, Feb 17, 2009
    #12
  13. Keep Asking

    Nelu Guest

    On 2009-02-17, Richard Heathfield <> wrote:
    > Nelu said:
    >
    >> On 2009-02-17, Keep Asking <> wrote:
    >>> What is output of following printf should be?

    <snip>
    >> You can't have any expectations.

    >
    > Yes, he can. Clearly, he does. Or did.


    Indeed.


    --
    Ioan - Ciprian Tandau
    tandau _at_ freeshell _dot_ org
     
    Nelu, Feb 17, 2009
    #13
  14. Keep Asking

    jameskuyper Guest

    Charlton Wilbur wrote:
    > >>>>> "KK" == Kaz Kylheku <> writes:

    >
    > >> Suppose that C1x were to completely eliminate all instances of
    > >> undefined behavior, so that the language were completely
    > >> deterministic.

    ....
    > >> How long do you think it would take before we saw a strictly
    > >> conforming C1x compiler?

    >
    > KK> Probably exactly as long as that will take anyway.
    >
    > Indeed. In other words, the designers of the language are relatively
    > powerless compared to the implementors of the language, and each
    > individual implementation is free to define any behavior that the
    > standard leaves undefined.


    While that is true, the proposed change was to remove undefined
    behavior, rendering that point pretty much irrelevant.

    We can safely predict that adoption of C1x will be very slow,
    regardless of its contents, using a much stronger and more relevant
    principle: each implementation is free to decide which standard to
    conform to, if any. Removing all undefined behavior would simply make
    the process even slower, especially on those platforms where the
    defined behavior is inconvenient, inefficient, or just plain outright
    impossible to implement (which will certainly be the case for many
    platforms, no matter which choice is made as to what the defined
    behavior should be).
     
    jameskuyper, Feb 17, 2009
    #14
  15. Keep Asking

    Guest

    Keep Asking <> wrote:
    > On Feb 16, 9:32 pm, Keep Asking <> wrote:
    > > What is output of following printf should be?
    > >
    > > i=0;
    > > printf("i=%d i++=%d i++=%d", i, i++, i++)?
    > >
    > > I was surprised when I was the print out.

    >
    > The C-FAQ answered my question.
    >
    > The comma operator does guarantee left-to-right evaluation, but the
    > commas separating the arguments in a function call are not comma
    > operators. The order of evaluation of the arguments to a function call
    > is unspecified.


    That's true, but note that you're also modifying the value of i multiple
    times without any intervening sequence point and also reading the value
    in an unrelated expression, either of which is sufficient to make the
    behavior completely undefined, so *any* result (or no result, for that
    matter) is possible. And almost any combination of zeros, ones, and/or
    twos is actually plausible on real implementations.
    --
    Larry Jones

    I'm so disappointed. -- Calvin
     
    , Feb 17, 2009
    #15
  16. Keep Asking

    CBFalconer Guest

    Keep Asking wrote:
    > Keep Asking <> wrote:
    >
    >> What is output of following printf should be?
    >>
    >> i=0;
    >> printf("i=%d i++=%d i++=%d", i, i++, i++)?
    >>
    >> I was surprised when I was the print out.

    >
    > The C-FAQ answered my question.
    >
    > The comma operator does guarantee left-to-right evaluation, but
    > the commas separating the arguments in a function call are not
    > comma operators. The order of evaluation of the arguments to a
    > function call is unspecified.


    This is the sort of misunderstanding that is common because of C's
    reuse of symbols in context sensitive manners. If a comma was
    always a comma operator, a '*' was always a multiplication, etc. we
    would have far fewer newbie errors. Of course then C would have
    had to use more reserved words, and entering code would have
    required more key presses. Horrors.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.
     
    CBFalconer, Feb 18, 2009
    #16
  17. Keep Asking

    Guest

    On 17 Feb, 19:50, Charlton Wilbur <> wrote:
    > >>>>> "KK" == Kaz Kylheku <> writes:

    >
    >     >> Suppose that C1x were to completely eliminate all instances of
    >     >> undefined behavior, so that the language were completely
    >     >> deterministic.
    >
    >     KK>http://en.wikipedia.org/wiki/False_dilemma
    >
    >     KK> ``Either we eliminate all undefined behavior, or it's not worth
    >     KK> it.''
    >
    > Okay.  Suppose it eliminated only the undefined behavior that results
    > from modifying the same variable multiple times between sequence points.


    what about aliasing?

    > Does that change your answer?  It doesn't change mine.
    >
    >     >> How long do you think it would take before we saw a strictly
    >     >> conforming C1x compiler?
    >
    >     KK> Probably exactly as long as that will take anyway.
    >
    > Indeed.  In other words, the designers of the language are relatively
    > powerless compared to the implementors of the language, and each
    > individual implementation is free to define any behavior that the
    > standard leaves undefined.  
    >
    >     >> For extra credit, mention as many strictly conforming C99
    >     >> compilers as you can for supporting evidence.
    >
    >     KK> If we were to take C90, and change it only by restricting order
    >     KK> of evaluation, we would see conformance in no time.
    >
    > And if it started to rain gold $20 pieces, in no time I would be rich.
     
    , Feb 18, 2009
    #17
  18. Keep Asking

    Guest

    Han from China <> wrote:
    >
    > Certainly having a few extra keywords would be a lot better than
    > overloading keywords like 'static'.


    One of the key issues for C1X is what new meaning can we come up with
    for static? :)
    --
    Larry Jones

    I think if Santa is going to judge my behavior over the last year,
    I ought to be entitled to legal representation. -- Calvin
     
    , Feb 19, 2009
    #18
  19. Keep Asking

    Tim Rentsch Guest

    writes:

    > Han from China <> wrote:
    > >
    > > Certainly having a few extra keywords would be a lot better than
    > > overloading keywords like 'static'.

    >
    > One of the key issues for C1X is what new meaning can we come up with
    > for static? :)
    > --
    > Larry Jones


    Oh, easy one:

    int *static p; // p may point only to objects with static
    // or automatic storage duration [1], not to
    // objects with allocated storage duration

    Of course, we would then also need:

    int *!static q; // q may point only to objects with allocated
    // storage duration

    The benefits to making it easier to know which pointers to
    free should be obvious.


    [1] Of course not just static storage duration, that would
    be too consistent; the other possibilities would be,

    int *static !auto x; // for static-only
    int *auto y; // for auto only
    int * !auto z; // for static or allocated
    int * auto !static v; // for automatic or allocated
    int * !static !auto w; // pointer may only be NULL
     
    Tim Rentsch, Feb 20, 2009
    #19
  20. Tim Rentsch <> writes:
    > writes:

    [...]
    >> One of the key issues for C1X is what new meaning can we come up with
    >> for static? :)

    >
    > Oh, easy one:
    >
    > int *static p; // p may point only to objects with static
    > // or automatic storage duration [1], not to
    > // objects with allocated storage duration
    >
    > Of course, we would then also need:
    >
    > int *!static q; // q may point only to objects with allocated
    > // storage duration
    >
    > The benefits to making it easier to know which pointers to
    > free should be obvious.
    >
    >
    > [1] Of course not just static storage duration, that would
    > be too consistent; the other possibilities would be,
    >
    > int *static !auto x; // for static-only
    > int *auto y; // for auto only
    > int * !auto z; // for static or allocated
    > int * auto !static v; // for automatic or allocated
    > int * !static !auto w; // pointer may only be NULL


    Ah, but you really want to be able to specify any of static, auto, or
    allocated storage duration. This gives us the opportunity to combine
    yet another re-use of "static" with a new keyword:

    int *static x; // static only
    int *auto y; // auto only
    int *_Allocated z; // allocated only

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Feb 20, 2009
    #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. Johan Lindh

    expected printf() output

    Johan Lindh, Jan 30, 2004, in forum: C Programming
    Replies:
    8
    Views:
    370
    Peter Nilsson
    Jan 31, 2004
  2. ben
    Replies:
    4
    Views:
    656
    Martin Ambuhl
    Jun 26, 2004
  3. whatluo

    (void) printf vs printf

    whatluo, May 26, 2005, in forum: C Programming
    Replies:
    29
    Views:
    1,323
  4. azza

    printf affects following printf/s

    azza, Oct 17, 2010, in forum: C Programming
    Replies:
    0
    Views:
    454
  5. guru
    Replies:
    8
    Views:
    301
Loading...

Share This Page