From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 22:47:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C642B16A4CE; Wed, 8 Sep 2004 22:47:50 +0000 (GMT) Received: from possum.icir.org (possum.icir.org [192.150.187.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8747843D31; Wed, 8 Sep 2004 22:47:50 +0000 (GMT) (envelope-from pavlin@icir.org) Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i88MlmwK049087; Wed, 8 Sep 2004 15:47:48 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Message-Id: <200409082247.i88MlmwK049087@possum.icir.org> To: Harti Brandt In-Reply-To: Message from Harti Brandt <20040908140335.R23565@beagle.kn.op.dlr.de> Date: Wed, 08 Sep 2004 15:47:48 -0700 From: Pavlin Radoslavov X-Mailman-Approved-At: Thu, 09 Sep 2004 11:47:30 +0000 cc: Craig Rodrigues cc: freebsd-current@freebsd.org cc: Pavlin Radoslavov Subject: Re: g++ may fail to compile __packed structures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 22:47:50 -0000 > 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@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 was (re)defined as __packed.