cvs commit: src/include ar.h

[Joseph Koshy]

bde> Non-broken code knows that byte-aligned data needs to be copied
bde> into structs using memcpy().

Do keep in mind that this is `struct ar_hdr' we are talking about, not
something else.

Having to use memcpy() to copy from a collection of ASCII strings (in file)
to a collection of ASCII strings (in struct ar_hdr) to cope with alignment
issues is odd.

To be truly portable, code needs to memcpy() in each ASCII string member
of `struct ar_hdr'  separately since we cannot make assumptions about
the file and memory layout being identical.

Needless to say no code in our tree does this today.

So we need to look at the original intent of why a `struct ar_hdr' was
declared as a collection of fixed size ASCII strings.   My guess is that it
was written that way to be able to directly describe its file layout: ASCII
for portability and fixed size char[] arrays to avoid issues with structure
padding.   Declaring it as __packed informs today's compilers of this
intent. It also brings down the alignment requirements for `struct ar_hdr'
on the ARM to match that of other platforms as a side-effect.

bde> I doubt that it is needed for more than breaking the warning.  You
bde> would have to be unlucky or shooting your feet for
bde> "(struct ar *)&byte_array[offset]" to give a pointer that is actually
bde> misaligned.  Large arrays of chars are normally aligned to the word
bde> size even if they are on the stack, and the archive header is at offset
bde> 0 in files.

In an ar(1) archive, there is a `struct ar_hdr' before each archive member.
The only 'alignment' expected for this structure is that of falling on
even offsets in the file.  This is only enforced programmatically though.

Regards,
Koshy