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

["titusjan at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #10 from titusjan at gmail dot com  2006-02-15 11:53 -------
(In reply to comment #9)
> (In reply to comment #4)

[snip]

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

I've got non-POD objects that abstract endiannes and use them in arrays that
represent data-packets. The non-POD objects are quite simple, they don't use
inheritance or virtual methods. I use assert statements to verify the size of
the data-packets and notice that packing hasn't changed. Nevertheless, I get
this warning when changing from gcc 3.3 to 4.0.

Is this warning given because there are other targets where the packing will be
different, or because the packing might change in the future?

In the first case: I don't need my program to be portable to every possible GCC
target. I think it's my responsibility to ensure that it works on the relevant
targets and would only want to get a warning if the  packed attribute is
actually ignored.

In the second case: how likely is it that the packing will change in the
future? I don't see any reason why my objects can't be packed but I have no
knowledge of the GCC internals.

In any case, can this warning be suppressed or is there a simple workaround?
Since I use the asserts I'm not realy worried about missing the case when the
packet attribute is ignored.

Forgive me for using this bugtracking system as a helpdesk but I hope my
questions contribute to the discussion.

Pepijn.


-- 


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