>It can be made to work by not packing Baz::m, and that is what g++ does
(with a
>warning%). Issuing an error in this case I don't think is acceptable
-- I know
>of users who would complain. If the user explicitly packed Baz::m
field, rather
>than the containing structure, I would be happy with a diagnostic.
I don't think this is the case. The questionable code (from the test
case) really is
struct Unpacked { int i; };
struct __attribute__ ((packed)) Packed
{
char c;
int i;
Unpacked u;
};
and the test expects that you cannot bind Packed::u to Unpacked& (error
expected), but that you can bind Packed::u::i to int& (not even a
warning expected). No warning is expected on the definition of Packed's
u member.
>> (In my idea world, ptr->m has type "packed Foo" in this case, and
it's
>> not permissible to binding a "packed Foo" to a "Foo const&", so
this
>> would be invalid, but I could live with undefined.)
>
>We need to distinguish the meanings of placing the packed attribute on
the
>structure and on the field itself. I agree with you that when the
attribute is
>on the field itself, the type should be 'packed Foo' and unbindable.
When the
>attribute is on the whole struct, I'm not so sure.
Yes, except that 'packed' on the containing structure doesn't really
imply 'packed' on the contained structure, it rather implies 'unaligned'
(unless [silently] overridden by ignoring the containing structure's
'packed' attribute, as you say is happening, but as I'm inclined to say
is not, given the expectations of the test case). Unfortunately gcc
(still) doesn't support an 'unaligned' attribute.
>>% ah, I think that warning should only be given on non-default-packed
arches.
>>Is this your problem Jan?
Not exactly. My problems are
(a) the above mentioned inconsistency in allowing binding to the whole
structure but not to its members, and
(b) on a default-packed target (or with -fpack-struct) getting reverse
behavior in allowing binding to Packed::u but not allowing binding to
Packed::u::i.
Jan
