Casting a byte array to allow assignment

[quantumred]

I found the following code floating around somewhere and I'd like to
get some comments.

unsigned char a1[4]= { 5,10,15,20};
unsigned char a2[4]= { 25,30,35,40};

*(unsigned int *)a1=*(unsigned int *)a2;

// now a1[0]=a2[0], a1[1]=a2[1], etc.

This is taking a byte array, casting it to a 4 byte integer pointer,
then dereferencing it, then assigning it. This results in the contents
of array a1 copied to array a2. (corrections to my interpretation
welcome)

I don't know why this was done this way. My first instinct would have
been to use memcpy. Is this faster than memcpy? Are there any dangers
other than the potential for int not being 4 bytes?

[pete]

quantumred wrote:

>
I found the following code floating around somewhere and I'd like to
get some comments.

unsigned char a1[4]= { 5,10,15,20};
unsigned char a2[4]= { 25,30,35,40};

*(unsigned int *)a1=*(unsigned int *)a2;

// now a1[0]=a2[0], a1[1]=a2[1], etc.

This is taking a byte array, casting it to a 4 byte integer pointer,
then dereferencing it, then assigning it. This results in the contents
of array a1 copied to array a2. (corrections to my interpretation
welcome)

I don't know why this was done this way. My first instinct would have
been to use memcpy. Is this faster than memcpy? Are there any dangers
other than the potential for int not being 4 bytes?

There's the possibility that a1 and a2 don't
have the proper alignment for type unsigned.

--
pete

[Aaron Gage]

probably a little quicker then memcpy, no function call overhead.

prob. safe if you know how your compiler treats these types, or you can
set appropriate command line params to your compiler (or use some
pragmas)
to force alignment and so on.

Not really worth the trouble i suspect though: not at all clear what is
happening, and
what you gonna save? a few instructions on a P4/Athlon/etc is nothin!

[Flash Gordon]

Aaron Gage wrote:

Please quote what you are replying to, Google now makes this easy. See
the last link in my sig for more information.

The code in question was:

quantumred wrote:

I found the following code floating around somewhere and I'd like to
get some comments.

unsigned char a1[4]= { 5,10,15,20};
unsigned char a2[4]= { 25,30,35,40};

*(unsigned int *)a1=*(unsigned int *)a2;

// now a1[0]=a2[0], a1[1]=a2[1], etc.

This is taking a byte array, casting it to a 4 byte integer pointer,
then dereferencing it, then assigning it. This results in the contents
of array a1 copied to array a2. (corrections to my interpretation
welcome)

I don't know why this was done this way. My first instinct would have
been to use memcpy. Is this faster than memcpy? Are there any dangers
other than the potential for int not being 4 bytes?

probably a little quicker then memcpy, no function call overhead.

On most modern compiler there is probably no difference in speed.

prob. safe if you know how your compiler treats these types, or you can
set appropriate command line params to your compiler (or use some
pragmas)
to force alignment and so on.

Definitely *not* safe. It might work on the OPs specific platform, but
it is not safe because the code might then get reused on a system where
it does not work.

Not really worth the trouble i suspect though: not at all clear what is
happening, and
what you gonna save? a few instructions on a P4/Athlon/etc is nothin!

Definitely not worth the trouble.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[Frederick Gotham]

quantumred posted:

unsigned char a1[4]= { 5,10,15,20};
unsigned char a2[4]= { 25,30,35,40};

*(unsigned int *)a1=*(unsigned int *)a2;

This will work perfectly if:

(1) 4 == sizeof(int)

(2) alignof(char[4]) >= alignof(int)
The C Standard does not provide these guarantees for all platforms and
implementations . What you have is non-portable, platform-specific code.

It seems to me that the author was aiming to optimise the copying of an
array. I'd probably take a route somewhat akin to the following:

#define DEFINE_SOLE_MEM BER(Type) \
\
struct SoleMember##Typ e { \
Type obj; \
} /* Usage code provides semi-colon */ \

#define SoleMember(Type ) SoleMember##Typ e

int main()
{
unsigned char a1[4]= {5,10,15,20};
unsigned char a2[4]= {25,30,35,40};

typedef char char4[4];

DEFINE_SOLE_MEM BER(char4);

*(SoleMember(ch ar4)*)a1 = *(SoleMember(ch ar4) const*)a2;
}
(The Standard guarantees that you can cast from a pointer to a struct, to a
pointer to the type of its first member. However, I don't believe it
guarantees the reverse -- so the code might be slightly dubious.)

--

Frederick Gotham

[Eric Sosman]

Frederick Gotham wrote:

quantumred posted:

>>unsigned char a1[4]= { 5,10,15,20};
unsigned char a2[4]= { 25,30,35,40};

*(unsigned int *)a1=*(unsigned int *)a2;

This will work perfectly if:

(1) 4 == sizeof(int)

