Is a[i] = i++ correct?

[jeniffer]

Hi

I want to know why is a[i] = i++ ; wrong? People say that it is
because of different parsing during compilation.Please explain
technically why it is wrong/behaviour undefined?

Regards,
Jeniffer

[Richard Heathfield]

jeniffer said:

Hi

I want to know why is a[i] = i++ ; wrong?

What do you think it should mean? Given this code:

int a[3] = { 5, 7, 9 };
i = 0;
a[i] = i++; /* bug */

which member of a[] do you think will be updated, and to what value?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[christian.bau]

On Dec 28, 7:50*pm, [e-mail] (Kenny McCormack)
wrote:

>
christian.bau <[e-mail]:

Java programmers all over the world think you are completely wrong. In
Java, a [i] = i++; has defined behaviour. The expression is evaluated
from left to right. So first it evaluates the lvalue a [i], then the
right hand side i++. The array element changed is determined by the
original value of i.

Well, that doesn't actually prove anything. *What it means is that Java
defined it that way (probably because it was easier to implement) and
the programmers accepted it. *It doesn't mean it is desirable (nor, of
course, does it mean it is undesirable).

You actually think anything in Java is defined the way it is defined
because "it was easier to implement"? Seriously?

[Rick]

On Fri, 28 Dec 2007 20:17:30 +0000, Flash Gordon
<sp**@flash-gordon.me.ukwrote:

>I hope I have corrected your misconceptions.

Good evening, Flash.

Respectfully, there were no misconceptions. There were only partial
answers. I gave Jeniffer the answers that I thought were needed
without getting into a lot of detail that goes way beyond the scope of
my perception of the questions asked. Of course, my perception may
have been wrong.

[Rick]

On Fri, 28 Dec 2007 12:23:01 -0800, Keith Thompson <ks***@mib.org>
wrote:

>So, if i started off as, say, 2, then a[i] might be a[2], or it might
be a[3].

That's only part of the problem. The behavior is completely
undefined; a[i] might be a[42], or your left earlobe.

Good evening, Keith.

If...

i = 2;
a[ i ] = i++;

.... then I claim that a[ i ] will be either a[ 2 ] or a[ 3 ],
depending on whether i++ gets evaluated first or last, but it must be
either one or the other.

Wrong?

[Richard Heathfield]

Rick said:

<snip>

If...

i = 2;
a[ i ] = i++;

... then I claim that a[ i ] will be either a[ 2 ] or a[ 3 ],
depending on whether i++ gets evaluated first or last, but it must be
either one or the other.

Wrong?

Er, yeah, wrong. C doesn't actually guarantee this at all. But
realistically, how could it have any other value? Well, I don't plan to
work an example for you, but I recommend the following page, which gives
some hard data on the various results you get from different compilers for
similar expressions:

http://www.phaedsys.demon.co.uk/chri...wengtips3a.htm

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Kenny McCormack]

In article <dg********************************@4ax.com>,
Rick <re****************@nospam.nowrote:

>On Fri, 28 Dec 2007 12:23:01 -0800, Keith Thompson <ks***@mib.org>
wrote:

>>So, if i started off as, say, 2, then a[i] might be a[2], or it might
be a[3].

That's only part of the problem. The behavior is completely
undefined; a[i] might be a[42], or your left earlobe.

Good evening, Keith.

If...

i = 2;
a[ i ] = i++;

... then I claim that a[ i ] will be either a[ 2 ] or a[ 3 ],
depending on whether i++ gets evaluated first or last, but it must be
either one or the other.

Wrong?

Wrong, by the standards of this newsgroup.

Here, what actually happens in the real world is irrelevant. In fact,
the real world itself is pretty much irrelevant. What matters is what
the standard requires, and the possible existence of a machine which has
read and understands the standard as well as the language lawyers
(aka, "the regulars") here have done.

So, the theory is that once you invoke "undefined behavior", anything
can happen (and does on the hypothetical machine described above),
including assigning a value to a[42] or starting global thermonuclear
war.

[Flash Gordon]

Rick wrote, On 28/12/07 23:25:

On Fri, 28 Dec 2007 20:17:30 +0000, Flash Gordon
<sp**@flash-gordon.me.ukwrote:

