Implementation-defined behaviour

I

Ioannis Vranos

AFAIK the following is implementation-defined behaviour, am I right?:


#include <stdio.h>


int main(void)
{
int n= 0;

printf("%d\n", n++);


return 0;
}
 
S

santosh

Ioannis said:
AFAIK the following is implementation-defined behaviour, am I right?:

#include <stdio.h>

int main(void)
{
int n= 0;
printf("%d\n", n++);
return 0;
}

I don't think so.
 
E

Eric Sosman

Ioannis said:
AFAIK the following is implementation-defined behaviour, am I right?:


#include <stdio.h>


int main(void)
{
int n= 0;

printf("%d\n", n++);


return 0;
}

Only by quibbles: the form of "successful termination"
returned to the host environment is implementation-defined,
the actual new-line representation written to stdout in
response to the '\n' is implementation-defined, and things
of that sort.

What aspect do you believe is not Standard-defined?
 
I

Ioannis Vranos

santosh said:
I don't think so.

There are similar examples at 2.12 of K&R2.


Two quotes from there:

"printf("%d %d\n", ++n, power(2, n)); /* WRONG */"


"One unhappy situation is typified by the statement

a= i++;"
 
I

Ioannis Vranos

Eric said:
Only by quibbles: the form of "successful termination"
returned to the host environment is implementation-defined,
the actual new-line representation written to stdout in
response to the '\n' is implementation-defined, and things
of that sort.

What aspect do you believe is not Standard-defined?


I am talking about the implementation-defined behaviour of the printf()
call described at 2.12 of K&R2.
 
S

santosh

Ioannis said:
santosh said:
I don't think so.

There are similar examples at 2.12 of K&R2.


Two quotes from there:

"printf("%d %d\n", ++n, power(2, n)); /* WRONG */"


"One unhappy situation is typified by the statement

a= i++;"


Well these examples are different from what you have shown above. The
first example above invokes unspecified behaviour while the second one
invokes undefined behaviour. The example in your first post does
neither as far as I can see.
 
I

Ian Collins

Ioannis said:
I am talking about the implementation-defined behaviour of the printf()
call described at 2.12 of K&R2.
There's nothing wrong with your example, the one you cite is completely
different. If you had tried to use n again in the printf, you would hit UB.
 
I

Ioannis Vranos

Ian said:
There's nothing wrong with your example, the one you cite is completely
different. If you had tried to use n again in the printf, you would hit UB.


