Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > structure layout question

Reply
Thread Tools

structure layout question

 
 
kyle york
Guest
Posts: n/a
 
      03-01-2007
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
 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      03-01-2007
In article <(E-Mail Removed)>,
kyle york <(E-Mail Removed)> wrote:

>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?


As best I recall, arbitrary padding is not permitted: only
where required to bring the entry into alignment (where alignment
rules are platform dependant.) So if you know the alignment rules
for (say) a "pure" double, then you also know the alignment
rules for a double embedded in a struct.

In any case, take the structure and wrap it around with a union,
the other member of which is an array of unsigned char. This is
a legal way to get at the bytes that make up the structure without
worrying about trap representations, and there are scenarios you
can construct where the alignment rules provide guarantees about
what will be where in the unsigned char array that wouldn't be met
if reordering was possible. For example, take the offset of a
member that was known to be followed by a char. char is the most
general alignment, so you know it followed -immediately- after the
end of the member. You know the size of the member via sizeof.
So the unsigned char array indexed at the offset of the member,
plus the sizeof the member, is certain to get you to the beginning of
that char -- but if you'd reordered the elements, the char could
be anywhere relative to the member in question.


>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.


And it would be easy enough for a compiler to provide a pragma to
pack efficiently, possibly breaking ordering or possibly requiring
slow movements in and out of internal char buffers if the architecture
doesn't support "move unaligned". You could call it something wild such
as ... ummm, say, #pragma pack
--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      03-01-2007
kyle york wrote On 03/01/07 13:06,:
> 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.


The first element of a struct must come first, and
must be preceded by no padding. This allows a struct
pointer to be converted to a pointer to the struct's
first element and vice versa, which is a useful property.

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.

A struct is often not just a bag of related elements,
but also a description of a "published" format. For
example, an image file that starts with a "magic number"
followed by version numbers followed by ... may well be
described by a struct. There are portability issues
with such usages, but they are useful nonetheless.

--
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Ben Pfaff
Guest
Posts: n/a
 
      03-01-2007
http://www.velocityreviews.com/forums/(E-Mail Removed)-cnrc.gc.ca (Walter Roberson) writes:

[in a struct]
> As best I recall, arbitrary padding is not permitted: only
> where required to bring the entry into alignment (where alignment
> rules are platform dependant.) So if you know the alignment rules
> for (say) a "pure" double, then you also know the alignment
> rules for a double embedded in a struct.


This is a nice theory, but I can't see how to back it up with a
quote from the standard. The text of the standard says "There
may be unnamed padding within a structure object, but not at its
beginning." and I don't see any restrictions on that.
--
"I ran it on my DeathStation 9000 and demons flew out of my nose." --Kaz
 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      03-01-2007
In article <(E-Mail Removed)>,
Ben Pfaff <(E-Mail Removed)> wrote:
>(E-Mail Removed)-cnrc.gc.ca (Walter Roberson) writes:


>[in a struct]
>> As best I recall, arbitrary padding is not permitted: only
>> where required to bring the entry into alignment (where alignment
>> rules are platform dependant.) So if you know the alignment rules
>> for (say) a "pure" double, then you also know the alignment
>> rules for a double embedded in a struct.


>This is a nice theory, but I can't see how to back it up with a
>quote from the standard. The text of the standard says "There
>may be unnamed padding within a structure object, but not at its
>beginning." and I don't see any restrictions on that.


There is a bit more wording that that in C89 3.5.2.1:

Each non-bit-field member of a structure or union object is
aligned in an implementation- defined manner appropriate to its type.

Within a structure object, the non-bit-field members and the units
in which bit-fields reside have addresses that increase in the order
in which they are declared. A pointer to a structure object,
suitably converted, points to its initial member (or if that
member is a bit-field, then to the unit in which it resides), and
vice versa. There may theefore be unnamed padding within a
structure object, but not at its beginning, as necessary to achieve the
appropriate alignment.


Notice that the alignment within the structure is in a manner
"appropriate to its type". I interpret that as the alignment
appropriate to the type "ex-vivo", outside of structure. I do not
see anything there that would suggest that a member could have one
alignment within structures and a different alignment outside of
structures.

Notice the padding is not "for arbitrary purposes", but only
"as necessary to achieve the appropriate alignment".

I only apply this hypothesis to the padding -inside- the structure,
and not to any "trailing" padding of the structure. For example,
the classic struct {int i; char c;} might have trailing padding
so that you can form effecient arrays of such elements.
--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell
 
Reply With Quote
 
Ben Pfaff
Guest
Posts: n/a
 
      03-01-2007
