Undefined, but common, expressions

[Dave]

Please consider the following:

st = sf[i++]

I seem to recall that there is a potential problem with an expression such
as this. If I recall properly, this actually exhibits undefined behavior,
though most compilers will probably do what was intended.

I remember one layman's explanation was that we don't know for sure that
sf[i++] won't be evaluated first, to we can't be sure that i will be
incremented at the proper time. However, as I recall, the real problem was
a little deeper than this.

Could somebody please explain?

Thanks!

 

[Mike Wahler]

Please consider the following:

st = sf[i++]

I seem to recall that there is a potential problem with an expression such
as this. If I recall properly, this actually exhibits undefined behavior,
though most compilers will probably do what was intended.

I remember one layman's explanation was that we don't know for sure that
sf[i++] won't be evaluated first, to we can't be sure that i will be
incremented at the proper time. However, as I recall, the real problem was
a little deeper than this.

Could somebody please explain?

Look up 'sequence points'.

If you want the above to increment 'i' after the assignment,
simply code it that way:

st = sf;
i++;

IMO too many C programmers (for whatever reason) try to write
these 'concise', 'clever' statements, and all too often they
introduce bugs which would have never happened had they wrote
the code more clearly.


-Mike

 

[Gianni Mariani]

Please consider the following:

st = sf[i++]

I seem to recall that there is a potential problem with an expression such
as this. If I recall properly, this actually exhibits undefined behavior,
though most compilers will probably do what was intended.

I remember one layman's explanation was that we don't know for sure that
sf[i++] won't be evaluated first, to we can't be sure that i will be
incremented at the proper time. However, as I recall, the real problem was
a little deeper than this.

That's it. The code above is undefined. Look up "sequence points".
You can be guarenteed that the side effects (++, --, etc) are "done" by
the time execution reaches the sequence point. I don't recall the
formal definition of "sequence point" but it's the point between when
one expression is done and the new unrelated expression is started

 

[Ron Natalie]

Please consider the following:

st = sf[i++]

I seem to recall that there is a potential problem with an expression such
as this. If I recall properly, this actually exhibits undefined behavior,
though most compilers will probably do what was intended.

It's undefined behavior and most compilers won't do what was intended
as it's not even clear what the intent was. When is the side effect (the ++) of
supposed to be applied? Before the assignment, afterwards?

 

[jeffc]

It's undefined behavior and most compilers won't do what was intended
as it's not even clear what the intent was. When is the side effect (the ++) of
supposed to be applied? Before the assignment, afterwards?

I don't see why this is different from, say, operator precedence. You have
the same questions. Why not just define ++ to do one or the other?

 

[Artie Gold]

It's undefined behavior and most compilers won't do what was intended
as it's not even clear what the intent was. When is the side effect

(the ++) of

supposed to be applied? Before the assignment, afterwards?

I don't see why this is different from, say, operator precedence. You have
the same questions. Why not just define ++ to do one or the other?

Operator precedence is a parsing issue as opposed to a run time one.
As far as your specific followup question is concerned, yes, the
order of events *could* have been defined -- but specifically
wasn't. (It is similar -- though not quite the same -- as the fact
that the order of evaluation of arguments to a function was left
undefined; in both cases it is to give the implementation the
freedom to decide.)

HTH,
--ag

 

[lilburne]

It's undefined behavior and most compilers won't do what was intended
as it's not even clear what the intent was. When is the side effect

(the ++) of

supposed to be applied? Before the assignment, afterwards?

I don't see why this is different from, say, operator precedence. You have
the same questions. Why not just define ++ to do one or the other?

Which other languages specify the order by which operands to
an operator are evaluated?

 

[Peter van Merkerk]

It's undefined behavior and most compilers won't do what was
intended

as it's not even clear what the intent was. When is the side

effect

(the ++) of

supposed to be applied? Before the assignment, afterwards?

I don't see why this is different from, say, operator precedence. You have
the same questions. Why not just define ++ to do one or the other?

Which other languages specify the order by which operands to
an operator are evaluated?

Java probably.

 

[J. Campbell]

Please consider the following:

st = sf[i++]

I seem to recall that there is a potential problem with an expression such
as this.

Along these same lines, is this defined?

x &= x-1;

Thanks,
Joe

 

[Ron Natalie]

Please consider the following:

st = sf[i++]

I seem to recall that there is a potential problem with an expression such
as this.

Along these same lines, is this defined?

x &= x-1;

That is fine. x is used only to compute the it's new value and
changed only once.

 

[Gene Wirchenko]

Please consider the following:

st = sf[i++]

I seem to recall that there is a potential problem with an expression such
as this.

Along these same lines, is this defined?

x &= x-1;

That is fine. x is used only to compute the it's new value and
changed only once.

To amplify,
x-1
does not change the value of x. This would be wrong though:
x &= x--;
because
x--
changes the value of x and so does the assignment.

Sincerely,

Gene Wirchenko

 

[J. Campbell]

Thanks Ron and Gene, for the quick replies.