(2) alignof(char[4]) >= alignof(int)
The C Standard does not provide these guarantees for all platforms and
implementations . What you have is non-portable, platform-specific code.

It seems to me that the author was aiming to optimise the copying of an
array. I'd probably take a route somewhat akin to the following:

#define DEFINE_SOLE_MEM BER(Type) \
\
struct SoleMember##Typ e { \
Type obj; \
} /* Usage code provides semi-colon */ \

#define SoleMember(Type ) SoleMember##Typ e

int main()
{
unsigned char a1[4]= {5,10,15,20};
unsigned char a2[4]= {25,30,35,40};

typedef char char4[4];

DEFINE_SOLE_MEM BER(char4);

*(SoleMember(ch ar4)*)a1 = *(SoleMember(ch ar4) const*)a2;
}
(The Standard guarantees that you can cast from a pointer to a struct, to a
pointer to the type of its first member. However, I don't believe it
guarantees the reverse -- so the code might be slightly dubious.)

In particular, it doesn't solve the alignment issue. The
alignment requirement for a struct object need not be a simple
function of the alignment requirements of its elements; the fact
that the enclosing object is a struct may impose alignment
requirements of its own. Therefore, either or both of the casts
in the above code may produce invalid struct pointers.

It also doesn't solve the size issue. The sizeof a struct
is at least as great as the sum of the sizeof its elements, but
may be greater. In the code above, sizeof(SoleMemb erchar4) may
be greater than sizeof(char4), and if so the assignment tries to
read from memory beyond the end of the a2[] array, and undefined
behavior ensues.

One is left to ask: What issue *does* the above code solve?
Is it in any way better than the broken original, or is it just
a more sophisticated expression of the same errors?

--
Eric Sosman
es*****@acm-dot-org.invalid

[Frederick Gotham]

Eric Sosman posted:

One is left to ask: What issue *does* the above code solve?
Is it in any way better than the broken original, or is it just
a more sophisticated expression of the same errors?

The code makes the (naive?) assumption that a struct consisting of a sole
member is identical to the member on its own.

Is this guaranteed? No.

Is it reasonable? I don't know, but it sounds sort of logical.
<OFF-TOPIC>
You've just given me an idea for a post to comp.std.c++.
</OFF-TOPIC>

--

Frederick Gotham

[Ben Pfaff]

Frederick Gotham <fg*******@SPAM .comwrites:

quantumred posted:

>unsigned char a1[4]= { 5,10,15,20};
unsigned char a2[4]= { 25,30,35,40};

*(unsigned int *)a1=*(unsigned int *)a2;

This will work perfectly if:

(1) 4 == sizeof(int)

(2) alignof(char[4]) >= alignof(int)

(3) unsigned int does not have trap representations , etc.
--
"The way I see it, an intelligent person who disagrees with me is
probably the most important person I'll interact with on any given
day."
--Billy Chambless

[Keith Thompson]

Frederick Gotham <fg*******@SPAM .comwrites:

quantumred posted:

>unsigned char a1[4]= { 5,10,15,20};
unsigned char a2[4]= { 25,30,35,40};

*(unsigned int *)a1=*(unsigned int *)a2;

This will work perfectly if:

(1) 4 == sizeof(int)

(2) alignof(char[4]) >= alignof(int)
The C Standard does not provide these guarantees for all platforms and
implementations .

[...]

Nor does it provide a function or operator called "alignof".

(That's not a complaint, just a clarification; your hypothetical
"alignof" operator is a good way to express the idea.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[SM Ryan]

"quantumred " <qu********@gma il.comwrote:
# I found the following code floating around somewhere and I'd like to
# get some comments.
#
# unsigned char a1[4]= { 5,10,15,20};
# unsigned char a2[4]= { 25,30,35,40};
#
# *(unsigned int *)a1=*(unsigned int *)a2;
#
# // now a1[0]=a2[0], a1[1]=a2[1], etc.
#
# This is taking a byte array, casting it to a 4 byte integer pointer,
# then dereferencing it, then assigning it. This results in the contents
# of array a1 copied to array a2. (corrections to my interpretation
# welcome)
#
# I don't know why this was done this way. My first instinct would have
# been to use memcpy. Is this faster than memcpy? Are there any dangers
# other than the potential for int not being 4 bytes?

If you have a 32 bit data path between memory and cpu, it's 4 times
faster to move an aligned word at a time instead of a byte at a time.
This can be a win on programs that do a lot of data movement on
aligned pointers.

A good implementation of memcpy will check lengths and alignments and
do the fastest possible move available on that particular machine.
Typical implementations are something else. Even a good implementation
without compiler assistance requires start up code everytime it is
called to determine what is the fastest move; often the compiler will
have all that information available, but it doesn't often happen that
information is made available to memcpy.

This kind of code is either defense against mediocre memcpy
implementations or a vain belief the programmer is cleverer
than the compiler.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
But I do believe in this.