size_t in a struct

[Dave Thompson]

On 17 Sep 2006 16:30:39 -0700, "Snis Pilbor" <[email protected]>
wrote:

Hmm, this is all very surprising to me: why on earth should the
structure layout depend on the order of the elements in the source? Is
there any reason to do this? Why don't compilers automatically
minimize the size of the structure, that seems like a no-brainer to me?

Because back around 1970 when C was designed, people didn't much
distinguish between "layout of several concrete things in more-or-less
adjacent memory" (like COBOL) and "abstract collection of several
things like a mathematical tuple" and by the time people did start
doing so lots of C implementations and particularly lots of C code
assumed the former and it was judged too late to change.

Languages created more recently, like Ada, or which added struct types
more recently, like Fortran, go (by default) with the latter.
Effectively so do languages that don't have any concrete memory access
at all, like java and perl. I don't remember which way Pascal went;
OT1H Wirth usually likes abstraction, OTOH he likes simplicity and
always doing the same thing the same way -- and he does have variant =
overlaid record parts which can make concrete memory visible, though
not officially or portably.

FWIW C++ compromises(?) by allowing reordering _only_ across access
specifiers in the class (or struct) definition, of which there are
never any in C or in the "not-quite-exactly-C-like" subset of C++.
I don't know of any implementation that has taken advantage of this.

Actually even a C compiler could reorder -- or split apart -- struct
elements under the as-if rule if it can look at all or enough of the
code to make sure none of it depends on the Standard order. This is
usually called InterProcedure Optimization or Whole-Program Analysis
or Optimization. There are periodically reports that certain compilers
do so for (at least?) certain important benchmark codes.

- David.Thompson1 at worldnet.att.net

 

[bwaichu]

Actually even a C compiler could reorder -- or split apart -- struct
elements under the as-if rule if it can look at all or enough of the
code to make sure none of it depends on the Standard order. This is
usually called InterProcedure Optimization or Whole-Program Analysis
or Optimization. There are periodically reports that certain compilers
do so for (at least?) certain important benchmark codes.

From gcc-local(1)

"On OpenBSD, gcc comes with the ``ProPolice'' stack protection exten-
sion, which is enabled by default. This extension reorders local
variable declarations and adds stack consistency checks at run time,
in order to detect stack overflows . . ."

Is there a way to determine the ordering that ProPolice makes to my
local variables?
</OT>

Thanks!

 

[Keith Thompson]

"On OpenBSD, gcc comes with the ``ProPolice'' stack protection exten-
sion, which is enabled by default. This extension reorders local
variable declarations and adds stack consistency checks at run time,
in order to detect stack overflows . . ."

Is there a way to determine the ordering that ProPolice makes to my
local variables?
</OT>

That talks about reordering local variables (which is perfectly
permissible in standard C), not reordering struct members (which
isn't).

 

[Mark L Pappin]

(I personally wouldn't mind if the compiler were allowed to
rearrange structure members arbitrarily, with an optional directive
to require them to be laid out in declared order, but that's not
what the standard says.)

A couple of weeks ago I encountered a scenario[0] where such
rearrangement might be handy:

- a "structure" is copied, field-by-field, to another similar
"structure", but with one field of different size and modified during
this copy, with the destination not referenced before the copy and the
source not referenced after;

- for clarity-of-documentation the different-sized field is declared
first in these "structures" and the common fields are declared last,
but there's nothing in the code that cares;

- if the compiler was allowed to rearrange things it could potentially
optimize away the copy by overlapping the allocation of space for
these two objects, with only the different-sized field needing to
actually be manipulated at all.

I thought "Wouldn't it be nice if (TM) we had a more-amorphous
aggregation tool than 'struct', that could give all these fields
no-overlapping but otherwise unconstrained offsets?" 'unstruct' has a
certain ring to it, as does 'bag', but they're not going to happen in
something that can call itself a C compiler. :-( Maybe 'restrict
struct' could work, though.

mlp

[0] conversion between different-precision numeric types, for an
implementation of the built-in types on tiny 8-bitters where cycles
are scarce, and multibyte integer or any FP operations scarcer