Re: g++ may fail to compile __packed structures

> PR>> On Mon, Sep 06, 2004 at 01:24:15PM -0700, Pavlin Radoslavov wrote:
> PR>> > It appears that the lastest g++ compiler that comes with FreeBSD may
> PR>> > fail to compile a __packed structure when one of its fields is
> PR>> > passed by reference. At the end of this email is a sample program
> PR>> > that demonstrates the problem. The compilation error is:
> PR>> > 
> PR>> > pavlin_at_carp[14] g++34 test.cc
> PR>> > test.cc: In function `int main()':
> PR>> > test.cc:22: error: cannot bind packed field `f1.foo::f' to `int&'
> PR>> > Exit 1
> PR>> > 
> PR>> > The problem appears to exist only with the recent g++ compiler that
> PR>> > comes with FreeBSD:
> PR>> 
> PR>> This change was made recently to gcc:
> PR>> http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01664.html
> PR>
> PR>Yes, I am aware of that patch (when I did some search on the subject
> PR>before posting my email). However, again, when I use the vanilla g++
> PR>3.4.1 which is 2 months old, or even the vanilla 3.4.2 which was
> PR>just released today, I don't get the compilation error.
> PR>Hence, why the disparity between the vanilla gcc and the lastest
> PR>gcc that comes with FreeBSD?
> PR>
> PR>> Apparently in C++, you are not allowed to  have non-const references
> PR>> to packed fields.  See:
> PR>> http://www.comnets.rwth-aachen.de/doc/c++std/decl.html#dcl.init.ref
> PR>
> PR>The above URL doesn't say anything about packed fields.
> PR>Please correct me if I am wrong, but I think that __packed is not
> PR>part of the C or C++ standart, hence this leaves some gray area for
> PR>interpretation. Anyway, this is a subject for the gcc ML...
> PR>
> PR>However, I am trying to find-out why the FreeBSD gcc behaves
> PR>different from the vanilla gcc, and which compiler has the "right"
> PR>behavior.
> 
> Neither. As you said __packed is not part of any standard. If you take 
> into account that a reference is essentially a pointer (at least in the 
> case of a function argument) this pointer could easily have the wrong 
> alignment, because your packed field may have the wrong alignment. To 
> catch this case the compiler would need to propagate that information at 
> run-time to the function. In short: don't use such features. If you need 
> packed (because you're accessing hardware) pass by value not by reference.

Yes, I understand why __packed can be problematic, and I am not
arguing what the behavior of the compiler should be. What I find
confusing is that the compiler that comes with FreeBSD behaves
differently from the vanilla gcc compiler (from gcc.gnu.org).
I am trying to find-out whether the difference in the behavior was
intentional or because of an overlook somewhere. In either case, I
believe the desired behavior is that both compilers should be
consistent.

Thanks,
Pavlin

P.S. BTW, the reason I came across __packed is because sometime in
the not so distant pass, "struct ip" inside <netinet/ip.h> was
(re)defined as __packed.