Hello,

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

Tnaks for your replies and your time

Vincent De Groote

Vincent De Groote wrote:
> Hello,
> 
> Does the C89/c90 language asserts that the address of a structure and
> the address of the first field of the structure are the same ?

     Yes.  More precisely, it states that you can convert
a pointer to the struct to a pointer of the first element's
type and use it to access the first element, or you can
convert a pointer to the first element to the struct's
type and use it to access the struct.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

Vincent De Groote wrote:
> Hello,
>
> Does the C89/c90 language asserts that the address of a structure and
> the address of the first field of the structure are the same ?

The standard guarantees that "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 be unnamed
padding within a structure object, but not at its
beginning." (6.7.2.1p13)

On Thu, 30 Apr 2009 00:15:37 +0200, Vincent De Groote wrote:
> Hello,
> 
> Does the C89/c90 language asserts that the address of a structure and
> the address of the first field of the structure are the same ?

Hi Vincent,

I think I can answer this one... No, I dont believe it does, because there
can be "padding bytes" inserted between fields of a struct, also at the
beginning and the end.

E.g. if the first field is a char and the second field is an int, the
compiler will fill out the struct so that the char is one of the bytes
in a full dword (or qword on 64bit) - and it could be any one of the bytes
(which one may depend on endianness of the machine?? but that's just a
guess).

Cheers,
Joe