(E-Mail Removed)-cnrc.gc.ca (Walter Roberson) writes:

> In article <(E-Mail Removed)>,
> Ben Pfaff <(E-Mail Removed)> wrote:
>>(E-Mail Removed)-cnrc.gc.ca (Walter Roberson) writes:

>
>>[in a struct]
>>> As best I recall, arbitrary padding is not permitted: only
>>> where required to bring the entry into alignment (where alignment
>>> rules are platform dependant.) So if you know the alignment rules
>>> for (say) a "pure" double, then you also know the alignment
>>> rules for a double embedded in a struct.

>
>>This is a nice theory, but I can't see how to back it up with a
>>quote from the standard. The text of the standard says "There
>>may be unnamed padding within a structure object, but not at its
>>beginning." and I don't see any restrictions on that.

>
> There is a bit more wording that that in C89 3.5.2.1:
>
> Each non-bit-field member of a structure or union object is
> aligned in an implementation- defined manner appropriate to its type.
>
> Within a structure object, the non-bit-field members and the units
> in which bit-fields reside have addresses that increase in the order
> in which they are declared. A pointer to a structure object,
> suitably converted, points to its initial member (or if that
> member is a bit-field, then to the unit in which it resides), and
> vice versa. There may theefore be unnamed padding within a
> structure object, but not at its beginning, as necessary to achieve the
> appropriate alignment.
>
> Notice that the alignment within the structure is in a manner
> "appropriate to its type". I interpret that as the alignment
> appropriate to the type "ex-vivo", outside of structure. I do not
> see anything there that would suggest that a member could have one
> alignment within structures and a different alignment outside of
> structures.


Interesting, I hadn't noticed that nuance.

But I don't think that "appropriate to its type" means that there
couldn't be more padding than necessary, or that it must be the
same padding as outside an structure.

> Notice the padding is not "for arbitrary purposes", but only
> "as necessary to achieve the appropriate alignment".


The sentence "There may therefore..." was changed in C99 to
"There may be unnamed padding within a structure object, but not
at its beginning." (as I quoted earlier), which may indicate a
change in requirements by the Standard. (But I do not know.)
--
"I ran it on my DeathStation 9000 and demons flew out of my nose." --Kaz
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      03-01-2007
Walter Roberson wrote On 03/01/07 14:17,:
> [concerning "excessive" padding in structs]
>
> Notice the padding is not "for arbitrary purposes", but only
> "as necessary to achieve the appropriate alignment".


I don't think "appropriate" implies "minimal." The
Rationale gives some hints as to how the authors wanted
these passages understood:

3.5.2.1 Structure and union specifiers
...
Since some existing implementations, in the interest
of enhanced access time, leave internal holes larger
than absolutely necessary, [...]

(As the section number indicates, this is from the original
ANSI C Rationale and not from a more recent ISO version. The
text might therefore be considered "closer" to the original
authors' thinking on the matter.)

--
(E-Mail Removed)
 
Reply With Quote
 
Stephen Sprunk
Guest
Posts: n/a
 
      03-01-2007
"kyle york" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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 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. It also
means that any later elements that are not common will be laid out _after_
the common ones, not interspersed with the common ones.

If a compiler was allowed to reorder the elements, these properties would
not hold and a lot of code would break.

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

 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      03-01-2007
Stephen Sprunk wrote:
> "kyle york" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>>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 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. It also
> means that any later elements that are not common will be laid out _after_
> the common ones, not interspersed with the common ones.
>
> If a compiler was allowed to reorder the elements, these properties would
> not hold and a lot of code would break.
>

Just to add to this, the above guarantee is important where structures
are members of a union and the first member or members are used to
identify the appropriate type. One example of this is the X-windows
event object which is a union of all possible event structs.

--
Ian Collins.
 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      03-01-2007
In article <45e72c57$0$6303$(E-Mail Removed)>,
Stephen Sprunk <(E-Mail Removed)> wrote:

>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?
--
All is vanity. -- Ecclesiastes
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Choosing Layout: Css-Layout or Table-Layout hpourfard@gmail.com ASP .Net 1 06-19-2006 10:06 AM
Question about css structure and layout Bill HTML 2 04-10-2006 12:41 PM
CSS Layout question - how to duplicate a table layout with CSS Eric ASP .Net 4 12-24-2004 04:54 PM
Converting from grid layout to flow layout. RobertH ASP .Net 1 11-04-2003 12:43 AM
DataList inside a Grid Layout Panel (<DIV>) item layout problem Rick Spiewak ASP .Net 3 08-26-2003 04:22 AM



Advertisments