undefined behavior?

[Loic Domaigne]

Hello everybody,

Let's assume that I have the following prototype:
void myf(int x, ...) ;

The function myf() is then called as follows:

int i=0;
f(a[i++],a[i++]); // a is an array

This sounds to me like an undefined behavior, am I right?

Thanks in advance,
Loic.
--

 

[mail2sandeepnl]

Hello everybody,

Let's assume that I have the following prototype:
void myf(int x, ...) ;

The function myf() is then called as follows:

int i=0;
f(a[i++],a[i++]); // a is an array

This sounds to me like an undefined behavior, am I right?

Thanks in advance,
Loic.
--

yes , order of evaluation in function parameters is compiler dependent

 

[Richard Bos]

Let's assume that I have the following prototype:
void myf(int x, ...) ;

The function myf() is then called as follows:

int i=0;
f(a[i++],a[i++]); // a is an array

This sounds to me like an undefined behavior, am I right?

yes , order of evaluation in function parameters is compiler dependent

It's worse than that. It's not just implementation-defined behaviour,
it's full-blown _un_-defined behaviour. If it only depended on the order
of evaluation, you'd have two possible outcomes: one way 'round, or the
other way 'round. But it's undefined, so anything may happen, from what
the naive programmer believes "should" happen to a complete crash, and
worse.
The prototype of the function doesn't matter here, BTW. You modify the
value of i twice between sequence points. _That_ causes UB, no matter
what else.

Richard

 

[Joachim Schmitz]

Let's assume that I have the following prototype:
void myf(int x, ...) ;

The function myf() is then called as follows:

int i=0;
f(a[i++],a[i++]); // a is an array

This sounds to me like an undefined behavior, am I right?

yes , order of evaluation in function parameters is compiler dependent

It's worse than that. It's not just implementation-defined behaviour,
it's full-blown _un_-defined behaviour. If it only depended on the order
of evaluation, you'd have two possible outcomes: one way 'round, or the
other way 'round. But it's undefined, so anything may happen, from what
the naive programmer believes "should" happen to a complete crash, and
worse.
The prototype of the function doesn't matter here, BTW. You modify the
value of i twice between sequence points. _That_ causes UB, no matter
what else.

the comma doesn't act as a sequence point here inside an argument list, like
is otherwise would?

Bye, Jojo

 

[Richard Bos]

Let's assume that I have the following prototype:
void myf(int x, ...) ;

The function myf() is then called as follows:

int i=0;
f(a[i++],a[i++]); // a is an array

This sounds to me like an undefined behavior, am I right?

yes , order of evaluation in function parameters is compiler dependent

It's worse than that. It's not just implementation-defined behaviour,
it's full-blown _un_-defined behaviour. If it only depended on the order
of evaluation, you'd have two possible outcomes: one way 'round, or the
other way 'round. But it's undefined, so anything may happen, from what
the naive programmer believes "should" happen to a complete crash, and
worse.
The prototype of the function doesn't matter here, BTW. You modify the
value of i twice between sequence points. _That_ causes UB, no matter
what else.

the comma doesn't act as a sequence point here inside an argument list, like
is otherwise would?

The comma only introduces a sequence point when it's the comma
_operator_. These are separators, a different part of the grammar
entirely. So are the commas in, for example, this declaration:

int i,j, *ip, ia[14];

Richard

 

[santosh]

Let's assume that I have the following prototype:
void myf(int x, ...) ;

The function myf() is then called as follows:

int i=0;
f(a[i++],a[i++]); // a is an array

This sounds to me like an undefined behavior, am I right?

yes , order of evaluation in function parameters is compiler
dependent

It's worse than that. It's not just implementation-defined behaviour,
it's full-blown _un_-defined behaviour. If it only depended on the
order of evaluation, you'd have two possible outcomes: one way
'round, or the other way 'round. But it's undefined, so anything may
happen, from what the naive programmer believes "should" happen to a
complete crash, and worse.
The prototype of the function doesn't matter here, BTW. You modify
the value of i twice between sequence points. _That_ causes UB, no
matter what else.

the comma doesn't act as a sequence point here inside an argument
list, like is otherwise would?

No.

 

[Loic Domaigne]

Hello everybody,

Let's assume that I have the following prototype:
void myf(int x, ...) ;

The function myf() is then called as follows:

int i=0;
f(a[i++],a[i++]); // a is an array

This sounds to me like an undefined behavior, am I right?

Thanks in advance,
Loic.
--

Thanks everybody for your answers.

Cheers,
Loic.

 

[David Thompson]

f(a[i++],a[i++]); // a is an array

the comma doesn't act as a sequence point here inside an argument list, like
is otherwise would?

The comma only introduces a sequence point when it's the comma
_operator_. These are separators, a different part of the grammar
entirely. So are the commas in, for example, this declaration:

int i,j, *ip, ia[14];

(Both) true as stated. However, a 'toplevel' comma in a declaration
coincides with either the end of a full-declarator (as here) or of an
initializer, and either of those IS a sequence point.

- formerly david.thompson1 || achar(64) || worldnet.att.net