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?

[Jack Klein]

On Mon, 24 Jul 2006 12:58:09 GMT, Frederick Gotham
<fg*******@SPAM .comwrote in comp.lang.c:

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.

To be perfectly correct, the C standard does not provide these
guarantees for ANY platform OR implementation.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Giorgio Silvestri]

"Ben Pfaff" <bl*@cs.stanfor d.eduha scritto nel messaggio
news:87******** ****@benpfaff.o rg...

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.

I think It is not sufficient.

(3) unsigned int does not have padding bits

should be preferible.

In presence of padding bits

(*(unsigned int *)a2) can have many representations .

In this case with assignment

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

you are not guaranteed to copy all bytes correctly.

--
Giorgio Silvestri

[Dave Thompson]

On Mon, 24 Jul 2006 12:58:09 GMT, Frederick Gotham
<fg*******@SPAM .comwrote:

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)

To be pedantic, alignof (unsigned char [4]) % alignof (unsigned int)
== 0. Although it is clearly expected and normally true that stricter
alignments (if they exist at all) are multiples of all looser ones,
that isn't explicitly required; a perverse (DS9k) implementation could
align char[4] to 3 and int to 5.

To be accurate, alignof(a1) % alignof(int) == 0
and alignof(a2) % alignof(int) . An implementation reasonably could
(and I use one which does) align 'top-level' variables a1 and a2 more
strictly than u_char[4] requires, and in fact sufficient for u_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

Presumably for C you meant either SoleMember(Type ) to expand to
struct SoleMember##Typ e

or the DEFINE_SOLE_MEM BER to do a typedef like
typedef struct { Type obj; } SoleMember##Typ e

<OTIn C++ your combination would work. </>

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.)

It does guarantee conversion from _actual_ (and hence correctly
aligned) first member back to the struct. But here of course the issue
is that _a variable of that same type_ may be misaligned. This is only
likely to be needed and happen in practice if the struct contains
other stricter members, but is formally allowed even if it doesn't.

- David.Thompson1 at worldnet.att.ne t

[ena8t8si]

Jack Klein wrote:

On Mon, 24 Jul 2006 12:58:09 GMT, Frederick Gotham
<fg*******@SPAM .comwrote in comp.lang.c:

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.

To be perfectly correct, the C standard does not provide these
guarantees for ANY platform OR implementation.

And even if it did, the behaviour would still be
undefined.

[Keith Thompson]

Dave Thompson <da************ *@worldnet.att. netwrites:

On Mon, 24 Jul 2006 12:58:09 GMT, Frederick Gotham
<fg*******@SPAM .comwrote:

>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)

To be pedantic, alignof (unsigned char [4]) % alignof (unsigned int)
== 0. Although it is clearly expected and normally true that stricter
alignments (if they exist at all) are multiples of all looser ones,
that isn't explicitly required; a perverse (DS9k) implementation could
align char[4] to 3 and int to 5.

[...]

Actually, I don't think it could. int could have an alignment of 5,
but char[4] can't have a required alignment of 3. Given:

char arr[2][4]

the two elements of arr must be adjacent and must each have a size of
4 bytes.

In general, because there can't be gaps between array elements, the
size of a type must be a multiple of its alignment. (The
implementation can adjust the size if necessary to make this happen,
for example by adding padding bits.)

--
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.

[Dave Thompson]

On Mon, 31 Jul 2006 07:31:53 GMT, Keith Thompson <ks***@mib.or g>
wrote:

Dave Thompson <da************ *@worldnet.att. netwrites:

To be pedantic, alignof (unsigned char [4]) % alignof (unsigned int)
== 0. Although it is clearly expected and normally true that stricter
alignments (if they exist at all) are multiples of all looser ones,
that isn't explicitly required; a perverse (DS9k) implementation could
align char[4] to 3 and int to 5.

[...]

Actually, I don't think it could. int could have an alignment of 5,
but char[4] can't have a required alignment of 3. Given:

char arr[2][4]

the two elements of arr must be adjacent and must each have a size of
4 bytes.

Oops, you're right. I didn't think far enough.

In general, because there can't be gaps between array elements, the
size of a type must be a multiple of its alignment. (The
implementation can adjust the size if necessary to make this happen,
for example by adding padding bits.)

Except to character types, or at least unsigned char and thus possibly
plain char. And, by the reasoning above, arrays of them.

