structure address = structure first field address ?

Discussion in 'C Programming' started by Vincent De Groote, Apr 29, 2009.

  1. 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, Apr 29, 2009
    #1
    1. Advertising

  2. Vincent De Groote

    Eric Sosman Guest

    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
    lid
     
    Eric Sosman, Apr 29, 2009
    #2
    1. Advertising

  3. Vincent De Groote

    jameskuyper Guest

    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)
     
    jameskuyper, Apr 29, 2009
    #3
  4. Vincent De Groote

    kid joe Guest

    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! , /\_ _| | .-'_|
    `................, _\__`[_______________| _| (_|
    ] [ \, ][ ][ (_|
     
    kid joe, Apr 29, 2009
    #4
  5. Vincent De Groote

    CBFalconer Guest

    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.
     
    CBFalconer, Apr 30, 2009
    #5
  6. kid joe <> 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) <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"
     
    Keith Thompson, Apr 30, 2009
    #6
  7. Vincent De Groote

    kid joe Guest

    On Wed, 29 Apr 2009 18:16:12 -0700, Keith Thompson wrote:
    > kid joe <> 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! , /\_ _| | .-'_|
    `................, _\__`[_______________| _| (_|
    ] [ \, ][ ][ (_|
     
    kid joe, May 1, 2009
    #7
  8. In article <gteqma$eev$>, kid joe <> 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.
     
    Kenny McCormack, May 1, 2009
    #8
  9. In article <gteqma$eev$>, kid joe <> 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.
     
    Richard Tobin, May 1, 2009
    #9
  10. On Fri, 1 May 2009 13:26:43 +0000 (UTC),
    (Kenny McCormack) wrote:

    >In article <gteqma$eev$>, kid joe <> 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, May 2, 2009
    #10
  11. Vincent De Groote

    CBFalconer Guest

    Barry Schwarz wrote:
    > (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.
     
    CBFalconer, May 2, 2009
    #11
  12. On Fri, 01 May 2009 21:07:35 -0400, CBFalconer <>
    wrote:

    >Barry Schwarz wrote:
    >> (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
     
    Barry Schwarz, May 2, 2009
    #12
  13. Vincent De Groote

    Guest

    On 2 May, 02:07, CBFalconer <> wrote:
    > Barry Schwarz wrote:
    > > (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.

    <snip big chunk of boiler-plate standardese>
     
    , May 2, 2009
    #13
  14. someone wrote:

    > On 2 May, 02:07, CBFalconer <> wrote:
    >> Barry Schwarz wrote:
    >> > (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
     
    Ralf Damaschke, May 2, 2009
    #14
  15. Vincent De Groote

    Tony Guest

    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, May 2, 2009
    #15
  16. "Tony" <> 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) <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"
     
    Keith Thompson, May 2, 2009
    #16
  17. Golden California Girls <> 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, May 2, 2009
    #17
  18. Vincent De Groote

    Eric Sosman Guest

    Beej Jorgensen wrote:
    > Golden California Girls <> 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
    lid
     
    Eric Sosman, May 2, 2009
    #18
  19. On Sat, 2 May 2009 01:38:27 -0700 (PDT),
    wrote:

    >On 2 May, 02:07, CBFalconer <> wrote:
    >> Barry Schwarz wrote:
    >> > (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
     
    Barry Schwarz, May 3, 2009
    #19
  20. On Sat, 02 May 2009 19:07:20 GMT, Golden California Girls
    <> wrote:

    >Barry Schwarz wrote:
    >> On Fri, 1 May 2009 13:26:43 +0000 (UTC),
    >> (Kenny McCormack) wrote:
    >>
    >>> In article <gteqma$eev$>, kid joe <> 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, May 3, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Grumble
    Replies:
    19
    Views:
    782
    Andrey Tarasevich
    Mar 16, 2005
  2. Tony Young
    Replies:
    3
    Views:
    322
    Daniel T.
    Mar 26, 2006
  3. Sound
    Replies:
    2
    Views:
    481
    Randy Webb
    Sep 28, 2006
  4. jr
    Replies:
    3
    Views:
    475
  5. Replies:
    2
    Views:
    289
    Rui Maciel
    Dec 12, 2012
Loading...

Share This Page