structure layout question

[kyle york]

Greetings,

Why does the C standard require the members of a structure not be
re-ordered (6.2.5.20)? Padding is allowed, and platform dependent, which
means one cannot rely on the exact layout anyway, so what's the point?

Without this restriction the compiler could layout the structure in the
most efficient way possible, for some definition of efficient. It would
be easy enough to turn this reordering off with a compiler specific
pragma as is often done with padding.

--
Kyle A. York
Sr. Subordinate Grunt

[Doug]

On 1 Mar, 20:30, "Stephen Sprunk" <step...@sprunk .orgwrote:

"kyle york" <[e-mail] wrote in message

<snip>

The standard's wording guarantees that two structs defined with the same
initial elements will be laid out the same way in memory

<snip>

Ben, Walter,

I'm interested in your discussion about 'minimal' vs 'appropriate'
padding. If we accept Stephen's statement above (which I *think* is
true), then I think this means that there must be a canonical way to
lay out a structure.

If this canonical method is compiler-specific, then I guess
appropriate might not equal minimal.

But I read the standard to say that all compilers (on a given arch)
should lay the structure out in memory the same way (without use of
#pragma pack, etc.). (Thus I can use a 3rd party library without
caring about what it was compiled with.)

Putting this all together, surely that means that all compilers (on
the same arch) must share the same canonical method of laying out a
structure? If so, then surely 'minimal' is the only sensible way to
agree on that canonical method?

Or am I way off base?

Thanks,
Doug

[Malcolm McLean]

"kyle york" <ky***@cisco.co mwrote in message

Why does the C standard require the members of a structure not be
re-ordered (6.2.5.20)? Padding is allowed, and platform dependent, which
means one cannot rely on the exact layout anyway, so what's the point?

Without this restriction the compiler could layout the structure in the
most efficient way possible, for some definition of efficient. It would be
easy enough to turn this reordering off with a compiler specific pragma as
is often done with padding.

The rules are a hangover from the bad old days when people would play silly
games, like putting a header in from of a variable-sized array and defining
the whole thing as a struct with a zero length array as the last member.
The other favourite is a disambiguation field for packets.

With modern processors and modern programming conventions, it should not be
necessary to rely on the arrangement of structure elements in memory. As you
say, doing so is fraught with portability bugs. But legacy code needs to be
supported, which is more important than minor gains in efficiency you might
obtain by allowing the compiler to organise the elements itself.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Keith Thompson]

ro******@ibd.nr c-cnrc.gc.ca (Walter Roberson) writes:

In article <45************ **********@free .teranews.com>,
Stephen Sprunk <st*****@sprunk .orgwrote:

>>The standard's wording guarantees that two structs defined with the same
initial elements will be laid out the same way in memory and that, as long
as you access only common members, they will be interchangeable .

C89 makes that guarantee where the two structs are the common
prefix of a union encompassing both, but does C89 or C99 promise
it if not union is involved?

I don't believe so, but it's difficult to imagine an implementation
that would lay out the structs differently if there doesn't happen to
be a union declaration. The mythical DS9K probably does so, but the
compiler has to expend a lot of effort to prove that there is no union
declared anywhere in the scope of the two types; in some cases, it has
to postpone layout decisions until link time.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ian Collins]

Malcolm McLean wrote:

>
With modern processors and modern programming conventions, it should not
be necessary to rely on the arrangement of structure elements in memory.
As you say, doing so is fraught with portability bugs. But legacy code
needs to be supported, which is more important than minor gains in
efficiency you might obtain by allowing the compiler to organise the
elements itself.

No matter how modern the code is, the problem of disambiguation of
structures in a union remains.

--
Ian Collins.

[Keith Thompson]

"Doug" <Du****@blueyon der.co.ukwrites :

On 1 Mar, 20:30, "Stephen Sprunk" <step...@sprunk .orgwrote:

>"kyle york" <[e-mail] wrote in message

<snip>

>The standard's wording guarantees that two structs defined with the same
initial elements will be laid out the same way in memory

<snip>

Ben, Walter,

I'm interested in your discussion about 'minimal' vs 'appropriate'
padding. If we accept Stephen's statement above (which I *think* is
true), then I think this means that there must be a canonical way to
lay out a structure.

If this canonical method is compiler-specific, then I guess
appropriate might not equal minimal.

But I read the standard to say that all compilers (on a given arch)
should lay the structure out in memory the same way (without use of
#pragma pack, etc.). (Thus I can use a 3rd party library without
caring about what it was compiled with.)

Putting this all together, surely that means that all compilers (on
the same arch) must share the same canonical method of laying out a
structure? If so, then surely 'minimal' is the only sensible way to
agree on that canonical method?

Or am I way off base?

I'm afraid you are.

Having all compilers on a given architecture lay out structures in the
same way is (almost) certainly a good idea, and it might be required
by some architecture-specific standard. But the C standard itself
imposes no such requirement.

Realistically, there can even be good reasons for the layout to be
inconsistent; one compiler might optimize the layout for efficiency,
and another might optimize for compatibility with, say, some earlier
version of the same architecture. Interoperation of code compiled by
the two compilers would be difficult, but as I said the C standard
doesn't require it to be easy.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Eric Sosman]

Doug wrote On 03/01/07 16:24,:

On 1 Mar, 20:30, "Stephen Sprunk" <step...@sprunk .orgwrote:

>>"kyle york" <[e-mail] wrote in message

<snip>

>>The standard's wording guarantees that two structs defined with the same
initial elements will be laid out the same way in memory

<snip>

Ben, Walter,

