«

Stephen Sprunk <> writes:
[...]
> Reordering structure members is therefore a constraint violation, and
> any compiler that does it is non-compliant.

A "constraint violation" is an error in code. Errors in compilers are
just bugs.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Wed, 2012-01-18, Robert Wessel wrote:
> On 18 Jan 2012 17:03:55 GMT, Jorgen Grahn <grahn+>
> wrote:
>
>>On Thu, 2012-01-12, Keith Thompson wrote:
>>> Ian Collins <ian-> writes:
>>>> On 01/12/12 07:56 PM, Dr Nick wrote:
>>>>> Keith Thompson<kst-> writes:
>>>>>
>>>>>> The compiler will (in fact, it *must*) insert whatever padding is
>>>>>> necessary so that all the members can be accesssed correctly. It may or
>>>>>> may not insert more padding than it strictly needs to.
>>>>>>
>>>>>> The language standard guarantees that the first declared member is at
>>>>>> offset 0, and that all other members are at increasing offsets in the
>>>>>> order in which they're declared (the compiler can't rearrange
>>>>>> members).
>>>>>
>>>>> Does any compiler let you do this? I have done things where the order
>>>>> of a least some elements (usually the first or the last) matters, but
>>>>> it's rare.
>>>>
>>>> Let you do what? I didn't see anything optional in Keith's reply.
>>>
>>> Permit reordering of struct members, I presume. Plenty of C
>>> compilers have plenty of options that break standard compliance.
>>
>>But is it really breaking compliance?
>>
>> struct Foo {
>> int a;
>> char b;
>> int c;
>> char d;
>> };
>>
>>If the compiler lays these out as a-c-b-d, is that really something
>>which is observable using correct C code?
>>
>>I seem to recall (but I can be wrong) that the expression
>>&foo.b < &foo.d is not guaranteed to be meaningful, unlike e.g.
>>comparisons inside an array.

> It's also required that structures with common leading sections have
> the same in-storage layout.

Ok, that is enough reason for not allowing reordering. To me, the
real reason then seems to be to allow things like the POSIX struct
sockaddr/sockaddr_in/sockaddr_in6/... hack. I always assumed the
sockaddr stuff demanded stronger guarantees from the compiler than the
standard gives.

> Of course that's all subject to the as-if rule, if the compiler can
> determine that the program never looks at the ordering, or the
> compiler can fake it, it's allowed to do anything it wants under the
> covers, including omitting and reordering parts or all of the
> structure.

Yes, but that surely is rare. Most structs are not limited to one
translation unit.

I agree with whoever-it-was upthread: if it was allowed to do it, the
compiler could do a much better layout of my structs than I am willing
to do manually.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

In article <>,
Kaz Kylheku <> wrote:
>Reordering struct members would break all kinds of code, not all of which is
>ISO C mandated.

It would be a cool option though...

struct apple
{
char x;
double y;
};

struct vector
{
__rearrangeok
struct apple e[5];
};

->

struct vectorn
{
char exz[5];
double eyz[5];
};

(Joe keane) writes:

> In article <>,
> Kaz Kylheku <> wrote:
>>Reordering struct members would break all kinds of code, not all of which is
>>ISO C mandated.
>
> It would be a cool option though...

C++ has something a little like this. If you write "public:"
between each pair of members, then the compiler is allowed to
arrange them the members in any order, except that (based on a
quick reading, anyway) the first member declared still has to be
first.
--
"This is a wonderful answer.
It's off-topic, it's incorrect, and it doesn't answer the question."
--Richard Heathfield

On Thu, 2012-01-19, Robert Wessel wrote:
> On 19 Jan 2012 11:34:43 GMT, Jorgen Grahn <grahn+>
> wrote:
>
>>On Wed, 2012-01-18, Robert Wessel wrote:
....
>>> Of course that's all subject to the as-if rule, if the compiler can
>>> determine that the program never looks at the ordering, or the
>>> compiler can fake it, it's allowed to do anything it wants under the
>>> covers, including omitting and reordering parts or all of the
>>> structure.
>>
>>Yes, but that surely is rare. Most structs are not limited to one
>>translation unit.
>>
>>I agree with whoever-it-was upthread: if it was allowed to do it, the
>>compiler could do a much better layout of my structs than I am willing
>>to do manually.

> Perhaps not so rare - a common case occurs when a (small-ish)
> structure is passed to or returned from a function that gets inlined.
> In C++ you see that in a lot of implicitly generated temporaries. Two
> cases in particular I've seen are in some graphics code where a
> "point" or "pixel" structure was so treated, and in code with a
> "complex" structure for representing, *ahem*, complex numbers. Of
> course none of those examples would typically involve any alignment
> issues.

True, and that is a case where I assume the compiler does something
smart. I automatically assume that in C too, but perhaps that's due
to my C++ training.

[...]

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .