Re: C struct Ordering Rules

daniels@cse.ogi.edu (Scott David Daniels)
Tue, 1 Nov 1994 23:14:46 GMT

          From comp.compilers

Related articles
CProf cache profiling system available david@cs.wisc.edu (1994-10-13)
Re: C struct Ordering Rules (Re: Data Structure Reorganizing Optimizat bart@cs.uoregon.edu (1994-10-27)
Re: C struct Ordering Rules bart@cs.uoregon.edu (1994-10-31)
Re: C struct Ordering Rules bbpy969@server4.bell-atl.com (1994-10-31)
Re: C struct Ordering Rules bill@amber.ssd.csd.harris.com (1994-11-01)
Re: C struct Ordering Rules daniels@cse.ogi.edu (1994-11-01)
Re: C struct Ordering Rules meissner@osf.org (1994-11-01)
| List of all articles for this month |

Newsgroups: comp.arch,comp.compilers
From: daniels@cse.ogi.edu (Scott David Daniels)
Keywords: C, design, optimize
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR
References: 94-10-108 94-10-160
Date: Tue, 1 Nov 1994 23:14:46 GMT

Andy Glew <glew@ichips.intel.com> wrote:
> I am aware of the K&R rule that structure elements be in increasing
> order of address....


bart@cs.uoregon.edu (Barton C. Massey) writes:
|> The guarantee that the ANSI C library macro offsetof() returns
|> increasing integers for structure element offsets is also
|> frequently used (mostly by converted K&R programs which used to
|> compute offsets directly). Section 3.5.4.2 of the ANSI
|> Rationale gives an example that mimics behavior of some real C
|> code I've seen:
|> struct xobj {
|> short tag;
|> short misc1;
|> int misc2;
|> char c[1];
|> } *mystructp = malloc( offsetof(struct xobj, c) + length );
|> If e.g. misc2 and c are swapped in this example, the malloc() size
|> becomes incorrect.


What I'd like to see is the following:
                Offsets are serially determined, and compatible. That is, the
offsets are determioned in order, and no subsequent field definition may
affect the previous mapping of field names to offsets. However, I'd let
the ``offsetof() returns increasing integers'' go by the wayside. Then we
could get relatively dense aligned structs without knowing the target machine
characteristics. So:
struct one { char a; long b; char c; char d; }
could have the same layout as:
struct two {char a; char c; char d; long b; }
It would simply mean that padding can be re-used for storage. This
means certain highly wierd assignments fail:
struct discriminator { char op; short size; }
struct opOne { char op; short size; char data; }
struct opTwo { char op; short size; long data; char key; }
A struct-assign to a variable of type "struct opTwo", even when assigning
as a "struct discriminator" will mangle ``key'' (an effect which cannot now
happen).


The big problem is the "struct hack" code that still exists. A kluge could
be introduced so that array-typed variables must appear at offsets greater
than all of the field offsets that precede them.


- Scott David Daniels
daniels@cse.ogi.edu
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.