Re: g++.dg/ext/packed3.C

[Nathan Sidwell <nathan at codesourcery dot com>]

Mark Mitchell wrote:

>  struct Foo { void operator=(Foo const &);};
>  struct Baz __attribute__((packed))
>  {
>    char c;
>    Foo m;
>  }
>
>  void Bar (Baz *ptr)
>  {
>    ptr->m = something;
>  }
>
> I'm not sure it can be made to work, without making the base class
> version of Foo::operator= expect unaligned input, which seems an
> unreasonable pessimization.  I would expect this code to be invalid, and
> either issue a diagnostic, or at least be considered undefined behavior.

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.

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

% ah, I think that warning should only be given on non-default-packed arches. 
Is this your problem Jan?

nathan

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk