2/4 bytes boundary problem

Discussion in 'C Programming' started by Thomas.Chang, May 15, 2006.

  1. Thomas.Chang

    Thomas.Chang Guest

    Hi,

    As we know, the compiler will pad structure to make it align on 4
    byte boundaries.
    I got a structure like this.
    typedef struct{
    uint8 a;
    uint8 b;
    uint8 c;
    uint16 d;
    ...
    }s;
    s s1;
    ... func(..., &s1.d, ...){...}
    But I always got crash when calling func(). I interchanged the
    position of "c" and "d", anything went ok.
    As the compiler will pad it right. Why I cannot fetch the address of
    "d"?
    Although the position of "c" and "d" is swapped, "d" is still not on
    4 byte boundary. But it works well, why?

    Thomas
     
    Thomas.Chang, May 15, 2006
    #1
    1. Advertising

  2. Thomas.Chang

    Flash Gordon Guest

    Thomas.Chang wrote:
    > Hi,
    >
    > As we know, the compiler will pad structure to make it align on 4
    > byte boundaries.


    Not on all systems.

    > I got a structure like this.
    > typedef struct{
    > uint8 a;
    > uint8 b;
    > uint8 c;
    > uint16 d;
    > ...
    > }s;
    > s s1;
    > ... func(..., &s1.d, ...){...}
    > But I always got crash when calling func(). I interchanged the
    > position of "c" and "d", anything went ok.
    > As the compiler will pad it right. Why I cannot fetch the address of
    > "d"?
    > Although the position of "c" and "d" is swapped, "d" is still not on
    > 4 byte boundary. But it works well, why?


    You've got an error on line 42 of func.

    In other words, if you don't show us your code how are we expected to
    know what you have done wrong? Post a small complete compilable program
    that exhibits the problem.
    --
    Flash Gordon, living in interesting times.
    Web site - http://home.flash-gordon.me.uk/
    comp.lang.c posting guidelines and intro:
    http://clc-wiki.net/wiki/Intro_to_clc
     
    Flash Gordon, May 15, 2006
    #2
    1. Advertising

  3. On 2006-05-15, Thomas.Chang <> wrote:
    > Hi,
    >
    > As we know, the compiler will pad structure to make it align on 4
    > byte boundaries.

    No, that's not guaranteed at all. Where did you hear that?

    > I got a structure like this.
    > typedef struct{
    > uint8 a;
    > uint8 b;
    > uint8 c;

    Why not just use chars?

    > uint16 d;

    And if you insist on 16 bits, try small int

    > ...
    > }s;
    > s s1;
    > ... func(..., &s1.d, ...){...}
    > But I always got crash when calling func(). I interchanged the
    > position of "c" and "d", anything went ok.
    > As the compiler will pad it right. Why I cannot fetch the address of
    > "d"?
    > Although the position of "c" and "d" is swapped, "d" is still not on
    > 4 byte boundary. But it works well, why?
    >
     
    Andrew Poelstra, May 15, 2006
    #3
  4. Andrew Poelstra wrote:
    > On 2006-05-15, Thomas.Chang <> wrote:
    > > Hi,
    > >
    > > As we know, the compiler will pad structure to make it align on 4
    > > byte boundaries.

    > No, that's not guaranteed at all. Where did you hear that?
    >
    > > I got a structure like this.
    > > typedef struct{
    > > uint8 a;
    > > uint8 b;
    > > uint8 c;

    > Why not just use chars?


    unsigned char would be the correct recommendation in this case.

    > > uint16 d;

    > And if you insist on 16 bits, try small int


    I don't know what a "small int" is but the corresponding type would be
    unsigned short int on most implementations. If the OP wants exactly 16
    bits this may not be suitable as short int can be more than 16 bits.

    Robert Gamble
     
    Robert Gamble, May 15, 2006
    #4
  5. Thomas.Chang

    Guest

    set the compiler optimization disable for the structure.

    like this:

    typedef struct{
    uint8 a;
    uint8 b;
    uint8 c;
    uint16 d;
    ...
    } __attribute__((packed)) s;
     
    , May 15, 2006
    #5
  6. On 2006-05-15, Robert Gamble <> wrote:
    > Andrew Poelstra wrote:
    >> On 2006-05-15, Thomas.Chang <> wrote:
    >> > Hi,
    >> >
    >> > As we know, the compiler will pad structure to make it align on 4
    >> > byte boundaries.

    >> No, that's not guaranteed at all. Where did you hear that?
    >>
    >> > I got a structure like this.
    >> > typedef struct{
    >> > uint8 a;
    >> > uint8 b;
    >> > uint8 c;

    >> Why not just use chars?

    >
    > unsigned char would be the correct recommendation in this case.
    >

    Is a uint8 unsigned by default? I honestly don't know.

    >> > uint16 d;

    >> And if you insist on 16 bits, try small int

    >
    > I don't know what a "small int" is but the corresponding type would be
    > unsigned short int on most implementations. If the OP wants exactly 16
    > bits this may not be suitable as short int can be more than 16 bits.
    >

    Yes, I meant 'short int'. I got four hours of sleep last night...
     
    Andrew Poelstra, May 15, 2006
    #6
  7. On 2006-05-15, Andrew Poelstra <> wrote:
    > On 2006-05-15, Robert Gamble <> wrote:
    >> Andrew Poelstra wrote:
    >>> On 2006-05-15, Thomas.Chang <> wrote:
    >>> > Hi,
    >>> >
    >>> > As we know, the compiler will pad structure to make it align on 4
    >>> > byte boundaries.
    >>> No, that's not guaranteed at all. Where did you hear that?
    >>>
    >>> > I got a structure like this.
    >>> > typedef struct{
    >>> > uint8 a;
    >>> > uint8 b;
    >>> > uint8 c;
    >>> Why not just use chars?

    >>
    >> unsigned char would be the correct recommendation in this case.
    >>

    > Is a uint8 unsigned by default? I honestly don't know.
    >

    Wait... that's what the u is for, isn't it? I've really got
    to go to bed.
     
    Andrew Poelstra, May 15, 2006
    #7
  8. On Mon, 15 May 2006 06:58:15 -0700, Thomas.Chang wrote:

    > Hi,
    >
    > As we know, the compiler will pad structure to make it align on 4
    > byte boundaries.
    > I got a structure like this.
    > typedef struct{
    > uint8 a;
    > uint8 b;
    > uint8 c;
    > uint16 d;
    > ...
    > }s;
    > s s1;
    > ... func(..., &s1.d, ...){...}
    > But I always got crash when calling func(). I interchanged the
    > position of "c" and "d", anything went ok.
    > As the compiler will pad it right. Why I cannot fetch the address of
    > "d"?
    > Although the position of "c" and "d" is swapped, "d" is still not on
    > 4 byte boundary. But it works well, why?
    >
    > Thomas


    Hard to say without more details. For example this:
    #include <stdio.h>
    typedef struct
    { char a;
    char b;
    char c;
    short int d;
    int e;
    } s;
    static void hmm( s* s, short int* d)
    { printf( "hmm %d -> %d\n", (char*)d-(char*)s, *d);
    }
    int main( int argc, char** argv)
    {
    s s1 = { 1, 2, 3, 444, 5};
    hmm( &s1, &s1.d);
    return 0;
    }
    compiled with "gcc -Wall -pedantic -ansi -o pad pad.c" (gcc 3.4.5) doesn't
    show any problems -- abd prints hmm "4 -> 444" as one would expect.

    Duncan
     
    Duncan Muirhead, May 15, 2006
    #8
  9. Thomas.Chang

    Flash Gordon Guest

    wrote:

    Please provide context when posting. Google is most definitely *not*
    Usenet. See the Google section at http://clc-wiki.net/wiki/Intro_to_clc
    for more information.

    > set the compiler optimization disable for the structure.
    >
    > like this:
    >
    > typedef struct{
    > uint8 a;
    > uint8 b;
    > uint8 c;
    > uint16 d;
    > ...
    > } __attribute__((packed)) s;


    That's strange, my C compiler rejects that. Perhaps __attribute__ is not
    part of C but an extension provided by some compilers? Do you have any
    reason to suspect that the OP is only interested in compilers that
    support this extension?
    --
    Flash Gordon, living in interesting times.
    Web site - http://home.flash-gordon.me.uk/
    comp.lang.c posting guidelines and intro:
    http://clc-wiki.net/wiki/Intro_to_clc

    Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
     
    Flash Gordon, May 15, 2006
    #9
  10. Andrew Poelstra wrote:
    > On 2006-05-15, Andrew Poelstra <> wrote:
    > > On 2006-05-15, Robert Gamble <> wrote:
    > >> Andrew Poelstra wrote:
    > >>> On 2006-05-15, Thomas.Chang <> wrote:
    > >>> > Hi,
    > >>> >
    > >>> > As we know, the compiler will pad structure to make it align on 4
    > >>> > byte boundaries.
    > >>> No, that's not guaranteed at all. Where did you hear that?
    > >>>
    > >>> > I got a structure like this.
    > >>> > typedef struct{
    > >>> > uint8 a;
    > >>> > uint8 b;
    > >>> > uint8 c;
    > >>> Why not just use chars?
    > >>
    > >> unsigned char would be the correct recommendation in this case.
    > >>

    > > Is a uint8 unsigned by default? I honestly don't know.
    > >

    > Wait... that's what the u is for, isn't it?


    One would assume so.

    > I've really got to go to bed.


    Robert Gamble
     
    Robert Gamble, May 15, 2006
    #10
  11. On Mon, 15 May 2006 15:16:17 +0100
    Flash Gordon <> wrote:

    > You've got an error on line 42 of func.
    >
    > In other words, if you don't show us your code how are we expected to
    > know what you have done wrong? Post a small complete compilable
    > program that exhibits the problem.
    > http://clc-wiki.net/wiki/Intro_to_clc


    Why people say that it's an "error on line 42"? Why specifically line
    42? I looked for it on c-faq.com and that wiki but there's no entries
    for it.
     
    Rafael Almeida, May 15, 2006
    #11
  12. Thomas.Chang

    Vladimir Oka Guest

    Rafael Almeida opined:

    > On Mon, 15 May 2006 15:16:17 +0100
    > Flash Gordon <> wrote:
    >
    >> You've got an error on line 42 of func.
    >>
    >> In other words, if you don't show us your code how are we expected
    >> to know what you have done wrong? Post a small complete compilable
    >> program that exhibits the problem.
    >> http://clc-wiki.net/wiki/Intro_to_clc

    >
    > Why people say that it's an "error on line 42"? Why specifically line
    > 42? I looked for it on c-faq.com and that wiki but there's no entries
    > for it.


    Look up Hitchhikers Guide to the Galaxy, by Douglas Adams. I'd go even
    further, and recommend you actually read it (and all the sequels).

    42 is the answer to Life, Universe, and Everything. But, what is the
    *question*?

    --
    Time is fluid ... like a river with currents, eddies, backwash.
    -- Spock, "The City on the Edge of Forever", stardate 3134.0

    <http://clc-wiki.net/wiki/Introduction_to_comp.lang.c>
     
    Vladimir Oka, May 15, 2006
    #12
  13. On 2006-05-15, Rafael Almeida <> wrote:
    > On Mon, 15 May 2006 15:16:17 +0100
    > Flash Gordon <> wrote:
    >
    >> You've got an error on line 42 of func.
    >>
    >> In other words, if you don't show us your code how are we expected to
    >> know what you have done wrong? Post a small complete compilable
    >> program that exhibits the problem.
    >> http://clc-wiki.net/wiki/Intro_to_clc

    >
    > Why people say that it's an "error on line 42"? Why specifically line
    > 42? I looked for it on c-faq.com and that wiki but there's no entries
    > for it.


    42 is a reference to "Hitchhiker's Guide to the Galaxy" and is a very
    profound number. Line 42 means that *you didn't post any code* (or not
    enough code) and therefore must assume that the code is floating
    through space and is part of the very fabric of the universe. And line
    42 has a glitch which causes all the problems of the world.

    In most cases, unposted code is merely unposted code and nothing else.
    But we can hope...

    (I starred the only important part of that paragraph)
     
    Andrew Poelstra, May 15, 2006
    #13
  14. Thomas.Chang

    Default User Guest

    Rafael Almeida wrote:

    > On Mon, 15 May 2006 15:16:17 +0100
    > Flash Gordon <> wrote:
    >
    > > You've got an error on line 42 of func.
    > >
    > > In other words, if you don't show us your code how are we expected
    > > to know what you have done wrong? Post a small complete compilable
    > > program that exhibits the problem.
    > > http://clc-wiki.net/wiki/Intro_to_clc

    >
    > Why people say that it's an "error on line 42"? Why specifically line
    > 42? I looked for it on c-faq.com and that wiki but there's no entries
    > for it.



    It's the answer to the question, always. Life, the Universe,
    everything.

    <http://en.wikipedia.org/wiki/The_Answer_to_Life,_the_Universe,_and_Ever
    ything>




    Brian
     
    Default User, May 15, 2006
    #14
  15. Thomas.Chang

    Nelu Guest

    Rafael Almeida wrote:
    > On Mon, 15 May 2006 15:16:17 +0100
    > Flash Gordon <> wrote:
    >
    > > You've got an error on line 42 of func.
    > >
    > > In other words, if you don't show us your code how are we expected to
    > > know what you have done wrong? Post a small complete compilable
    > > program that exhibits the problem.
    > > http://clc-wiki.net/wiki/Intro_to_clc

    >
    > Why people say that it's an "error on line 42"? Why specifically line
    > 42? I looked for it on c-faq.com and that wiki but there's no entries
    > for it.


    It's related to the cosmological constant (between 40 and 50, if it's
    really a constant - Hubble diagrams help). The Hitchhiker's Guide...
    (book, movie) makes it 42 and sets it as the answer to everything.
    There's no theory behind 42 other than "between 40 and 50" so it's like
    popping a number from the top of your head without having any idea what
    the number is, exactly like finding the error in a piece of code that
    you don't have access to.

    --
    Ioan - Ciprian Tandau
    tandau _at_ freeshell _dot_ org (hope it's not too late)
    (... and that it still works...)
     
    Nelu, May 16, 2006
    #15
  16. Nelu said:

    > There's no theory behind 42 other than "between 40 and 50"


    Not even that.

    DNA was astounded to learn that astronomers are finding a use for 42. When
    he chose it, it was for no other reason than that it was the sort of number
    you would be happy to take home and introduce to your parents.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at above domain (but drop the www, obviously)
     
    Richard Heathfield, May 16, 2006
    #16
  17. Thomas.Chang

    Thomas.Chang Guest

    My bad for not stating that my program is just a little piece of an
    embedded system, a router.
    I know that a lot of factors may cause the crash. But it does work well
    after I swapped the position of "c" and "d".
    I heard that problems occur when you try to fetch a member which
    locates across boundaries, but I don't know what the problem can be,
    crash? Maybe...
    btw, the CPU is IXP425 for my router. I know that the "packed" option
    can prohibit padding, which is dangerous for packets constructing or
    parsing. But my code is runtime data structure, which can be paded at
    one's wish.
    Then why the CPU didn't pad it? Is it sleeping?... Oh, god!

    Duncan Muirhead wrote:
    > On Mon, 15 May 2006 06:58:15 -0700, Thomas.Chang wrote:
    >
    > > Hi,
    > >
    > > As we know, the compiler will pad structure to make it align on 4
    > > byte boundaries.
    > > I got a structure like this.
    > > typedef struct{
    > > uint8 a;
    > > uint8 b;
    > > uint8 c;
    > > uint16 d;
    > > ...
    > > }s;
    > > s s1;
    > > ... func(..., &s1.d, ...){...}
    > > But I always got crash when calling func(). I interchanged the
    > > position of "c" and "d", anything went ok.
    > > As the compiler will pad it right. Why I cannot fetch the address of
    > > "d"?
    > > Although the position of "c" and "d" is swapped, "d" is still not on
    > > 4 byte boundary. But it works well, why?
    > >
    > > Thomas

    >
    > Hard to say without more details. For example this:
    > #include <stdio.h>
    > typedef struct
    > { char a;
    > char b;
    > char c;
    > short int d;
    > int e;
    > } s;
    > static void hmm( s* s, short int* d)
    > { printf( "hmm %d -> %d\n", (char*)d-(char*)s, *d);
    > }
    > int main( int argc, char** argv)
    > {
    > s s1 = { 1, 2, 3, 444, 5};
    > hmm( &s1, &s1.d);
    > return 0;
    > }
    > compiled with "gcc -Wall -pedantic -ansi -o pad pad.c" (gcc 3.4.5) doesn't
    > show any problems -- abd prints hmm "4 -> 444" as one would expect.
    >
    > Duncan
     
    Thomas.Chang, May 16, 2006
    #17
  18. Thomas.Chang

    Thomas.Chang Guest

    yes, the u stands for unsigned.
    I just want to emphasize the length of storage for each member.

    Andrew Poelstra wrote:
    > On 2006-05-15, Andrew Poelstra <> wrote:
    > > On 2006-05-15, Robert Gamble <> wrote:
    > >> Andrew Poelstra wrote:
    > >>> On 2006-05-15, Thomas.Chang <> wrote:
    > >>> > Hi,
    > >>> >
    > >>> > As we know, the compiler will pad structure to make it align on 4
    > >>> > byte boundaries.
    > >>> No, that's not guaranteed at all. Where did you hear that?
    > >>>
    > >>> > I got a structure like this.
    > >>> > typedef struct{
    > >>> > uint8 a;
    > >>> > uint8 b;
    > >>> > uint8 c;
    > >>> Why not just use chars?
    > >>
    > >> unsigned char would be the correct recommendation in this case.
    > >>

    > > Is a uint8 unsigned by default? I honestly don't know.
    > >

    > Wait... that's what the u is for, isn't it? I've really got
    > to go to bed.
     
    Thomas.Chang, May 16, 2006
    #18
  19. Thomas.Chang

    Eric Sosman Guest

    Nelu wrote On 05/15/06 23:40,:
    > Rafael Almeida wrote:
    >
    >>On Mon, 15 May 2006 15:16:17 +0100
    >>Flash Gordon <> wrote:
    >>
    >>
    >>>You've got an error on line 42 of func.
    >>>
    >>>In other words, if you don't show us your code how are we expected to
    >>>know what you have done wrong? Post a small complete compilable
    >>>program that exhibits the problem.
    >>>http://clc-wiki.net/wiki/Intro_to_clc

    >>
    >>Why people say that it's an "error on line 42"? Why specifically line
    >>42? I looked for it on c-faq.com and that wiki but there's no entries
    >>for it.

    >
    >
    > It's related to the cosmological constant (between 40 and 50, if it's
    > really a constant - Hubble diagrams help). The Hitchhiker's Guide...
    > (book, movie) makes it 42 and sets it as the answer to everything.
    > There's no theory behind 42 [...]


    <off-topic>

    I beg to differ: There *is* a theory behind 42. It's
    not only the Ultimate Answer to the Question of Life, the
    Universe, and Everything, but it's also the answer to the
    specific question

    What do you get if you multiply six by nine?

    .... which I think should be read with an emphasis on the
    second "you."

    </off-topic>

    --
     
    Eric Sosman, May 16, 2006
    #19
  20. Eric Sosman <> writes:
    [...]
    > <off-topic>
    >
    > I beg to differ: There *is* a theory behind 42. It's
    > not only the Ultimate Answer to the Question of Life, the
    > Universe, and Everything, but it's also the answer to the
    > specific question
    >
    > What do you get if you multiply six by nine?
    >
    > ... which I think should be read with an emphasis on the
    > second "you."
    >
    > </off-topic>


    #include <stdio.h>

    #define SIX 1+5
    #define NINE 8+1

    int main(void)
    {
    printf("%d * %d = %d\n", SIX, NINE, SIX * NINE);
    return 0;
    }

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, May 19, 2006
    #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. Jason Collins
    Replies:
    3
    Views:
    6,046
    Jason Collins
    Feb 18, 2004
  2. mrby

    4-bytes or 8-bytes alignment?

    mrby, Nov 2, 2004, in forum: C Programming
    Replies:
    8
    Views:
    435
    Mark McIntyre
    Nov 2, 2004
  3. Replies:
    5
    Views:
    558
    Flash Gordon
    Apr 9, 2006
  4. NM
    Replies:
    5
    Views:
    345
  5. Yandos
    Replies:
    12
    Views:
    5,135
    Pete Becker
    Sep 15, 2005
Loading...

Share This Page