I'm interested in your discussion about 'minimal' vs 'appropriate'
padding. If we accept Stephen's statement above (which I *think* is
true), then I think this means that there must be a canonical way to
lay out a structure.

If this canonical method is compiler-specific, then I guess
appropriate might not equal minimal.

But I read the standard to say that all compilers (on a given arch)
should lay the structure out in memory the same way (without use of
#pragma pack, etc.). (Thus I can use a 3rd party library without
caring about what it was compiled with.)

No, the C Standard has no concept of an "arch;" it talks
only about "implementation s." Every implementation must meet
the requirements of the Standard, but can do so in any way it
chooses. There is no guarantee (in the C Standard) that gcc
and Frobozz Magic C will make identical decisions, even if
they run on the same machine. There is no guarantee even
that a single compiler will make the same decisions when run
with different option flags! As far as the C Standard can
see, "gcc" and "gcc -fomit-frame-pointer" are two distinct
implementations , and need not be compatible.

That said, most platforms publish some kind of "Applicatio n
Binary Interface" that specifies some of the decisions that the
C Standard leaves unmade. If you're supposed to pass some kind
of struct to a system service, the struct must be laid out in
thus-and-such a way, and all compilers on that platform had
better toe the line. So the standard you mention usually does
exist -- except that it's not The Standard, and it may or may
not describe things in terms of language-specific constructs
like structs.

Putting this all together, surely that means that all compilers (on
the same arch) must share the same canonical method of laying out a
structure? If so, then surely 'minimal' is the only sensible way to
agree on that canonical method?

I don't see how "canonical" implies "minimal."

Or am I way off base?

I once saw a relief pitcher enter a baseball game and seal
the win without throwing even one pitch. The Red Sox were down
by two in the top of the ninth in Baltimore, with two out and a
man on base. Carlton Fisk singled, advancing the runner to
third and putting himself on first as the tying run. In came
the reliever to face the next batter, the potential go-ahead run.
He took his warm-up throws, got his sign from the catcher, and
threw to first to pick off Fisk and end the game.

He would *definitely* have had you flat-footed. ;-)

--
Er*********@sun .com

[Malcolm McLean]

"Ian Collins" <ia******@hotma il.comwrote in message

>

>With modern processors and modern programming conventions, it should not
be necessary to rely on the arrangement of structure elements in memory.
As you say, doing so is fraught with portability bugs. But legacy code
needs to be supported, which is more important than minor gains in
efficiency you might obtain by allowing the compiler to organise the
elements itself.

No matter how modern the code is, the problem of disambiguation of
structures in a union remains.

Generally you don't need unions.
A 256-byte packet arrives. Instead of trying to define the bit pattern with
a C union, you can take the first two bytes, switch on the type, and then
create the appropriate structure, reading that data packet one byte at a
time.
If you need a generic function, it accepts a void * together with some
information telling it what type of packet was received. That probably
entails a call to malloc() to receive the data, but that doesn't matter on a
modern system.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Ian Collins]

Malcolm McLean wrote:

>
"Ian Collins" <ia******@hotma il.comwrote in message

>>

>>With modern processors and modern programming conventions, it should not
be necessary to rely on the arrangement of structure elements in memory.
As you say, doing so is fraught with portability bugs. But legacy code
needs to be supported, which is more important than minor gains in
efficiency you might obtain by allowing the compiler to organise the
elements itself.

No matter how modern the code is, the problem of disambiguation of
structures in a union remains.

Generally you don't need unions.
A 256-byte packet arrives. Instead of trying to define the bit pattern
with a C union, you can take the first two bytes, switch on the type,
and then create the appropriate structure, reading that data packet one
byte at a time.
If you need a generic function, it accepts a void * together with some
information telling it what type of packet was received. That probably
entails a call to malloc() to receive the data, but that doesn't matter
on a modern system.

It sure does on the 'modern' 8 and 16 bit embedded devices I work with!

--
Ian Collins.

[Dave Vandervies]

In article <1172773547.747 71@news1nwk>,
Eric Sosman <Er*********@su n.comwrote:

Under certain conditions, different struct types
that share a "common initial subsequence" of elements
can be accessed through a pointer to either type, so
long as the accesses are to the common elements. That's
another useful property.

Aren't the condititions for that pretty much "You're not running it on
the DS9k"?
dave

--
Dave Vandervies dj******@csclub .uwaterloo.ca

Odd, that. My programs don't tend to make my computer systems fall over.
--Richard Heathfield in comp.lang.c

[Stephen Sprunk]

"Malcolm McLean" <re*******@btin ternet.comwrote in message
news:h-*************** *************** @bt.com...

Generally you don't need unions.
A 256-byte packet arrives. Instead of trying to define the bit
pattern with a C union, you can take the first two bytes, switch on
the type, and then create the appropriate structure, reading that
data packet one byte at a time.
If you need a generic function, it accepts a void * together with
some information telling it what type of packet was received.
That probably entails a call to malloc() to receive the data, but
that doesn't matter on a modern system.

A common technique for implementing inheritance in C is to have the first
element in a subclass be the superclass, or have the initial elements be
identical. That allows you to pass a "Tree" struct to a function that
expects a "Plant" struct with only a cast -- but only if the condition we're
discussing holds. Passing a Plant subclass in as a void* and enumerating
its type requires a function that only cares about the Plant parts to know
about every possible type of Plant subclass and a monstrous switch statement
that would cast the argument to one of potentially millions of different
types of Plants, just so it could access an element that _should_ be at the
same offset in all of them. That's just wasteful.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

--
Posted via a free Usenet account from http://www.teranews.com