[Bug c++/17519] [3.4/4.0/4.1/4.2 Regression] Warning for array of packed non-POD in packed struct

amylaar at gcc dot gnu dot org gcc-bugzilla@gcc.gnu.org
Fri Feb 10 18:22:00 GMT 2006



------- Comment #9 from amylaar at gcc dot gnu dot org  2006-02-10 18:22 -------
(In reply to comment #4)
> There's certainly a good case for warning about packing that's likely not to
> have the desired results - we've been bitten by that before. But that doesn't
> really apply to all non-POD; you can define a subset safe-non-POD (broadly
> speaking, no virtual functions/bases and (recursively) no unsafe non-static data
> members) where everything still has reasonably predictable representations and
> you don't need extra space for polymorphism magic.

All the more reason to warn if we don't pack these members now, but we might
fix that in the future and thus change the data layout.
I.e. if the packed attribute is applied (individually or as part of an entire
struct / class) to a member, but ignored, and this is relevant for the size or
alignment of that member, we should warn.  That obviously applies for the
target
we are compiling for, but I think if possible, we should warn if the ignoring
of the packed attribute is relevant for any possible gcc target.
> 
> So if you do go in that direction, please consider separate warnings for those
> non-POD types that can nevertheless safely be packed and those that can't.
> Classes made non-POD through fairly innoccuous constructions - e.g.
> constructors, simple inheritance - are often useful in abstracting hardware
> registers, data formats, etc. We'd be swamped in warnings if we got one for
> every packed non-POD, but we definitely do want to know if there's something
> that's actually going to mess things up.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17519



More information about the Gcc-bugs mailing list