sequence points and printf()

A

arnuld

OBJECTIVE: To know why its UB


#include <stdio.h>

int main(void)
{
char c='8';
int d=8;
printf("%d %d %d\n",d, d+=c>='0'&& c<='9', c++);

return 0;
}
================ OUTPUT ===================
[arnuld@dune C]$ gcc -ansi -pedantic -Wall -Wextra test.c
test.c: In function ‘main’:
test.c:7: warning: operation on ‘d’ may be undefined
test.c:7: warning: operation on ‘c’ may be undefined
[arnuld@dune C]$ ./a.out
9 9 56
[arnuld@dune C]$


gcc says its UB. The way I understand it is:

(1) d is incremented in 2nd argument without defining any sequence
points, hence you can not guarantee what printf() will print as value of
d.

(2) same for c, as its being incremented without defining any sequence
point.

But as per C-FAQs here: http://c-faq.com/expr/seqpoints.html

comma operator defined a sequence point and I see comma is present
between printf() arguments but I am not sure if this "comma" is called as
"comma operator" ?
 
A

Alan Curry

printf("%d %d %d\n",d, d+=c>='0'&& c<='9', c++); [...]

comma operator defined a sequence point and I see comma is present
between printf() arguments but I am not sure if this "comma" is called as
"comma operator" ?

You hit on the problem right there. The function-argument-separating comma is
not an operator.
 
B

BartC

printf("%d %d %d\n",d, d+=c>='0'&& c<='9', c++);
gcc says its UB. The way I understand it is:
comma operator defined a sequence point and I see comma is present
between printf() arguments but I am not sure if this "comma" is called as
"comma operator" ?

The problem here is that the order the printf arguments are evaluated, is
not specified. The statement will give different results depending on
whether they're evaluated left-to-right or right-to-left (or starting in the
middle).

Saying it's 'UB' is a bit of an overreaction though, as the worst that can
happen *ought* to be that wrong results are printed, and that d ends up
being 1 more or less than you might expect.
 
W

Willem

arnuld wrote:
) OBJECTIVE: To know why its UB
....
) printf("%d %d %d\n",d, d+=c>='0'&& c<='9', c++);
....
) comma operator defined a sequence point and I see comma is present
) between printf() arguments but I am not sure if this "comma" is called as
) "comma operator" ?

This "comma" is definitely not called as "comma operator".

HTH, HAND.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
 
K

Keith Thompson

Martin Ambuhl said:
Commas between arguments are punctuation and not comma operators.

Right.

A terminology quibble: comma *operators* are also punctuation.
 
L

lawrence.jones

BartC said:
The problem here is that the order the printf arguments are evaluated, is
not specified. The statement will give different results depending on

Not just that, but there are no sequence points between the argument
evaluations. Both c and d are modified as well as being accessed
outside the modification expression, which makes the behavior completely
undefined.
 
K

Keith Thompson

BartC said:
The problem here is that the order the printf arguments are evaluated, is
not specified. The statement will give different results depending on
whether they're evaluated left-to-right or right-to-left (or starting in the
middle).

Saying it's 'UB' is a bit of an overreaction though, as the worst that can
happen *ought* to be that wrong results are printed, and that d ends up
being 1 more or less than you might expect.

No, the behavior is undefined.

C99 6.5p2:

Between the previous and next sequence point an object shall
have its stored value modified at most once by the evaluation
of an expression. Furthermore, the prior value shall be read
only to determine the value to be stored.

The above printf call doesn't violate the first sentence, but it
does violate the second. There is no sequence point between reading
d and modifying d *and* the value read is not used to compute the
value to be stored.

Something like

x = x + 1;

reads and writes x with no intervening sequence points, but its
behavior is well defined because the value that's read is used to
compute the value to be stored. Because of this, the read *must*
occur before the write, so no conflict can occur. (C201X expresses
this more clearly; it says that the read is "sequenced before"
the write, rather than leaving it implicit.)

In the printf call, the read and write of d are unsequenced
(can occur in either order), and the standard says this produces
undefined behavior.
 
P

Phil Carmody

BartC said:
The problem here is that the order the printf arguments are evaluated,
is not specified. The statement will give different results depending
on whether they're evaluated left-to-right or right-to-left (or
starting in the middle).

Saying it's 'UB' is a bit of an overreaction though, as the worst that
can happen *ought* to be that wrong results are printed, and that d
ends up being 1 more or less than you might expect.

This is a dangerous and sloppy way of thinking.

Arnuld is trying to learn C, we should be helping him to avoid
sloppy ways of thinking.

Anyway, I'd not say it's an over-reaction. An overreaction would be
someone going to their manager and saying something like "X is not
competent in the field for which he was hired. That's the second one
from the same consultancy in 6 months, can you tell resourcing there's
a problem?". Not that that's ever happened, nor did the one from 6
months earlier magically re-appear in a different team a year later.

Phil
 
S

Seebs

comma operator defined a sequence point and I see comma is present
between printf() arguments but I am not sure if this "comma" is called as
"comma operator" ?

It's not. The commas separating function call arguments are not
comma operators.

-s
 
S

Seebs

Saying it's 'UB' is a bit of an overreaction though, as the worst that can
happen *ought* to be that wrong results are printed, and that d ends up
being 1 more or less than you might expect.

Nope. It's undefined behavior, full stop.

And yes, I have seen REALLY crazy results from stuff like this. I once
saw someone do something roughly to the effect of:

i = ++i % 4;

and get results which followed no particular pattern I could understand,
but they got larger and larger -- say, well over 1000.

No idea why. Changed the code, problem went away, not worth trying to figure
it out.

-s
 
A

August Karlstrom

On 2011-12-01 07:06, arnuld wrote:
[...]
But as per C-FAQs here: http://c-faq.com/expr/seqpoints.html

comma operator defined a sequence point and I see comma is present
between printf() arguments but I am not sure if this "comma" is called as
"comma operator" ?

Just want to add that unless you are into code maintenance I see no
point in bothering with sequence points.

August
 
K

Keith Thompson

August Karlstrom said:
On 2011-12-01 07:06, arnuld wrote:
[...]
But as per C-FAQs here: http://c-faq.com/expr/seqpoints.html

comma operator defined a sequence point and I see comma is present
between printf() arguments but I am not sure if this "comma" is called as
"comma operator" ?

Just want to add that unless you are into code maintenance I see no
point in bothering with sequence points.

How does one not bother with sequence points?
 
K

Kaz Kylheku

On 2011-12-01 07:06, arnuld wrote:
[...]
But as per C-FAQs here: http://c-faq.com/expr/seqpoints.html

comma operator defined a sequence point and I see comma is present
between printf() arguments but I am not sure if this "comma" is called as
"comma operator" ?

Just want to add that unless you are into code maintenance I see no
point in bothering with sequence points.

Phew! I always just write new code myself and let others debug/maintain it, so
I'm safe from sequence points, I guess.

:)
 
J

James Kuyper

On 2011-12-01 07:06, arnuld wrote:
[...]
But as per C-FAQs here: http://c-faq.com/expr/seqpoints.html

comma operator defined a sequence point and I see comma is present
between printf() arguments but I am not sure if this "comma" is called as
"comma operator" ?

Just want to add that unless you are into code maintenance I see no
point in bothering with sequence points.

I'm curious - if you don't bother with sequence points, how do you write
C? Any C program has a minimum of at least one sequence point.

Or are you saying you see no point in bothering to understand sequence
points? In that case, how do you avoid writing code that has undefined
behavior by reason of not bothering with sequence points?

I suppose a sufficient broad definition of "code maintenance" might turn
that into a reasonable assertion - but it would have to be broad enough
to include all writing of C code with desire to have create a program
that functions correctly.
 
E

Eric Sosman

Not just that, but there are no sequence points between the argument
evaluations. Both c and d are modified as well as being accessed
outside the modification expression, which makes the behavior completely
undefined.

As opposed to partially undefined?

;-)
 
K

Kaz Kylheku

On 2011-12-01 07:06, arnuld wrote:
[...]
But as per C-FAQs here: http://c-faq.com/expr/seqpoints.html

comma operator defined a sequence point and I see comma is present
between printf() arguments but I am not sure if this "comma" is called as
"comma operator" ?

Just want to add that unless you are into code maintenance I see no
point in bothering with sequence points.

I'm curious - if you don't bother with sequence points, how do you write
C? Any C program has a minimum of at least one sequence point.

Or are you saying you see no point in bothering to understand sequence
points? In that case, how do you avoid writing code that has undefined
behavior by reason of not bothering with sequence points?

You can avoid knowledge of sequence points by memorizing some simplified
coding rules instead: in any full expression (such as an expression
statement, initializer, or the controlling expression of a loop, etc) never
modify the same object twice, and never make an ambiguous-looking access to an
object that is being modified (any access to an object being modified
has to be one of the operands of the expressions which compute the new value
being stored).
 
A

August Karlstrom

You can avoid knowledge of sequence points by memorizing some simplified
coding rules instead: in any full expression (such as an expression
statement, initializer, or the controlling expression of a loop, etc) never
modify the same object twice, and never make an ambiguous-looking access to an
object that is being modified (any access to an object being modified
has to be one of the operands of the expressions which compute the new value
being stored).

Yes, that is what I meant.

August
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top