a[i] = a[j]... Dangerous?

[s0suk3]

I'm a bit unclear whether a statement such as 'a[i] = a[j];' causes
undefined behavior or some other abnormalities. A statement such as
'a[i] = a[i++];' would definitely cause problems because of the double
use and side effect of 'i'. But in the former case, will the double
use of the array 'a' cause problems? Or will the right operand
('a[j]') of the assignment be evaluated first and then safely assigned
to the right operand ('a[i]')?

Thanks

[pete]

s0****@gmail.co m wrote:

I'm a bit unclear whether a statement such as 'a[i] = a[j];' causes
undefined behavior or some other abnormalities.

It doesn't.

--
pete

[Walter Roberson]

In article <20************ ****@gmail.com> ,
Kaz Kylheku <kk******@gmail .comwrote:

>Note that a[i] = a[i] is well-defined, from which it follows that a[i] = a[j]
is well defined even if i == j.

I don't seem to recall at the moment... if a is an array of
volatile sig_atomic_t and while the statement a[i] = a[i]; is
being executed, there is a signal handler fired which changes
a[i], what is the "well defined" result?
--
"Eightly percent of the people in the world are fools and the
rest of us are in danger of contamination." -- Walter Matthau

[CBFalconer]

s0****@gmail.co m wrote:

>
I'm a bit unclear whether a statement such as 'a[i] = a[j];' causes
undefined behavior or some other abnormalities. A statement such as
'a[i] = a[i++];' would definitely cause problems because of the
double use and side effect of 'i'. But in the former case, will the
double use of the array 'a' cause problems? Or will the right
operand ('a[j]') of the assignment be evaluated first and then
safely assigned to the right operand ('a[i]')?

Yes. However a pointer to a[i] _may_ be computed before the value
of a[j] is derived. Your expression is safe.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[August Karlstrom]

s0****@gmail.co m wrote:

I'm a bit unclear whether a statement such as 'a[i] = a[j];' causes
undefined behavior or some other abnormalities. A statement such as
'a[i] = a[i++];' would definitely cause problems because of the double
use and side effect of 'i'. But in the former case, will the double
use of the array 'a' cause problems? Or will the right operand
('a[j]') of the assignment be evaluated first and then safely assigned
to the right operand ('a[i]')?

Thanks

In the assignment

a[i] = a[j];

neither a[i] nor a[j] has any side effects so it is certainly a
well-defined statement.
August

[Robbie Hatley]

<s0****@gmail.c omwrote:

I'm a bit unclear whether a statement such as 'a[i] = a[j];' causes
undefined behavior or some other abnormalities. A statement such as
'a[i] = a[i++];' would definitely cause problems because of the double
use and side effect of 'i'. But in the former case, will the double
use of the array 'a' cause problems? Or will the right operand
('a[j]') of the assignment be evaluated first and then safely assigned
to the right operand ('a[i]')?

"a[i] = a[j];" is legal.

The only surprises it might have in store is if you don't keep
the ranges of numbers over which i and j vary non-overlapping.
If they overlap, stuff will get over-written. If that's what
you intended, great; otherwise, it's a problem.

I use something like the above in production code at work,
to periodically move the right-most 80% of an array to the
far left, freeing up space on the right. A FIFO buffer;
only the most recent data is retained, due to space limitations:

int blat[800];
.... do some stuff ...
// shift data left when buffer gets full:
if (BufferIsFull() )
{
for ( i = 0 ; i < 700 ; ++i )
{
// Discard oldest 100 bytes and shift newest 700 leftward,
// freeing 100 bytes on right side of array:
blat[i] = blat[i+100];
}
}

--
Cheers,
Robbie Hatley
lonewolf aatt well dott com
www dott well dott com slant user slant lonewolf slant

[vippstar]

On Jul 3, 2:34 am, "Robbie Hatley"
<see.my.signat. [e-mail] .addresswrote:
<snip>

I use something like the above in production code at work,
to periodically move the right-most 80% of an array to the
far left, freeing up space on the right. A FIFO buffer;
only the most recent data is retained, due to space limitations:

int blat[800];
... do some stuff ...
// shift data left when buffer gets full:
if (BufferIsFull() )
{
for ( i = 0 ; i < 700 ; ++i )
{
// Discard oldest 100 bytes and shift newest 700 leftward,
// freeing 100 bytes on right side of array:
blat[i] = blat[i+100];
}

}

