Jan Beulich wrote:
I don't think this is the case. The questionable code (from the test
case) really is
struct Unpacked { int i; };
struct __attribute__ ((packed)) Packed
{
char c;
int i;
Unpacked u;
};
and the test expects that you cannot bind Packed::u to Unpacked& (error
expected), but that you can bind Packed::u::i to int& (not even a
warning expected). No warning is expected on the definition of Packed's
u member.
ok. I think you're right. I think I've remembered why it is the way it is, and
that's because rejecting such a binding broke overload resolution of (the
trivial) Unpacked::operator=. I think that no longer applies.
nathan
--
Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED] :: http://www.planetfall.pwp.blueyonder.co.uk