printf output

[Keep Asking]

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.

 

[Charlton Wilbur]

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

 

[Nelu]

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?

 

[Richard]

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.

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.

 

[jaysome]

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!

 

[Guest]

There is nothing that it "should be".



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>

 

[Kaz Kylheku]

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.

 

[Keep Asking]

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.

 

[Charlton Wilbur]

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

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

 

[Kaz Kylheku]

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


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.

 

[Keith Thompson]

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

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


Probably exactly as long as that will take anyway.


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.

 

[Charlton Wilbur]

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.

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.

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

 

[Nelu]

Nelu said:


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

Indeed.

 

[jameskuyper]

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

 

[lawrence.jones]

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.

 

[CBFalconer]

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.

 

[Guest]

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

 

[lawrence.jones]

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?

 

[Tim Rentsch]

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

 

[Keith Thompson]

(e-mail address removed) 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