This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: structure members of packed structures


On Tue, 15 Jul 2003, Nathan Sidwell wrote:
> Hans-Peter Nilsson wrote:
> > On Mon, 14 Jul 2003, Nathan Sidwell wrote:
>
> > Only for members whose type does not include a "packed"
> > qualifier, and only when used in an expression whose type also
> > doesn't include a packed qualifier.  For example, this should
> > remain valid and supported:
> >
> > struct Packed s1;
> > struct __attribute__ ((packed)) Unpacked *p1;
> > p1 = &s1.u;
> Lik Mark has said, it is hard to do this *and* prevent
>   struct Unpacked *p2 = &s1.u;
> because building the ADDR_EXPR loses the unalignedness information.

Does it *have* to lose that information?  Anyway, it's also hard
to explain to users (and have them content) that something broke
that's perfectly logical and has worked in the past.

> The 'proper' fix is to propagate an unaligned attribute, but I understand
> there have been objections in the past to doing that kind of thing.

Well, *I* wouldn't object... :-P

> The original problem manifested in C++ with reference binding to
> such a packed field. In C++ reference binding happens much more quietly
> (there is no '&' screaming at you in the source.)
> I could restrict to reference binding.

Yes, please.  The head-count of people carrying torches and
pitforks in your direction will be much lower, for one.

> Dale Johannesen wrote:
>  > Contingent on STRICT_ALIGNMENT, please.  Unaligned accesses are not
>  > a problem on all architectures.
> good point.

Hum, not sure if machine traits should matter here.  On second
thought, no, STRICT_ALIGNMENT shouldn't matter.  This is a
supposedly-portable (across GCC ports) GCC extension which
should behave the same on all systems.

> Another question. What about
> struct __attribute__((packed)) Foo
> {
>    T m;
> };
>
> here m happens to fall at an aligned address, and the size of Foo happens
> to be a multiple of that alignment. Should m be DECL_PACKED or not?

Yes.  If nothing else because it's easier. ;-)
(Easier on the rule system, at least.  Only the actual expressed
attributes would matter; not the context.)

By the way, we're discussing a special case of attribute ((aligned (N))).
I hope you mean to handle them all the same way.

brgds, H-P


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]