>>I hope I have corrected your misconceptions.

Good evening, Flash.

Respectfully, there were no misconceptions.

There were I'm afraid, and the FAQ addresses them.

There were only partial
answers.

They were incorrect answers because they specified a limited number of
possibilities.

I gave Jeniffer the answers that I thought were needed
without getting into a lot of detail that goes way beyond the scope of
my perception of the questions asked. Of course, my perception may
have been wrong.

Your perception is wrong.

The standard *explicitly* states that the behaviour is undefined. The
standard also explains what it means by "undefined behaviour". It says
that undefined behaviour is behaviour upon which it poses no
requirements. I.e. as far as the language standard is concerned, if the
program invokes undefined behaviour literally *anything* that happens is
acceptable.

Now to give a possible example of *why* you could get something as
unexpected as a crash. Imagine a processor which can do multiple
operations in parallel (many processors have been able to do this for
years). Further imagine that it has multiple data paths, so it is
possible for it to read from one (cached) location at the same time as
writing to another. Now, the compiler knows that it does not have to
worry about you reading a variable at the same time as writing to it
because you can only read from it as part of generating the new value.
So it does minimal analysis and writes code that does...
Increment the location that contains i and in parallel read it in to
an index register.
Unfortunately on the processor I'm suggesting this is not possible since
it cannot simultaneously do an increment on a location and read it. So
this generates an "illegal parallel operation" exception which the C
runtime does not catch (because there is no "legal" way to generate it)
and your program crashes.

I've not used a processor precisely like the one I've described, but I
have used processors which can do things in parallel but only if the
combination of requested operations is valid and some of the
combinations were quite surprising.
--
Flash Gordon

[Charlton Wilbur]

>>>>"R" == Rick <re****************@nospam.nowrites:

RGood evening, Keith.

RIf...

Ri = 2; a[ i ] = i++;

R... then I claim that a[ i ] will be either a[ 2 ] or a[ 3 ],
Rdepending on whether i++ gets evaluated first or last, but it
Rmust be either one or the other.

RWrong?

Wrong. a[i] = i++; is explicitly undefined behavior; you've been
pointed at the FAQ entry that explains this in detail, so it's not
worth going into here. As soon as you write a[i] = i++; the compiler
is free to do whatever it wants with the rest of your program. It
could decide to fill the entire a array with junk, or halt because it
detected undefined behavior at runtime.

And seriously, even if it were somewhat defined, and you knew that
that statement wound up being at least one of the following, depending
on quirks of the compiler --

a[2] = 3;
a[3] = 3;
a[2] = 2;

-- why not just write the one you want? That way it will produce the
same results on all compilers, which is the point of a portable
programming language. a[i] = i+1; is *much* clearer, and has the
significant advantage of only one plausible interpretation.

Charlton
--
Charlton Wilbur
cw*****@chromatico.net

[Keith Thompson]

Charlton Wilbur <cw*****@chromatico.netwrites:

>>>>>"R" == Rick <re****************@nospam.nowrites:

RGood evening, Keith.

RIf...

Ri = 2; a[ i ] = i++;

R... then I claim that a[ i ] will be either a[ 2 ] or a[ 3 ],
Rdepending on whether i++ gets evaluated first or last, but it
Rmust be either one or the other.

RWrong?

Wrong. a[i] = i++; is explicitly undefined behavior; you've been
pointed at the FAQ entry that explains this in detail, so it's not
worth going into here. As soon as you write a[i] = i++; the compiler
is free to do whatever it wants with the rest of your program. It
could decide to fill the entire a array with junk, or halt because it
detected undefined behavior at runtime.

And seriously, even if it were somewhat defined, and you knew that
that statement wound up being at least one of the following, depending
on quirks of the compiler --

a[2] = 3;
a[3] = 3;
a[2] = 2;

-- why not just write the one you want? That way it will produce the
same results on all compilers, which is the point of a portable
programming language. a[i] = i+1; is *much* clearer, and has the
significant advantage of only one plausible interpretation.

The expression a[i] = i++ clearly *intends* to do two different
things; it modifies an element of the array a, and it increments i.
None of your proposed replacements modify i.

