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