From owner-freebsd-current Mon Jul 15 15:12:17 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 061C637B400 for ; Mon, 15 Jul 2002 15:12:12 -0700 (PDT) Received: from rhymer.cogsci.ed.ac.uk (rhymer.cogsci.ed.ac.uk [129.215.144.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id E52C343E4A for ; Mon, 15 Jul 2002 15:12:10 -0700 (PDT) (envelope-from richard@cogsci.ed.ac.uk) Received: (from richard@localhost) by rhymer.cogsci.ed.ac.uk (8.9.3/8.9.3) id XAA12604; Mon, 15 Jul 2002 23:12:08 +0100 (BST) Date: Mon, 15 Jul 2002 23:12:08 +0100 (BST) Message-Id: <200207152212.XAA12604@rhymer.cogsci.ed.ac.uk> From: Richard Tobin Subject: Re: different packing of structs in kernel vs. userland ? To: Terry Lambert In-Reply-To: Terry Lambert's message of Mon, 15 Jul 2002 14:16:59 -0700 Organization: just say no Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > If everyone could read the text past my example of bad math, so > that they could know it was an intentional example of bad math, > live would be beautiful. 8-). I did read past it, and I just read it again, and I can't make it come out any way other than it did the first time. You said: > He's making the valid point that for: > > struct foo *fee; > > It's possible that: > > sizeof(struct foo) != (((char *)&fee[1]) - ((char *)&fee[0])) > > because of end-padding, which is not accounted for in arrays, It is not a valid point that it's possible that sizeof(struct foo) != (((char *)&fee[1]) - ((char *)&fee[0])) because it isn't possible. It must be the case that sizeof(struct foo) == (((char *)&fee[1]) - ((char *)&fee[0])) If that's what you meant, you seem to be saying the opposite. > and that inter-structure padding depends on ordering of elements Yes, though it isn't "inter-structure" padding, it's padding that is part of the structure. > (for a good example of this, see the struct direct name element > reference macro, which is also padding independent). Not sure which macro you mean here, since there are several variants of it which work in different ways. The one in dirent.h (I'm looking at 4.6 here) subtracts from sizeof, while the one in ufs/dir.h uses &(0->d_name) which is equivalent to offsetof. > Basically, end-padding happens because arrays of structures need to > have their first element properly aligned, so there is a pad added > after each element to ensure that the following element starts on > an alignment boundary. The point is that there isn't a pad *after* each element. The pad is part of the element, and is there regardless of whether the structure is in an array. Again, if that's what you meant you seem to be saying the opposite! -- Richard To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message