If it were well-defined, it could make sense to use a[i] = i++ in a
loop to set a[0] to 0, a[1] to 1, etc. If you want to achieve the
intended effect, you need to separate the modification of a and of i
with a sequence point.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Golden California Girls]

Flash Gordon wrote:

Rick wrote, On 28/12/07 23:25:

>On Fri, 28 Dec 2007 20:17:30 +0000, Flash Gordon
<sp**@flash-gordon.me.ukwrote:

>>>I hope I have corrected your misconceptions.

Good evening, Flash.

Respectfully, there were no misconceptions.

There were I'm afraid, and the FAQ addresses them.

> There were only partial
answers.

They were incorrect answers because they specified a limited number of
possibilities.

> I gave Jeniffer the answers that I thought were needed
without getting into a lot of detail that goes way beyond the scope of
my perception of the questions asked. Of course, my perception may
have been wrong.

Your perception is wrong.

The standard *explicitly* states that the behaviour is undefined. The
standard also explains what it means by "undefined behaviour". It says
that undefined behaviour is behaviour upon which it poses no
requirements. I.e. as far as the language standard is concerned, if the
program invokes undefined behaviour literally *anything* that happens is
acceptable.

So when it is run, it empties your bank account and transfers it all to mine.

So I'm sure we will hear about a complier that some undergrad wrote in some
class that does something other than evaulate one side or the other first, or
some obscure chip that has some strange instruction that this one shot compiler
emits that causes all havoc and stops every train in Boston. No one cares
because they aren't asking about that specific implementation defined example!

Post a table about what the top ten most used compliers do when generating code
for the top ten most used chips and someone might consider it useful information.

[CBFalconer]

Keith Thompson wrote:

>

.... snip ...

>
The expression a[i] = i++ clearly *intends* to do two different
things; it modifies an element of the array a, and it increments
i. None of your proposed replacements modify i.

If it were well-defined, it could make sense to use a[i] = i++ in
a loop to set a[0] to 0, a[1] to 1, etc. If you want to achieve
the intended effect, you need to separate the modification of a
and of i with a sequence point.

Of course it is trivially easy to rewrite the statement to do
something accurately defined. For instance:

a[i] = i + 1; i++;
or
a[i + 1] = i; i++;

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Tim Smith]

In article <C-******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

... then I claim that a[ i ] will be either a[ 2 ] or a[ 3 ],
depending on whether i++ gets evaluated first or last, but it must be
either one or the other.

Wrong?

Er, yeah, wrong. C doesn't actually guarantee this at all. But
realistically, how could it have any other value? Well, I don't plan to
work an example for you, but I recommend the following page, which gives
some hard data on the various results you get from different compilers for
similar expressions:

http://www.phaedsys.demon.co.uk/chri...wengtips3a.htm

For i == 2 initially, one of those is probably realistically what you'll
get, but how about for other values of i?

Imagine an implementation using 64-bit ints, on a processor where
arithmetic is done using 32-bit operations, and the processor has
multiple hardware threads, which the compiler takes advantage of, and
imagine that i is a value such that i++ has changes to the bits in both
the lower and the upper 32-bits.

Neither increment nor assignment would be atomic for integers on this
setup, and the i in a[i] could be wildly off, using, say, the
pre-increment upper 32 bits and post increment lower 32 bits. It would
then be off by around 4 billion.

--
--Tim Smith

[Army1987]

Kaz Kylheku wrote:

C is not cast in stone. Past undefined behaviors can easily be defined
in the future, without breaking any correctly written code.

Considering that the C99 standard has yet to be widely implemented, C is
cast in stone for most practical purposes.

--
Army1987 (Replace "NOSPAM" with "email")

[Kelsey Bjarnason]

[snips]

On Fri, 28 Dec 2007 23:45:20 +0000, Kenny McCormack wrote:

Here, what actually happens in the real world is irrelevant. In fact,
the real world itself is pretty much irrelevant.

Most of us write code that is expected to work in the real world.

What matters is what
the standard requires

Correct, as this is the only realistic guideline we have as to how the
code we write is supposed to behave. It defines exactly how our code is
expected to work, but *only* if we adhere to the standard.