But I still maintain in the example upthread int could (perversely)
require an alignment not supplied by char[4].

- David.Thompson1 at worldnet.att.ne t

[ena8t8si]

Dave Thompson wrote:

On Mon, 31 Jul 2006 07:31:53 GMT, Keith Thompson <ks***@mib.or g>
wrote:

Dave Thompson <da************ *@worldnet.att. netwrites:

To be pedantic, alignof (unsigned char [4]) % alignof (unsigned int)
== 0. Although it is clearly expected and normally true that stricter
alignments (if they exist at all) are multiples of all looser ones,
that isn't explicitly required; a perverse (DS9k) implementation could
align char[4] to 3 and int to 5.

[...]

Actually, I don't think it could. int could have an alignment of 5,
but char[4] can't have a required alignment of 3. Given:

char arr[2][4]

the two elements of arr must be adjacent and must each have a size of
4 bytes.

Oops, you're right. I didn't think far enough.

In general, because there can't be gaps between array elements, the
size of a type must be a multiple of its alignment. (The
implementation can adjust the size if necessary to make this happen,
for example by adding padding bits.)

Except to character types, or at least unsigned char and thus possibly
plain char. And, by the reasoning above, arrays of them.

But I still maintain in the example upthread int could (perversely)
require an alignment not supplied by char[4].

Are you saying anything more than, eg, char[4] can
require four byte alignment whereas int could allow
alignment of either 0 or 2 mod 4? Certainly the
set of alignments allowed for int must have some
overlap with the set of alignments allowed for
char[4].

[Keith Thompson]

en******@yahoo. com writes:

Dave Thompson wrote:

>On Mon, 31 Jul 2006 07:31:53 GMT, Keith Thompson <ks***@mib.or g>
wrote:

Dave Thompson <da************ *@worldnet.att. netwrites:
To be pedantic, alignof (unsigned char [4]) % alignof (unsigned int)
== 0. Although it is clearly expected and normally true that stricter
alignments (if they exist at all) are multiples of all looser ones,
that isn't explicitly required; a perverse (DS9k) implementation could
align char[4] to 3 and int to 5.
[...]

Actually, I don't think it could. int could have an alignment of 5,
but char[4] can't have a required alignment of 3. Given:

char arr[2][4]

the two elements of arr must be adjacent and must each have a size of
4 bytes.

Oops, you're right. I didn't think far enough.

In general, because there can't be gaps between array elements, the
size of a type must be a multiple of its alignment. (The
implementation can adjust the size if necessary to make this happen,
for example by adding padding bits.)

Except to character types, or at least unsigned char and thus possibly
plain char. And, by the reasoning above, arrays of them.

But I still maintain in the example upthread int could (perversely)
require an alignment not supplied by char[4].

Are you saying anything more than, eg, char[4] can
require four byte alignment whereas int could allow
alignment of either 0 or 2 mod 4? Certainly the
set of alignments allowed for int must have some
overlap with the set of alignments allowed for
char[4].

int could have an alignment of, say, 5. If char[4] required an
alignment of 4, then a union of an int and a char[4] would require an
alignment of at least 20.

But I'm not sure that char[4] can require an alignment stricter than 1
byte. For example, this:

char buf[5];
char (*p)[4] = (char(*)[4])(buf+1);

make p a pointer to a char[4] array that aliases elements 1..4 of buf.
Is this guaranteed to make p a valid pointer?

More generally, may an array of type X have a stricter alignment
requirement than type X itself?

An implementation may, of course, choose to align a char array, or
even a single char object, on, say, a word boundary; the question is
whether it can require such strict alignment.

--
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.

[Walter Roberson]

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:

>More generally, may an array of type X have a stricter alignment
requirement than type X itself?

No: that would interfere with the requirement that the address of
a variable of non-aggregate type is equivilent to the address
of an array of length 1 of that type. (If I recall correctly, this
requirement is part of the definition of pointer comparison.)
--
Programming is what happens while you're busy making other plans.

[ena8t8si]

Walter Roberson wrote:

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:

More generally, may an array of type X have a stricter alignment
requirement than type X itself?

No: that would interfere with the requirement that the address of
a variable of non-aggregate type is equivilent to the address
of an array of length 1 of that type. (If I recall correctly, this
requirement is part of the definition of pointer comparison.)

Keith was talking about arrays of length greater than one.