Just use memmove()

memmove(blat, &blat[100], 700 * sizeof *blat);

[Kaz Kylheku]

On 2008-07-02, Robbie Hatley <se************ **@for.my.email .addresswrote:

"a[i] = a[j];" is legal.

The only surprises it might have in store is if you don't keep
the ranges of numbers over which i and j vary non-overlapping.
If they overlap, stuff will get over-written.

a[i] is ``stuff''.

a[i] is overwritten.

Therefore, stuff is overwritten.

What may be a surprise is that a[j] is overwritten, if i == j.

I use something like the above in production code at work,
to periodically move the right-most 80% of an array to the
far left, freeing up space on the right. A FIFO buffer;
only the most recent data is retained, due to space limitations:

int blat[800];
... do some stuff ...
// shift data left when buffer gets full:
if (BufferIsFull() )
{
for ( i = 0 ; i < 700 ; ++i )
{
// Discard oldest 100 bytes and shift newest 700 leftward,
// freeing 100 bytes on right side of array:
blat[i] = blat[i+100];
}
}

Why would you write loops that reinvent memmove?

#include <string.h>

/* ... */

memmove(blat + i, blat + i + 100, 700 * sizeof *blat);

** Posted from http://www.teranews.com **

[Robbie Hatley]

<vi******@gmail .comwrote:

Robbie Hatley wrote:

int blat[800];
... do some stuff ...
// shift data left when buffer gets full:
if (BufferIsFull() )
{
for ( i = 0 ; i < 700 ; ++i )
{
// Discard oldest 100 bytes and shift newest 700 leftward,
// freeing 100 bytes on right side of array:
blat[i] = blat[i+100];
}
}

Just use memmove()
memmove(blat, &blat[100], 700 * sizeof *blat);

I'd probably seen "memmove" in the libc header before, but using
it for that application simply never occurred to me.

And even after reading the instructions for memmove, I like my
version better, because it's more obvious what's happening:

for ( i = 0; i < 700 ; ++i ) blat[i] = blat[i+1]; // TRANSPARENT

Whereas with memmove, you can't "see under the hood":

memmove(blat, &blat[100], 700 * sizeof *blat); // OPAQUE

I even doubt if the compiled code is faster for memmove.
I'd guess it just uses a for loop. And if it does any
error checking, it could even be slower. (Though in
either case, we're talking maybe about 1 microsecond
every 20 minutes or so. Cheap.)

--
Cheers,
Robbie Hatley
lonewolf aatt well dott com
www dott well dott com slant user slant lonewolf slant

[santosh]

Robbie Hatley wrote:

>
<vi******@gmail .comwrote:

>Robbie Hatley wrote:

>
int blat[800];
... do some stuff ...
// shift data left when buffer gets full:
if (BufferIsFull() )
{
for ( i = 0 ; i < 700 ; ++i )
{
// Discard oldest 100 bytes and shift newest 700 leftward,
// freeing 100 bytes on right side of array:
blat[i] = blat[i+100];
}
}

Just use memmove()
memmove(blat , &blat[100], 700 * sizeof *blat);

I'd probably seen "memmove" in the libc header before, but using
it for that application simply never occurred to me.

And even after reading the instructions for memmove, I like my
version better, because it's more obvious what's happening:

for ( i = 0; i < 700 ; ++i ) blat[i] = blat[i+1]; // TRANSPARENT

Whereas with memmove, you can't "see under the hood":

memmove(blat, &blat[100], 700 * sizeof *blat); // OPAQUE

I even doubt if the compiled code is faster for memmove.
I'd guess it just uses a for loop. And if it does any
error checking, it could even be slower. (Though in
either case, we're talking maybe about 1 microsecond
every 20 minutes or so. Cheap.)

The standard library memmove can take advantage of any special block
memory copy instructions that the hardware may have, using assembler.
Your replacement cannot do so.

Having said that I have observed in some tests that a custom written
memmove (also memcpy) is actually faster than the one provided by the
standard library, if the code is compiled with optimisations enabled.
This is because the C library on my machine is compiled to run on all
Intel processors from the 80x386 onwards while my custom memmove is
optimised for the specific processor model in operation. The difference
though is minuscule, and shows up only for large copies or intensive
loops.