This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: memcpy to an unaligned address
>>>>> "Dave" == Dave Korn <dave.korn@artimi.com> writes:
Dave> ----Original Message----
>> From: Shaun Jackman Sent: 02 August 2005 20:26
>> On 8/2/05, Paul Koning <pkoning@equallogic.com> wrote:
>>> One of the things that continues to baffle me (and my colleagues)
>>> is the bizarre way in which attributes such as "packed" work when
>>> applied to structs.
>>>
>>> It would be natural to assume, as Shaun did, that marking a
>>> struct "packed" (or, for that matter, "packed,aligned(2)") would
>>> apply that attribute to the fields of the struct.
>> This is exactly the behaviour suggested by the info docs:
>>
>> $ info gcc 'C Ext' 'Type Attr' ... Specifying this attribute for
>> `struct' and `union' types is equivalent to specifying the
>> `packed' attribute on each of the structure or union members.
>>
Dave> There are two separate issues here:
Dave> 1) Is the base of the struct aligned to the natural alignment,
Dave> or can the struct be based at any address
Dave> 2) Is there padding between the struct members to maintain
Dave> their natural alignments (on the assumption that the struct's
Dave> base address is aligned.)
Sure. But in Shaun's case it looks like (2) has been applied, except
that the compiler doesn't adjust the generated code correctly. I
would argue that "packed" applied to a whole struct should produce
BOTH effects 1 and 2.
There's a third case for which there appears to be no notation:
3) A pointer to a T that doesn't have the normal alignment of
the type T.
For example, as far as I can tell, GCC offers no way to say "pointer
to unaligned int" -- short of creating a one-member struct.
paul