So, printf("%d "%d\n", x++, x++); invokes implementation-defined
behaviour, while printf("%d\n", x++); doesn't invoke
implementation-defined behaviour?
 
D

Dann Corbit

Ioannis Vranos said:
AFAIK the following is implementation-defined behaviour, am I right?:


#include <stdio.h>


int main(void)
{
int n= 0;

printf("%d\n", n++);


return 0;
}

C:\tmp>lin foo.c

C:\tmp>"C:\Lint\Lint-nt" +v -i"C:\Lint" std.lnt -os(_LINT.TMP) foo.c
PC-lint for C/C++ (NT) Vers. 8.00u, Copyright Gimpel Software 1985-2006

--- Module: foo.c (C)

C:\tmp>type _LINT.TMP | more

--- Module: foo.c (C)
_
printf("%d %d\n", n++, n);
foo.c(8) : Warning 564: variable 'n' depends on order of evaluation

---
output placed in _LINT.TMP

C:\tmp>splint foo.c
Splint 3.1.1 --- 12 Mar 2007

foo.c: (in function main)
foo.c(8,24): Argument 2 modifies n, used by argument 3 (order of evaluation
of
actual parameters is undefined): printf("%d %d\n", n++, n)
Code has unspecified behavior. Order of evaluation of function parameters
or
subexpressions is not defined, so if a value is used and modified in
different places not separated by a sequence point constraining evaluation
order, then the result of the expression is unspecified. (Use -evalorder
to
inhibit warning)

Finished checking --- 1 code warning

C:\tmp>type foo.c
#include <stdio.h>
int main(void)
{
int n = 0;
/* Not a problem, function call is a sequence point: */
printf("%d\n", n++);
/* Problem here, order unspecified */
printf("%d %d\n", n++, n);
return 0;
}
 
D

Dann Corbit

Ioannis Vranos said:
So, printf("%d %d\n", x++, x++); invokes implementation-defined
so does:
printf("%d %d\n", x++, x);
behaviour, while printf("%d\n", x++); doesn't invoke
implementation-defined behaviour?

This one does not.
 
A

Andrey Tarasevich

Ioannis said:
So, printf("%d "%d\n", x++, x++); invokes implementation-defined
behaviour, while printf("%d\n", x++); doesn't invoke
implementation-defined behaviour?

'printf("%d "%d\n", x++, x++)' invokes _undefined_ behavior. 'printf("%d
"%d\n", x++, x)' also invokes _undefined_ behavior.

'printf("%d\n", x++)' does not invoke undefined behavior.

"Implementation-defined behavior" is not immediately relevant to the
nature of your question.
 
B

Barry Schwarz

So, printf("%d "%d\n", x++, x++); invokes implementation-defined

This invokes undefined behavior. The commas separating function
arguments are not sequence points. You are modifying x twice without
an intervening sequence point.
behaviour, while printf("%d\n", x++); doesn't invoke
implementation-defined behaviour?


Remove del for email
 
B

Barry Schwarz

C:\tmp>lin foo.c

C:\tmp>"C:\Lint\Lint-nt" +v -i"C:\Lint" std.lnt -os(_LINT.TMP) foo.c
PC-lint for C/C++ (NT) Vers. 8.00u, Copyright Gimpel Software 1985-2006

--- Module: foo.c (C)

C:\tmp>type _LINT.TMP | more

--- Module: foo.c (C)
_
printf("%d %d\n", n++, n);
foo.c(8) : Warning 564: variable 'n' depends on order of evaluation

The correct diagnostic would state: without an intervening sequence
point, n is modified and also evaluated for a purpose other than
determining the modified value. This invokes undefined behavior.
---
output placed in _LINT.TMP

C:\tmp>splint foo.c
Splint 3.1.1 --- 12 Mar 2007

foo.c: (in function main)
foo.c(8,24): Argument 2 modifies n, used by argument 3 (order of evaluation
of
actual parameters is undefined): printf("%d %d\n", n++, n)
Code has unspecified behavior. Order of evaluation of function parameters
or
subexpressions is not defined, so if a value is used and modified in
different places not separated by a sequence point constraining evaluation
order, then the result of the expression is unspecified. (Use -evalorder
to
inhibit warning)

Finished checking --- 1 code warning

C:\tmp>type foo.c
#include <stdio.h>
int main(void)
{
int n = 0;
/* Not a problem, function call is a sequence point: */
printf("%d\n", n++);
/* Problem here, order unspecified */
printf("%d %d\n", n++, n);
return 0;
}


Remove del for email
 
D

Dann Corbit

Barry Schwarz said:
The correct diagnostic would state: without an intervening sequence
point, n is modified and also evaluated for a purpose other than
determining the modified value. This invokes undefined behavior.

The examination of n in the last parameter of printf() is to determine its
value.
I am not sure that your interpretation is certain. Are you sure of it?
 
R

Richard Heathfield

Dann Corbit said:
The examination of n in the last parameter of printf() is to determine
its value.

More to the point, it is /not/ to determine the /modified/ value.
I am not sure that your interpretation is certain. Are you sure of it?

If he isn't, he should be.
 
D

Dann Corbit

Richard Heathfield said:
Dann Corbit said:


More to the point, it is /not/ to determine the /modified/ value.

How about:
printf("%d %d\n", ++n, n);

In this case one could possibly argue that the intent is to determine the
modified value.
If he isn't, he should be.

While I agree it is an awful construct, I think that 'purpose' renders the
statement a bit ambiguous, because it implies intent.
 
R

Richard Heathfield

Dann Corbit said:

How about:
printf("%d %d\n", ++n, n);

In this case one could possibly argue that the intent is to determine the
modified value.

The intent might be. Nevertheless, the *purpose* is not (because the order
of evaluation of function arguments is unspecified).
While I agree it is an awful construct, I think that 'purpose' renders
the statement a bit ambiguous, because it implies intent.

I don't think so, actually. Intent implies the possibility of mistaken
execution of that intent, which would in turn require the implementation
to read minds! No: *irrespective* of the intent, the *purpose* cannot be
to determine the modified value, in either the "%d %d\n", ++n, n or the
"%d %d\n", n, ++n case, because in neither case is the evaluation order
specified.
 
D

Dann Corbit

Richard Heathfield said:
Dann Corbit said:



The intent might be. Nevertheless, the *purpose* is not (because the order
of evaluation of function arguments is unspecified).


I don't think so, actually. Intent implies the possibility of mistaken
execution of that intent, which would in turn require the implementation
to read minds! No: *irrespective* of the intent, the *purpose* cannot be
to determine the modified value, in either the "%d %d\n", ++n, n or the
"%d %d\n", n, ++n case, because in neither case is the evaluation order
specified.

I'm convinced.
 
P

Philip Potter

Ioannis said:
So, printf("%d "%d\n", x++, x++); invokes implementation-defined
behaviour, while printf("%d\n", x++); doesn't invoke
implementation-defined behaviour?
Aside from the fact that this won't compile (you have one too many "
characters), this is almost exactly the same question as FAQ 3.2. The
problem is not the individual 'x++' expressions, but the way they
interact with each other.

Philip
 
I

Ioannis Vranos

Andrey said:
'printf("%d "%d\n", x++, x++)' invokes _undefined_ behavior. 'printf("%d
"%d\n", x++, x)' also invokes _undefined_ behavior.

'printf("%d\n", x++)' does not invoke undefined behavior.

"Implementation-defined behavior" is not immediately relevant to the
nature of your question.


K&R2 mentions the following:

"printf("%d %d\n", ++n, power(2,n)); /* WRONG */

can produce different results with different compilers, depending on
whether n is incremented before power is called".


That's why I call it implementation-defined behaviour.
 

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,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top