Re: C struct Ordering Rules (Re: Data Structure Reorganizing Optimizations)

bart@cs.uoregon.edu (Barton C. Massey)
Thu, 27 Oct 1994 04:18:48 GMT

          From comp.compilers

Related articles
CProf cache profiling system available david@cs.wisc.edu (1994-10-13)
Data Structure Reorganizing Optimizations [Was: Re: CProf cache profil glew@ichips.intel.com (1994-10-19)
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)
| List of all articles for this month |
Newsgroups: comp.arch,comp.compilers
From: bart@cs.uoregon.edu (Barton C. Massey)
Keywords: C, design, optimize
Organization: University of Oregon Computer and Information Sciences Dept.
References: 94-10-108 94-10-141
Date: Thu, 27 Oct 1994 04:18:48 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. But, since the contiguity requirement has been
> dropped, and since different machines have different padding rules,
> what value does the address ordering rule have? Even network header
> code cannot be written portably using structures to access data
> structures placed in memory from DMA devices.


One popular C programming technique is to "know" that the first
element of a structure begins at offset 0 in the structure, and
to thus convert the structure pointer into a pointer to the
first field, e.g.,
int tag = * (int *) mystructp;
This trick is typically used to simulate dynamically typed
structures: the first field is typically a tag indicating what
type the structure is. However, the ANSI restriction that "a
pointer to a structure offset, suitably converted, points to
its initial member" is sufficient to enforce this condition.


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.


All this said, I too would like to see field rearrangement.
There's several possibilities: my favorite suggestion is to
forbid rearrangement to move fields past non-volatile fields
(i.e. treat them as tombstones), and to force volatile structs
to be completely unpadded and in order (possibly necessitating
structure packing and unpacking across assignment).


Thus,
volatile struct device_regs {
short cmd;
short dummy;
int result;
} * volatile p;
gives a poiner to a structure guaranteed to map onto the device
registers correctly. The results of violating alignment
restrictions in the declaration are undefined, and a warning
will be given.


The previous examples are taken care of via
struct xobj {
volatile short tag;
short misc1;
int misc2;
volatile char c[1];
} *mystructp = malloc( offsetof(struct xobj, c) + length );
An implementation would be free to swap misc1 and misc2,
but must keep tag at the beginning and c at the end.


There's probably some bugs in here, but you get the idea...


Bart Massey
bart@cs.uoregon.edu
--


Post a followup to this message

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