From owner-cvs-src@FreeBSD.ORG Mon Nov 13 19:06:04 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 F0B8316A49E; Mon, 13 Nov 2006 19:06:04 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from pittgoth.com (ns1.pittgoth.com [216.38.206.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0D7A43E32; Mon, 13 Nov 2006 19:04:24 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from localhost (ip70-177-190-239.dc.dc.cox.net [70.177.190.239]) (authenticated bits=0) by pittgoth.com (8.13.6/8.13.6) with ESMTP id kADJ3pV0018830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Nov 2006 14:03:52 -0500 (EST) (envelope-from trhodes@FreeBSD.org) Date: Mon, 13 Nov 2006 14:03:49 -0500 From: Tom Rhodes To: "M. Warner Losh" Message-Id: <20061113140349.0acfd25b.trhodes@FreeBSD.org> In-Reply-To: <20061113.101808.-1540392146.imp@bsdimp.com> References: <200611130428.kAD4ST0U093715@repoman.freebsd.org> <20061113173927.Q75708@delplex.bde.org> <20061113.101808.-1540392146.imp@bsdimp.com> Organization: The FreeBSD Project X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: jkoshy@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, bde@zeta.org.au, 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: Mon, 13 Nov 2006 19:06:05 -0000 On Mon, 13 Nov 2006 10:18:08 -0700 (MST) "M. Warner Losh" wrote: > In message: <20061113173927.Q75708@delplex.bde.org> > Bruce Evans writes: > : In , all struct members are char arrays so there will be no > : padding in practice. > > Actually, that isn't the case at all. There are many systems that > pad/align structs to 4 byte boundaries regardless. NetBSD has many of > these places tagged with __packed since they run on more architectures > than they can hand tweek for. > > : Most system headers depend on the padding being > : the same for all compilers, even when the struct member types are very > : varied. Many system headers use explicit manual padding to try to > : give a fixed layout. This works in practice, and the not-unused file > : system ffs and the not-unused networking component netinet depend on > : it working. Most file systems probably depend on it working across > : OS's for very varied struct types. One exception is msdosfs -- since > : msdosfs's disk data structures are poorly laid out even for an 8-bit > : system, they are almost perfectly misaligned even for a 16-bit system, > : so manual packing is not practical, and msdosfs declares most of the > : structures as byte arrays in much the same way as . It doesn't > : go as far as using a single array of bytes with fake struct members > : defined via offsets into the array, as might be required to be portable > : in theory. > > "almost" "in theory". These are nice words, but don't match reality. I think this is a fortune candidate. You are so quotesfiled Mr. Warner. ;) > On the arm, the __packed is absolutely required to not only compile, > but produce correct code. > This is a hardware thing correct? Admittedly so, I have no clue about ARM. -- Tom Rhodes