Date: Thu, 16 Nov 2006 16:52:07 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: yar@comp.chem.msu.su 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 Message-ID: <20061116.165207.1661914048.imp@bsdimp.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20061116090412.GB37133@comp.chem.msu.su>
Yar Tikhiy <yar@comp.chem.msu.su> writes:
: On Mon, Nov 13, 2006 at 10:19:58AM -0700, M. Warner Losh wrote:
: > :
: > : BTW, you are responsible for the __packed in <netinet/ip.h>. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061116.165207.1661914048.imp>