From owner-cvs-src@FreeBSD.ORG Thu Nov 16 23:53:53 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.ORG Delivered-To: cvs-src@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2A7D16A403; Thu, 16 Nov 2006 23:53:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA62B43D6B; Thu, 16 Nov 2006 23:53:48 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kAGNpSur019031; Thu, 16 Nov 2006 16:51:29 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 16 Nov 2006 16:52:07 -0700 (MST) Message-Id: <20061116.165207.1661914048.imp@bsdimp.com> To: yar@comp.chem.msu.su From: "M. Warner Losh" In-Reply-To: <20061116090412.GB37133@comp.chem.msu.su> References: <20061113214928.P76443@delplex.bde.org> <20061113.101958.-861030824.imp@bsdimp.com> <20061116090412.GB37133@comp.chem.msu.su> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 16 Nov 2006 16:51:30 -0700 (MST) Cc: src-committers@FreeBSD.ORG, bde@zeta.org.au, jkoshy@FreeBSD.ORG, cvs-all@FreeBSD.ORG, phk@phk.freebsd.dk, cvs-src@FreeBSD.ORG 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: Thu, 16 Nov 2006 23:53:53 -0000 In message: <20061116090412.GB37133@comp.chem.msu.su> Yar Tikhiy writes: : On Mon, Nov 13, 2006 at 10:19:58AM -0700, M. Warner Losh wrote: : > : : > : BTW, you are responsible for the __packed in . Please remove : > : it. The __CTASSERT() is enough to detect if heroic packing is ever needed. : > : The only danger is if something has grown to depend on __packed reducing : > : alignment as a side effect. E.g., suppose we had a byte string containing : > : a bytewise copy of a struct ip. If the copy might be misaligned, then it : > : should be copied to an actual struct ip before accessing it as a struct, : > : but code that accesses it directly using ((struct ip *)&bs[N]) would work : > : now due to the reduced alignment. Places that really need __packed should : > : probably use __aligned() to restore the natural alignment. : > : > DO NOT REMOVE IT. IT IS ABSOLUTELY REQUIRED FOR ARM TO WORK RIGHT. : > If you want to remove it, then you must make sure arm works right : > after it because I'll add it back. : : Many years ago I was taught that comments in code could help to : avoid such clashes in software development. Is this true no more? ;-) You don't add comments like: i++; // Add one to i. This is a similar class. It is for any compiler that has differing alignment requirements than i386. Warner