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

Reply via email to