2/4 bytes boundary problem

[Thomas.Chang]

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

 

[Flash Gordon]

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.

 

[Andrew Poelstra]

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

 

[Robert Gamble]

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

Why not just use chars?

unsigned char would be the correct recommendation in this case.

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

 

[zhongjiechao]

set the compiler optimization disable for the structure.

like this:

typedef struct{
uint8 a;
uint8 b;
uint8 c;
uint16 d;
...
} __attribute__((packed)) s;

 

[Andrew Poelstra]

unsigned char would be the correct recommendation in this case.

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

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]

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.

 

[Duncan Muirhead]

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

 

[Flash Gordon]

(e-mail address removed) 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

 

[Robert Gamble]

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

 

[Rafael Almeida]

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.

 

[Vladimir Oka]

Rafael Almeida opined:

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*?

 

[Andrew Poelstra]

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)

 

[Default User]

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

 

[Nelu]

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.

 

[Richard Heathfield]

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.

 

[Thomas.Chang]

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!

 

[Thomas.Chang]

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

 

[Eric Sosman]

Nelu wrote On 05/15/06 23:40,:

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>

 

[Keith Thompson]

<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;
}