Date: Thu, 30 May 2002 01:53:00 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Tony Finch <dot@dotat.at> Cc: Jens Schweikhardt <schweikh@schweikhardt.net>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys gpt.h Message-ID: <20020530085259.GA8405@dhcp01.pn.xcllnt.net> In-Reply-To: <20020530091217.A10098@chiark.greenend.org.uk> References: <200205290258.g4T2wgF83137@freefall.freebsd.org> <9551.1022648961@critter.freebsd.dk> <20020529053653.GA306@dhcp01.pn.xcllnt.net> <20020529173621.B11817@chiark.greenend.org.uk> <20020529131927.C64995@kayak.xcllnt.net> <200205292027.g4TKRfnv031668@khavrinen.lcs.mit.edu> <20020529133846.E64995@kayak.xcllnt.net> <20020529233248.A24780@schweikhardt.net> <20020529230137.GA306@dhcp01.pn.xcllnt.net> <20020530091217.A10098@chiark.greenend.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 30, 2002 at 09:12:17AM +0100, Tony Finch wrote: > On Wed, May 29, 2002 at 04:01:37PM -0700, Marcel Moolenaar wrote: > > > > No, I assume that the compiler does do gratuitous padding, beyond > > what is reasonable or expected. Especially not to extend the size > > of the struct after the last field. > > C99 section 6.7.2.1 "Structure and union specifiers" paragraph 14: > "There may be unnamed padding at the end of a structure or union." > > I wonder how you expect C to work without this permission, given > that pointer arithmetic is defined in terms of the size of the > object pointed to, and given hard alighment requirements on some > machines. I wouldn't know either. I think that it simply worked as assumed, irrespective of whether the assumption was correct or not, and if you don't get (in this case) negative feedback early enough in your development, it turns into a blind spot. For example, I would write malloc(n * sizeof(foo)) and be amazed if it caused alignment traps while on the other hand I still prefer that the size of a struct is not to be adjusted to deal with the alignment of an object that follows it, be it the same struct. This clearly is an inconsistency that I like to resolve by blaming the malloc function and any other that suffers from the same problem :-) > (char *)(p + 1) == (char *)p + sizeof(*p) > p + 1 == &p[1] I would find it unsurprising when the first condition can fail, simply because it has explicit type casting and thus change the properties of the pointer. It's an intuitive failure. The LH expression says: "give me the next *p-aligned address", while the RH expression says: "give me the first char-aligned address after the struct". Anyway: I'm repeating myself and it won't make a difference; even if I'm right... > end of structs. Many implementations, especially on PCs which don't > have hard alignment requirements, won't have used the facility.) Yes, I think this is the crux and probably also why Intel has not defined the GPT structure to be a multiple of 8 bytes. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020530085259.GA8405>