Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: Walter Banks Newsgroups: comp.std.c Subject: Re: Structure Packing. Date: Tue, 12 Jun 2012 11:51:58 -0400 Organization: Aioe.org NNTP Server Lines: 62 Message-ID: <4FD7659E.89172310@bytecraft.com> References: <12b3df42-f6a0-4411-a5e5-136900f8255b@googlegroups.com> <4FD6ABFA.72F52C75@bytecraft.com> NNTP-Posting-Host: nbZIcP9ujGt3Z7oU6KK4Bg.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org X-Mailer: Mozilla 4.79 [en]C-CCK-MCD NSCPCD479 (Windows NT 5.0; U) X-Accept-Language: en X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.std.c:1367 Eric Sosman wrote: > > A current compiler project I am working on potentially has a completely different twist on struct placement. > > > > There is quite a list of hardware based alignment requirements based on boundaries. It is a RAM poor processor and I am being very > > tempted to assign global variables in the holes left behind in global structs. My guess the need for RAM space will outweigh other > > considerations. > > Don't do it: Operations on the named elements of a struct are > not guaranteed to preserve the contents of the holes. For example > > struct s { > unsigned char flag; > // possible hole here > unsigned int value; > } x; > unsigned char *hole = &x.flag + 1; > size_t hole_size = (unsigned char*)&x.value - hole; > if (hole_size > 0) *hole = 0xFF; > flag = 42; > if (hole_size > 0) assert(*hole == 0xFF); // may fail > > struct s y = x; > assert(memcmp(&x, &y, sizeof x) == 0); // may fail > > If you need the variable, give it a name and make it an ordinary > struct element. > > If you're worried about different alignments on different > systems and it's difficult to find one arrangement that works > efficiently for all, consider generating system-specific struct > definitions from a data file during your build process. You can > then give each system its own arrangement of the struct elements > to pack things as efficiently as possible. (Of course, this won't > work for struct elements that "must be first" or "must appear in > such-and-such order" -- but if memory scarcity is extreme, that > sacrifice may be worthwhile.) Your points are well taken. I have resolved every issue in this specific processor except memcpy and memcmp both of which are rarely used in embedded systems. I am not worried about different alignments on different processors. In this specific case first fit in a struct allocation is significantly tighter allocation than next available that will fit. I am uncomfortable even with packing the struct elements out of order. I am about to re-write the struct allocator (within the next day or two) and probably will at least use first fit in the struct or perhaps a tetris style packer. At that point I will see what hole metrics come out of a bunch of regression tests with actual application code. Thanks for the comments w..