-- 
       ......................  o    _______________           _,
      ` Good Evening!  ,      /\_  _|             |        .-'_|
      `................,     _\__`[_______________|       _| (_|
                             ] [ \, ][         ][        (_|

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

>I think I can answer this one... No, I dont believe it does, because there
>can be "padding bytes" inserted between fields of a struct, also at the
>beginning and the end.

No, there may not be padding at the beginning.  There may be padding
between fields, or at the end.

Vincent De Groote wrote:
> 
> Does the C89/c90 language asserts that the address of a structure
> and the address of the first field of the structure are the same ?

Yes.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

kid joe <spamtrap@spamtrap.invalid> writes:
> On Thu, 30 Apr 2009 00:15:37 +0200, Vincent De Groote wrote:
>> Does the C89/c90 language asserts that the address of a structure and
>> the address of the first field of the structure are the same ?
>
> I think I can answer this one... No, I dont believe it does, because there
> can be "padding bytes" inserted between fields of a struct, also at the
> beginning and the end.
[...]

No, that's incorrect.  The standard very specifically does *not*
permit padding before the first member of a struct.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On Wed, 29 Apr 2009 18:16:12 -0700, Keith Thompson wrote:
> kid joe <spamtrap@spamtrap.invalid> writes:
>> On Thu, 30 Apr 2009 00:15:37 +0200, Vincent De Groote wrote:
>>> Does the C89/c90 language asserts that the address of a structure and
>>> the address of the first field of the structure are the same ?
>>
>> I think I can answer this one... No, I dont believe it does, because there
>> can be "padding bytes" inserted between fields of a struct, also at the
>> beginning and the end.
> [...]
> 
> No, that's incorrect.  The standard very specifically does *not*
> permit padding before the first member of a struct.

Hi Keith,

Thanks for the correction.

I find that strange... if I was a compiler writer on an endianness where
the least-significant byte was at the top end of the word, my thought to
implement a struct with char followed by int, Id allocate a whole dword
for the char, just do native-width integer operations on the dword, then
access and set the char through an 0xFF mask. But it sounds like that
wouldnt be standards-compliant.

Cheers,
Joe


-- 

       ......................  o    _______________           _,
      ` Good Afternoon! ,      /\_  _|             |        .-'_|
      `................,     _\__`[_______________|       _| (_|
                             ] [ \, ][         ][        (_|

In article <gteqma$eev$1@aioe.org>, kid joe  <spamtrap@spamtrap.invalid> wrote:
....
>Hi Keith,
>
>Thanks for the correction.

Please, sir.  Could I have some more?

>I find that strange... if I was a compiler writer on an endianness where
>the least-significant byte was at the top end of the word, my thought to
>implement a struct with char followed by int, Id allocate a whole dword
>for the char, just do native-width integer operations on the dword, then
>access and set the char through an 0xFF mask. But it sounds like that
>wouldnt be standards-compliant.

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.

In article <gteqma$eev$1@aioe.org>, kid joe  <spamtrap@spamtrap.invalid> wrote:
>On Wed, 29 Apr 2009 18:16:12 -0700, Keith Thompson wrote:

>I find that strange... if I was a compiler writer on an endianness where
>the least-significant byte was at the top end of the word,

.... and where there was no equally efficient instruction for accessing
the high-order byte...

>my thought to
>implement a struct with char followed by int, Id allocate a whole dword
>for the char, just do native-width integer operations on the dword, then
>access and set the char through an 0xFF mask. But it sounds like that
>wouldnt be standards-compliant.

Correct.  C's rules do not always permit the most efficient layout of
data.  But there are other considerations in standardisation, such as
existing programs that rely on being able to convert the address of
a structure to the address of its first member.

Your case is probably not a common one.

-- Richard
-- 
Please remember to mention me / in tapes you leave behind.

kid joe wrote:
[...]
> I find that strange... if I was a compiler writer on an endianness where
> the least-significant byte was at the top end of the word,

Nit-pick: The least-significant byte is ALWAYS at the bottom of a word, by
definition; the bottom of a word is the right-most portion, when it's
represented in the usual form with least significant bits on the right.

The beginning and end of a word usually refers to the representation in
memory, also "first byte", "last byte".

On Fri, 1 May 2009 13:26:43 +0000 (UTC), gazelle@shell.xmission.com
(Kenny McCormack) wrote:

>In article <gteqma$eev$1@aioe.org>, kid joe  <spamtrap@spamtrap.invalid> wrote:
>...
>>Hi Keith,
>>
>>Thanks for the correction.
>
>Please, sir.  Could I have some more?
>
>>I find that strange... if I was a compiler writer on an endianness where
>>the least-significant byte was at the top end of the word, my thought to
>>implement a struct with char followed by int, Id allocate a whole dword
>>for the char, just do native-width integer operations on the dword, then
>>access and set the char through an 0xFF mask. But it sounds like that
>>wouldnt be standards-compliant.
>
>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.

-- 
Remove del for email

Barry Schwarz wrote:
> gazelle@shell.xmission.com (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.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

On Fri, 01 May 2009 21:07:35 -0400, CBFalconer <cbfalconer@yahoo.com>
wrote:

>Barry Schwarz wrote:
>> gazelle@shell.xmission.com (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.

-- 
Remove del for email

On 2 May, 02:07, CBFalconer <cbfalco...@yahoo.com> wrote:
> Barry Schwarz wrote:
> > gaze...@shell.xmission.com (Kenny McCormack) wrote:


> >> 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. =A0From the C
> standard:

but what he said made sense.

<snip big chunk of boiler-plate standardese>

someone wrote:

> On 2 May, 02:07, CBFalconer <cbfalco...@yahoo.com> wrote:
>> Barry Schwarz wrote:
>> > gaze...@shell.xmission.com (Kenny McCormack) wrote:
> 
>> >> 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:
> 
> but what he said made sense.

I hope you are referring to Barry's statement, not to Kenny's.

-- Ralf

kid joe wrote:
> On Thu, 30 Apr 2009 00:15:37 +0200, Vincent De Groote wrote:
>> Hello,
>>
>> Does the C89/c90 language asserts that the address of a structure and
>> the address of the first field of the structure are the same ?
>
> Hi Vincent,
>
> I think I can answer this one... No, I dont believe it does, because
> there can be "padding bytes" inserted between fields of a struct,
> also at the beginning and the end.
>
> E.g. if the first field is a char and the second field is an int, the
> compiler will fill out the struct so that the char is one of the bytes
> in a full dword (or qword on 64bit) - and it could be any one of the
> bytes (which one may depend on endianness of the machine?? but that's
> just a guess).

I rely on the fact that the compiler gives some kind of padding/alignment 
control, either via pragmas or commandline/IDE switches. I pretty much 
byte-align everything (with the switch) and do "manual alignment" when 
designing structs (not as hard as it sounds). The only real "gotcha" to 
watch out for is pointer fields for their width is different on 32- and 
64-bit platforms (put pointers at the top of the struct and subsequent field 
will align nicely). I always use width-specified integral types.

"Tony" <tony@my.net> writes:
[...]
> I rely on the fact that the compiler gives some kind of padding/alignment 
> control, either via pragmas or commandline/IDE switches. I pretty much 
> byte-align everything (with the switch) and do "manual alignment" when 
> designing structs (not as hard as it sounds). The only real "gotcha" to 
> watch out for is pointer fields for their width is different on 32- and 
> 64-bit platforms (put pointers at the top of the struct and subsequent field 
> will align nicely). I always use width-specified integral types.

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

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Barry Schwarz wrote:
> Kenny McCormack wrote:
> >kid joe wrote:
[...]
> >>I find that strange... if I was a compiler writer on an endianness where
> >>the least-significant byte was at the top end of the word, my thought to
> >>implement a struct with char followed by int, Id allocate a whole dword
> >>for the char, just do native-width integer operations on the dword, then
> >>access and set the char through an 0xFF mask. But it sounds like that
> >>wouldnt be standards-compliant.
> >
> >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.

Any padding of this sort is made invisible by giving you the address of
the first member. This is because such padding depends on the particular
object, for example one automatic object might need the padding, while
another doesn't, while all heap-based ones don't need it (as malloc itself
aligns things for you, and gives you an aligned pointer, again for the
same reason).

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

In a sense, padding to align the first member is inserted at the END of
the structure, since that affects the alignment of the first member of the
NEXT structure in an array.

Keith Thompson wrote:
> "Tony" <tony@my.net> writes:
> [...]
> > I rely on the fact that the compiler gives some kind of padding/alignment 
> > control, either via pragmas or commandline/IDE switches. I pretty much 
> > byte-align everything (with the switch) and do "manual alignment" when 
> > designing structs (not as hard as it sounds). The only real "gotcha" to 
> > watch out for is pointer fields for their width is different on 32- and 
> > 64-bit platforms (put pointers at the top of the struct and subsequent
field 
> > will align nicely). I always use width-specified integral types.
> 
> Why?  Is it really worth the effort to do manually what the compiler
> would have done for you?

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.

Barry Schwarz wrote:
> On Fri, 1 May 2009 13:26:43 +0000 (UTC), gazelle@shell.xmission.com
> (Kenny McCormack) wrote:
> 
>> In article <gteqma$eev$1@aioe.org>, kid joe  <spamtrap@spamtrap.invalid> wrote:
>> ...
>>> Hi Keith,
>>>
>>> Thanks for the correction.
>> Please, sir.  Could I have some more?
>>
>>> I find that strange... if I was a compiler writer on an endianness where
>>> the least-significant byte was at the top end of the word, my thought to
>>> implement a struct with char followed by int, Id allocate a whole dword
>>> for the char, just do native-width integer operations on the dword, then
>>> access and set the char through an 0xFF mask. But it sounds like that
>>> wouldnt be standards-compliant.
>> 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.

Actually Kenny McCormack is 100% right.  There may be padding before the
structure.  Or are you so daft as the think that the structure isn't aligned on
the correct boundary for its first element?  As McCormack said very clearly that
padding isn't considered part of the structure, never the less it is there!
Same thing happens when you get memory from malloc, but there it is talked about.

Golden California Girls  <gldncagrls@aol.com.mil> wrote:
>Or are you so daft as the think that the structure isn't aligned on the
>correct boundary for its first element?

Typical CLC thread: 2 seconds of life followed by a solid 96-hour death
rattle.

-Beej

Beej Jorgensen wrote:
> Golden California Girls  <gldncagrls@aol.com.mil> wrote:
>> Or are you so daft as the think that the structure isn't aligned on the
>> correct boundary for its first element?
> 
> Typical CLC thread: 2 seconds of life followed by a solid 96-hour death
> rattle.

     Wrenching back towards topicality: The quoted statement
is only partially correct.  A struct must be properly aligned
for *all* of its elements, not just for the first.  This is
easily seen by considering an array s[] of structs containing
an element we'll call x: Since both s[0] and s[1] are aligned
to the struct's own needs and since both s[0].x and s[1].x are
aligned to the needs of x's type, it follows that the alignment
of the struct type is a multiple of the alignment of x's type.
Since we made no assumptions about which struct element x is,
nor about its firstness or lastness or offsetof nor anything
other than that it's some element of the struct, the same
argument holds for all elements.

     Note that "multiple of" does not necessarily mean "smallest
multiple of," although it would be a fairly strange compiler
that didn't make it so.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

beej@beej.us wrote:
> Golden California Girls  <gldncagrls@aol.com.mil> wrote:
> >Or are you so daft as the think that the structure isn't aligned on the
> >correct boundary for its first element?
> 
> Typical CLC thread: 2 seconds of life followed by a solid 96-hour death
> rattle.

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)

On Sat, 02 May 2009 13:30:46 -0500, blargg.ei3@gishpuppy.com (blargg)
wrote:

>Keith Thompson wrote:
>> "Tony" <tony@my.net> writes:
>> [...]
>> > I rely on the fact that the compiler gives some kind of padding/alignment 
>> > control, either via pragmas or commandline/IDE switches. I pretty much 
>> > byte-align everything (with the switch) and do "manual alignment" when 
>> > designing structs (not as hard as it sounds). The only real "gotcha" to 
>> > watch out for is pointer fields for their width is different on 32- and 
>> > 64-bit platforms (put pointers at the top of the struct and subsequent
>field 
>> > will align nicely). I always use width-specified integral types.
>> 
>> Why?  Is it really worth the effort to do manually what the compiler
>> would have done for you?
>
>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.

-- 
Remove del for email

On Sat, 2 May 2009 01:38:27 -0700 (PDT),
nick_keighley_nospam@hotmail.com wrote:

>On 2 May, 02:07, CBFalconer <cbfalco...@yahoo.com> wrote:
>> Barry Schwarz wrote:
>> > gaze...@shell.xmission.com (Kenny McCormack) wrote:
>
>
>> >> 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:
>
>but what he said made sense.

Just enough to be plausible.  Unfortunately it was incomplete and not
quite accurate.

-- 
Remove del for email

On Sat, 02 May 2009 19:07:20 GMT, Golden California Girls
<gldncagrls@aol.com.mil> wrote:

>Barry Schwarz wrote:
>> On Fri, 1 May 2009 13:26:43 +0000 (UTC), gazelle@shell.xmission.com
>> (Kenny McCormack) wrote:
>> 
>>> In article <gteqma$eev$1@aioe.org>, kid joe  <spamtrap@spamtrap.invalid> wrote:
>>> ...
>>>> Hi Keith,
>>>>
>>>> Thanks for the correction.
>>> Please, sir.  Could I have some more?
>>>
>>>> I find that strange... if I was a compiler writer on an endianness where
>>>> the least-significant byte was at the top end of the word, my thought to
>>>> implement a struct with char followed by int, Id allocate a whole dword
>>>> for the char, just do native-width integer operations on the dword, then
>>>> access and set the char through an 0xFF mask. But it sounds like that
>>>> wouldnt be standards-compliant.
>>> 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.
>
>Actually Kenny McCormack is 100% right.  There may be padding before the

The proof that his statement is incorrect is simple.  Consider a
system where int must be aligned on a multiple of 4 and long on a
multiple of 8.  Now consider a struct on that system
    struct s {int x; long y}z;

If z is located on a multiple of 8, then there must be 4 bytes of
padding between x and y (acutely 8k+4 for some non-negative k but I
would love to here about a system where k is not 0).

If z is located on an odd multiple of 4, there must be 0 bytes of
padding (actually 8k ...)

But the padding in z is not variable. Since either location satisfies
Kenny's statement but each requires a different amount of padding, the
statement cannot be correct.

>structure.  Or are you so daft as the think that the structure isn't aligned on
>the correct boundary for its first element?  As McCormack said very clearly that

The structure is actually aligned for all of its members and the issue
is usually driven by the member with the strictest requirement.

>padding isn't considered part of the structure, never the less it is there!
>Same thing happens when you get memory from malloc, but there it is talked about.

Now consider malloc in this system.  It must return an address
suitable for any object.  Since long must be on a multiple of 8,
malloc must return a multiple of 8.  But since struct s is also an
object type, it must also be aligned on a multiple of 8 with four
bytes of padding since the address returned from malloc is suitable
for it also.  Therefore again, z cannot be aligned on a multiple of 4
even though it satisfies Kenny's condition.

-- 
Remove del for email

Barry Schwarz wrote:
> CBFalconer <cbfalconer@yahoo.com> wrote:
>> Barry Schwarz wrote:
>>> gazelle@shell.xmission.com (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.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

nick_keighley_nospam@hotmail.com wrote:
> CBFalconer <cbfalco...@yahoo.com> wrote:
>> Barry Schwarz wrote:
>>> gaze...@shell.xmission.com (Kenny McCormack) wrote:
> 
>>>> 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:
> 
> but what he said made sense.

But is forbidden in the standard.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

blargg wrote:
> beej@beej.us wrote:
>> Golden California Girls  <gldncagrls@aol.com.mil> wrote:
>>
>>> Or are you so daft as the think that the structure isn't aligned
>>> on the correct boundary for its first element?
>>
>> Typical CLC thread: 2 seconds of life followed by a solid 96-hour
>> death rattle.
> 
> 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.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

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

I'll retract mine about 100%

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

Barry Schwarz wrote:
> On Sat, 02 May 2009 19:07:20 GMT, Golden California Girls
> <gldncagrls@aol.com.mil> wrote:
> 
>> Barry Schwarz wrote:
>>> On Fri, 1 May 2009 13:26:43 +0000 (UTC), gazelle@shell.xmission.com
>>> (Kenny McCormack) wrote:
>>>
>>>> In article <gteqma$eev$1@aioe.org>, kid joe  <spamtrap@spamtrap.invalid> wrote:
>>>> ...
>>>>> Hi Keith,
>>>>>
>>>>> Thanks for the correction.
>>>> Please, sir.  Could I have some more?
>>>>
>>>>> I find that strange... if I was a compiler writer on an endianness where
>>>>> the least-significant byte was at the top end of the word, my thought to
>>>>> implement a struct with char followed by int, Id allocate a whole dword
>>>>> for the char, just do native-width integer operations on the dword, then
>>>>> access and set the char through an 0xFF mask. But it sounds like that
>>>>> wouldnt be standards-compliant.
>>>> 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.
>> Actually Kenny McCormack is 100% right.  There may be padding before the
> 
> The proof that his statement is incorrect is simple.  Consider a
> system where int must be aligned on a multiple of 4 and long on a
> multiple of 8.  Now consider a struct on that system
>     struct s {int x; long y}z;
> 
> If z is located on a multiple of 8, then there must be 4 bytes of
> padding between x and y (acutely 8k+4 for some non-negative k but I
> would love to here about a system where k is not 0).
> 
> If z is located on an odd multiple of 4, there must be 0 bytes of
> padding (actually 8k ...)
> 
> But the padding in z is not variable. Since either location satisfies
> Kenny's statement but each requires a different amount of padding, the
> statement cannot be correct.
> 
>> structure.  Or are you so daft as the think that the structure isn't aligned on
>> the correct boundary for its first element?  As McCormack said very clearly that
> 
> The structure is actually aligned for all of its members and the issue
> is usually driven by the member with the strictest requirement.
> 
>> padding isn't considered part of the structure, never the less it is there!
>> Same thing happens when you get memory from malloc, but there it is talked about.
> 
> Now consider malloc in this system.  It must return an address
> suitable for any object.  Since long must be on a multiple of 8,
> malloc must return a multiple of 8.  But since struct s is also an
> object type, it must also be aligned on a multiple of 8 with four
> bytes of padding since the address returned from malloc is suitable
> for it also.  Therefore again, z cannot be aligned on a multiple of 4
> even though it satisfies Kenny's condition.
> 

On Sun, 03 May 2009 07:51:57 GMT, Golden California Girls
<gldncagrls@aol.com.mil> wrote:

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

>
>Barry Schwarz wrote:
>> On Sat, 02 May 2009 19:07:20 GMT, Golden California Girls
>> <gldncagrls@aol.com.mil> wrote:
>> 
>>> Barry Schwarz wrote:
>>>> On Fri, 1 May 2009 13:26:43 +0000 (UTC), gazelle@shell.xmission.com
>>>> (Kenny McCormack) wrote:
>>>>
>>>>> In article <gteqma$eev$1@aioe.org>, kid joe  <spamtrap@spamtrap.invalid> wrote:
>>>>> ...
>>>>>> Hi Keith,
>>>>>>
>>>>>> Thanks for the correction.
>>>>> Please, sir.  Could I have some more?
>>>>>
>>>>>> I find that strange... if I was a compiler writer on an endianness where
>>>>>> the least-significant byte was at the top end of the word, my thought to
>>>>>> implement a struct with char followed by int, Id allocate a whole dword
>>>>>> for the char, just do native-width integer operations on the dword, then
>>>>>> access and set the char through an 0xFF mask. But it sounds like that
>>>>>> wouldnt be standards-compliant.
>>>>> 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.
>>> Actually Kenny McCormack is 100% right.  There may be padding before the
>> 
>> The proof that his statement is incorrect is simple.  Consider a
>> system where int must be aligned on a multiple of 4 and long on a
>> multiple of 8.  Now consider a struct on that system
>>     struct s {int x; long y}z;
>> 
>> If z is located on a multiple of 8, then there must be 4 bytes of
>> padding between x and y (acutely 8k+4 for some non-negative k but I
>> would love to here about a system where k is not 0).
>> 
>> If z is located on an odd multiple of 4, there must be 0 bytes of
>> padding (actually 8k ...)
>> 
>> But the padding in z is not variable. Since either location satisfies
>> Kenny's statement but each requires a different amount of padding, the
>> statement cannot be correct.
>> 
>>> structure.  Or are you so daft as the think that the structure isn't aligned on
>>> the correct boundary for its first element?  As McCormack said very clearly that
>> 
>> The structure is actually aligned for all of its members and the issue
>> is usually driven by the member with the strictest requirement.
>> 
>>> padding isn't considered part of the structure, never the less it is there!
>>> Same thing happens when you get memory from malloc, but there it is talked about.
>> 
>> Now consider malloc in this system.  It must return an address
>> suitable for any object.  Since long must be on a multiple of 8,
>> malloc must return a multiple of 8.  But since struct s is also an
>> object type, it must also be aligned on a multiple of 8 with four
>> bytes of padding since the address returned from malloc is suitable
>> for it also.  Therefore again, z cannot be aligned on a multiple of 4
>> even though it satisfies Kenny's condition.
>> 

-- 
Remove del for email

Barry Schwarz wrote:
> On Sun, 03 May 2009 07:51:57 GMT, Golden California Girls
> <gldncagrls@aol.com.mil> wrote:
> 
>> I take it you are retracting your words
>> "everywhere except before the first member"
> 
> Please don't top post.

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

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

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.

In article <dWpLl.2220$fy.1897@nwrddc01.gnilink.net>,
Golden California Girls  <gldncagrls@aol.com.mil> wrote:

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

>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
-- 
Please remember to mention me / in tapes you leave behind.

On Sun, 03 May 2009 23:38:49 GMT, Golden California Girls
<gldncagrls@aol.com.mil> wrote:

>Barry Schwarz wrote:
>> On Sun, 03 May 2009 07:51:57 GMT, Golden California Girls
>> <gldncagrls@aol.com.mil> wrote:
>> 
>>> I take it you are retracting your words
>>> "everywhere except before the first member"
>> 
>> Please don't top post.
>
>When I don't want to pad, I will.
>
>> 
>> On the contrary, there is never any padding before the first member of
>> a struct.
>
>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.

-- 
Remove del for email

Barry Schwarz wrote:
> 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.

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

Golden California Girls  <gldncagrls@aol.com.mil> wrote:
>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

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnocubigg8.fsf@nuthaus.mib.org...
> "Tony" <tony@my.net> writes:
> [...]
>> I rely on the fact that the compiler gives some kind of padding/alignment
>> control, either via pragmas or commandline/IDE switches. I pretty much
>> byte-align everything (with the switch) and do "manual alignment" when
>> designing structs (not as hard as it sounds). The only real "gotcha" to
>> watch out for is pointer fields for their width is different on 32- and
>> 64-bit platforms (put pointers at the top of the struct and subsequent 
>> field
>> will align nicely). I always use width-specified integral types.
>
> 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

"blargg" <blargg.ei3@gishpuppy.com> wrote in message 
news:blargg.ei3-0205091330460001@192.168.1.4...
> Keith Thompson wrote:
>> "Tony" <tony@my.net> writes:
>> [...]
>> > I rely on the fact that the compiler gives some kind of 
>> > padding/alignment
>> > control, either via pragmas or commandline/IDE switches. I pretty much
>> > byte-align everything (with the switch) and do "manual alignment" when
>> > designing structs (not as hard as it sounds). The only real "gotcha" to
>> > watch out for is pointer fields for their width is different on 32- and
>> > 64-bit platforms (put pointers at the top of the struct and subsequent
> field
>> > will align nicely). I always use width-specified integral types.
>>
>> Why?  Is it really worth the effort to do manually what the compiler
>> would have done for you?
>
> 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