structure address = structure first field address ?

[Barry Schwarz]

The compiler won't reorder members of a struct to reduce space wasted by
padding. If one is going to create millions of objects of some structure
type and wants to reduce padding in a portable way, he should order
members from largest to smallest, for example double, long long, pointers,
long, float, int, short, char.

That has nothing to do with whether you align the members yourself or
let the compiler do it.

 

[CBFalconer]

(e-mail address removed) (Kenny McCormack) wrote:
... snip ...

The way it is usually done is to put the padding *before* the
beginning of the struct - i.e., so that the struct is aligned
to the type of its first element.

The structure must be aligned and padding inserted as needed
everywhere except before the first member so that every member
is properly aligned.

Bear in mind that McCormack is an admitted troll. From the C
standard:

7.20.3 Memory management functions

[#1] The order and contiguity of storage allocated by
successive calls to the calloc, malloc, and realloc
functions is unspecified. The pointer returned if the
allocation succeeds is suitably aligned so that it may be
assigned to a pointer to any type of object and then used to
access such an object or an array of such objects in the
space allocated (until the space is explicitly freed or
reallocated). Each such allocation shall yield a pointer to
an object disjoint from any other object. The pointer
returned points to the start (lowest byte address) of the
allocated space. If the space cannot be allocated, a null
pointer is returned. If the size of the space requested is
zero, the behavior is implementation-defined: either a null
pointer is returned, or the behavior is as if the size were
some nonzero value, except that the returned pointer shall
not be used to access an object. The value of a pointer
that refers to freed space is indeterminate.

The original post asked about defining structures, not allocating
space.

The space allocated by malloc, and that allocated locally, or
statically, must be identical. Otherwise you couldn't pass around
arrays of things. The real point is that McCormack is a troll, and
is bent on disrupting c.l.c.

 

[CBFalconer]

but what he said made sense.

But is forbidden in the standard.

 

[CBFalconer]

One could consider it not padding if it's before the starting
address, since it's not really part of the object itself (not
within the range address to address+size). (just doing my part to
extend the rattle)

Of course there are, at present, 27 messages in this thread due to
McCormacks trolling.

 

[Barry Schwarz]

I take it you are retracting your words
"everywhere except before the first member"

Please don't top post.

On the contrary, there is never any padding before the first member of
a struct.

I'll retract mine about 100%

We can agree padded before first member (aligned) to longest basic type.

No we cannot. Even if you change "padded before first member" to
"padded before struct", it is still incorrect. We might agree if you
change "longest" to "strictest"

 

[Richard Tobin]

On the contrary, there is never any padding before the first member of
a struct.

[/QUOTE]

So now you claim a struct is not aligned. Interesting.

You are obviously having a problem with the concept of "before" and maybe are
limiting it in some unspecified manner.

Hint, see if the standard defines the word padding. It uses it in many places
to describe filler things and even describes as padding the filler used to get
alignment.

As far as I can see, it is used only to describe unused bits or bytes
within objects. An implementation may leave memory unused in order to
ensure alignment of a single struct, but that unused memory is not
part of any C object.

In any case, it's obvious that everyone who has said there is no
padding before the first member of a struct means, correctly, that
there is no padding *within the struct* before the first member.
There is no real dispute here, just an attempt to make people seem
wrong when they are in fact right.

-- Richard

 

[Barry Schwarz]

When I don't want to pad, I will.


So now you claim a struct is not aligned. Interesting.

As long as you want to stick stupid words in my mouth, since there is
usually not any padding in an int, I guess I'm also saying that an int
is not aligned either.

You are obviously having a problem with the concept of "before" and maybe are
limiting it in some unspecified manner.


Hint, see if the standard defines the word padding. It uses it in many places
to describe filler things and even describes as padding the filler used to get
alignment.

You mean like section 6.5.3.4-3 which says a structure may have
internal and trailing padding but specifically omits leading padding.
Or perhaps you mean 6.7.2.1-13 which says there may be unnamed padding
within a structure but not at its beginning.

 

[Dik T. Winter]

....
> Actually Kenny McCormack is 100% right.

Is he? Is a struct that starts with a char is indeed aligned to the type
char? No, he is wrong. (In general all structs are aligned the same,
regardless the type of the first element.)

 

[Keith Thompson]

Is he? Is a struct that starts with a char is indeed aligned to the
type char? No, he is wrong. (In general all structs are aligned
the same, regardless the type of the first element.)

No, all structs needn't be aligned the same, though an implementation
may choose to do so. For example, struct { char c; } may have a
size and alignment of 1 byte, while struct { int i; } may have a
size and alignment of, say, 4 bytes (or a size of 8 bytes and an
alignment of 2 bytes, or whatever).

You're probably thinking of 6.2.5p27:
[...] All pointers to structure types shall have the same
representation and alignment requirements as each other. All
pointers to union types shall have the same representation and
alignment requirements as each other. Pointers to other types need
not have the same representation or alignment requirements.

But that refers to the alignment of a pointer object, not to the
alignment of a struct or union object that it points to.

 

[Beej Jorgensen]

May be. They seem to limit before to only the case of within,
something I don't believe the OP stated.

The OP merely said:

OP> Does the C89/c90 language asserts that the address of a structure
OP> and the address of the first field of the structure are the same?

It's apparent that he's speaking "within the struct" and not before it.
And CBFalconer won the prize for "Most Concise Answer" right off the
line.

It's also apparent that all posters on this thread agree on where the
compiler can and cannot add padding in a struct. So why can't we all
just all get along?

-Beej

 

[Tony]

Why? Is it really worth the effort to do manually what the compiler
would have done for you?

Yes, as an aspiring compiler writer it does. Also, having complete control
of your code is important: read, the portability mantra is a white elephant
(or yet to be one). All those behind the scenes things the compiler does
get's annoying many times (moreso in C++, but there, one thing leads to
another and that makes it a big pill), and I have different goals for my
language that the C language has.

Tony

 

[Tony]

The compiler won't reorder members of a struct to reduce space wasted by
padding. If one is going to create millions of objects of some structure
type and wants to reduce padding in a portable way, he should order
members from largest to smallest, for example double, long long, pointers,
long, float, int, short, char.

I rather have control via a switch or pragma rather than "a portable way".

Tony