From owner-cvs-src@FreeBSD.ORG Sat Nov 18 20:21:37 2006 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9756216A412; Sat, 18 Nov 2006 20:21:37 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FF7443D64; Sat, 18 Nov 2006 20:21:30 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id kAIKLWwY085580; Sat, 18 Nov 2006 23:21:32 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id kAIKLPwY085576; Sat, 18 Nov 2006 23:21:25 +0300 (MSK) (envelope-from yar) Date: Sat, 18 Nov 2006 23:21:25 +0300 From: Yar Tikhiy To: Bruce Evans Message-ID: <20061118202125.GD80527@comp.chem.msu.su> References: <20061117201432.X11101@delplex.bde.org> <20061117.105304.1769993002.imp@bsdimp.com> <20061118214618.U15111@delplex.bde.org> <20061118.110343.58444366.imp@bsdimp.com> <20061119052526.S16985@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061119052526.S16985@delplex.bde.org> User-Agent: Mutt/1.5.9i Cc: src-committers@freebsd.org, jkoshy@freebsd.org, cvs-all@freebsd.org, phk@phk.freebsd.dk, cvs-src@freebsd.org, "M. Warner Losh" Subject: Re: cvs commit: src/include ar.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 20:21:37 -0000 On Sun, Nov 19, 2006 at 05:47:40AM +1100, Bruce Evans wrote: > On Sat, 18 Nov 2006, M. Warner Losh wrote: > > >In message: <20061118214618.U15111@delplex.bde.org> > > Bruce Evans writes: > >: On Fri, 17 Nov 2006, M. Warner Losh wrote: > >: > >: > In message: <20061117201432.X11101@delplex.bde.org> > >: > Bruce Evans writes: > >: > : For that the comment should be something like: > >: > : > >: > : __packed; /* Align (sic) to work around bugs on arm > >(*). */ > >: > : > >: > : but I doubt that arm is that broken. > >: > : > >: > : (*) See this thread for more details. > >: > > >: > But they aren't bugs. > >: > >: Er, this thread gived the details of why they are bugs. > > > >Wait, is this the ar or the struct ip thing.. Ar is clearly needed, > >but I was going to test the packedness on struct ip... I've just had > >my first son and am operating on too little sleep :-(. > > I was mostly talking about struct ip. Something is needed for struct > ar_hdr, since although it has size a multiple of 4 applications expect > it to have alignment 1 but arm gives it alignment 4. Something is needed > for struct ether_header (which sam recently packed), since it wants to > have size 14 and alignment 2, but arm gives it size 16 and alignment 4. > Nothing shoulded be need for struct ip, since it wants to have size 20 and > alignment 4, and arm gives it that. The C standard provides no clues as to how structures are packed or aligned. The only thing it says is that objects have alignment and it can be the same or not the same for different objects. That is, a future C compiler is allowed to put holes in struct ip, and in any struct it wants, unless we use the unportable __packed hack -- or abandon the structs in favor of byte-level access to seamless data such as hardware or network packets. That's what I meant by struct ip being historically lucky. We still want to use __packed and __align, but IMHO we should realize that we just pay the price of non-portability for using convenient things such as struct in low-level programming. Perhaps we're just getting even with the C standard authors, who sacrificed the ability to use struct in that way for the sake of the language's own portability. :-) -- Yar