Re: Packed structs and C++

[Mark Mitchell <mark at codesourcery dot com>]

> why does this happen? Well, map::value_type (f.i, to) calls
> 	pair<int, int>::pair (L const &, R const &);
> which implicitly takes the address of f.i, and loses the unalignedness
> information. This can lead to bus errors or silently reading the wrong
> memory locations.

Ugh.  Insert standard complaints about extensions here.

> solution0)
> do nothing. I think this is unacceptable. In C, it is more obvious when
> you are taking the address of something, in C++ it happens much more
> quietly.

Agreed.

> solution1)
> packed fields have an unaligned type, and that is propagated through
> the type system just as cv-qualifiers are. This will also work for
> C, and give allow the user to specify when unaligned objects might be
> pointed to. Template deduction will probably have to start deducing
> attributes -- bleah!

Arguably, this is the best solution -- from a pure language design point
of view.  I've argued before that alignment attributes should be part of
the type, and that "int i" is a subtype of "unaligned int i"; the former
can do everything the latter can do, but also supports the "read
aligned" and "write aligned" operations.

However, I agree that trying to do this in C++ is a mistake -- the
language is certainly complex enough as it is.  You're entirely correct
that figuring how these new types would interact with templates is
complicated at best.

> solution2)
> packed fields are like bitfields. Thus they cannot have their address
> taken and they can bind to 'T const &' parameters by invoking
> the copy constructor. If they cannot have their address taken, do
> we want offsetof (M, packedField) to work or not?

I think this is a good solution, at least for now.

I think offsetof should still work -- but that requires the offsetof
magic that we don't have yet, so, for now, it won't work.  That's OK.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC