From owner-cvs-all@FreeBSD.ORG Fri Nov 17 06:56:08 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.ORG Delivered-To: cvs-all@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6BE716A415; Fri, 17 Nov 2006 06:56:08 +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 22D8543D46; Fri, 17 Nov 2006 06:56:06 +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 kAH6u2pg058694; Fri, 17 Nov 2006 09:56:03 +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 kAH6ttmQ058691; Fri, 17 Nov 2006 09:55:55 +0300 (MSK) (envelope-from yar) Date: Fri, 17 Nov 2006 09:55:55 +0300 From: Yar Tikhiy To: "M. Warner Losh" Message-ID: <20061117065555.GE49602@comp.chem.msu.su> References: <20061113214928.P76443@delplex.bde.org> <20061113.101958.-861030824.imp@bsdimp.com> <20061116090412.GB37133@comp.chem.msu.su> <20061116.165207.1661914048.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061116.165207.1661914048.imp@bsdimp.com> User-Agent: Mutt/1.5.9i 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-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 06:56:08 -0000 On Thu, Nov 16, 2006 at 04:52:07PM -0700, M. Warner Losh wrote: > 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. This is an oversimplification of the case. If it were so simple, no doubts about it would be raised. That's why I suggested adding a comment explaining that historically struct ip was lucky to be packed/aligned properly, but that wasn't backed by the C standard in fact, and eventually architectures appeared, e.g., ARM, which broke the false assumption. It's a rather edifying case. Then you'll have a smaller chance of having to yell in capital letters again, "DO NOT REMOVE IT. IT IS ABSOLUTELY REQUIRED FOR ARM TO WORK RIGHT." -- hopefully, not only regarding struct ip. -- Yar