468,133 Members | 1,315 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,133 developers. It's quick & easy.

pragma pack(1) on struct contains object

In our project, one used the following struct

#pragma pack(1)
struct Foo {
uint8_t b1;
uint8_t b2;
uint8_t b3;
std::vector<uint8_t buf;
...
};
#pragma pack()

this work on PC, but not on ARM target using a gcc/g++ cross
compiler. The problem is, on ARM, after defined a variable of Foo
and want to access a method of buf, such as

Foo foo;
foo.buf.resize(100);

the program will exit. I guss it's a segment failure.
Can you experts explain for me the reason? I know, it is suspious
that why this guy use pack(1) on this kind of struct, but we can just
ignore it and focus on the underlying reason why the usage cause the
failure.

Thanks in advance.

-
narke

Jul 12 '08 #1
4 14780
On 12 Jul., 12:26, Steven Woody <narkewo...@gmail.comwrote:
In our project, one used the following struct

#pragma pack(1)
struct Foo {
* uint8_t * b1;
* uint8_t * b2;
* uint8_t * b3;
* std::vector<uint8_t*buf;
* ...};

#pragma pack()

this work on PC, but not on ARM target using a gcc/g++ cross
compiler. *The problem is, on ARM, after defined a variable of *Foo
and want to access a method of buf, such as

* * Foo foo;
* * foo.buf.resize(100);

the program will exit. *I guss it's a segment failure.

Can you experts explain for me the reason? *I know, it is *suspious
that why this guy use pack(1) on this kind of struct, but we can just
ignore it and focus on the underlying reason why the usage cause the
failure.
Because some processors require that certain types are properly
aligned. So stop packing your structures: even on x86 architectures,
packed structures (although allowed) cause the code to run much more
slowly.

/Peter
Jul 12 '08 #2
Steven Woody wrote:
In our project, one used the following struct

#pragma pack(1)
struct Foo {
uint8_t b1;
uint8_t b2;
uint8_t b3;
std::vector<uint8_t buf;
...
};
#pragma pack()

this work on PC, but not on ARM target using a gcc/g++ cross
compiler. The problem is, on ARM, after defined a variable of Foo
and want to access a method of buf, such as

Foo foo;
foo.buf.resize(100);

the program will exit. I guss it's a segment failure.
Can you experts explain for me the reason?
Because you enforce mis-alingment. And while PCs can still access
mis-algined data (though at reduced speed), an ARM CPU simply can't.
I know, it is suspious that why this guy use pack(1) on this kind of
struct, but we can just ignore it and focus on the underlying reason why
the usage cause the failure.
Well that reason is at the same time the reason why this looks suspicious,
since it's also the reason why you shouldn't do that in the first place.
Jul 12 '08 #3
On Jul 13, 1:25 am, Rolf Magnus <ramag...@t-online.dewrote:
Steven Woody wrote:
In our project, one used the following struct
#pragma pack(1)
struct Foo {
uint8_t b1;
uint8_t b2;
uint8_t b3;
std::vector<uint8_t buf;
...
};
#pragma pack()
this work on PC, but not on ARM target using a gcc/g++ cross
compiler. The problem is, on ARM, after defined a variable of Foo
and want to access a method of buf, such as
Foo foo;
foo.buf.resize(100);
the program will exit. I guss it's a segment failure.
Can you experts explain for me the reason?

Because you enforce mis-alingment. And while PCs can still access
mis-algined data (though at reduced speed), an ARM CPU simply can't.
I know, it is suspious that why this guy use pack(1) on this kind of
struct, but we can just ignore it and focus on the underlying reason why
the usage cause the failure.

Well that reason is at the same time the reason why this looks suspicious,
since it's also the reason why you shouldn't do that in the first place.

Could you explain? Thanks.

And, I am thinking another question: whether using packing a struct is
itself a bad notion at all. You know, we are writting a network
program, other members in the team tends to define a structure for
every kind of packet come in/out from/to the network, because there is
no padding in packets in the form of byte-stream, so "#pragma pack(1)"
or "__attribute__((packed))" was used almost everywhere. I personally
dont' prefer this method, I just do the packet parsing and framing in
a character by character way, hence don't mapping packets to any in-
memory structure. Do these two kind of programming style imply
anything? What kind do you prefer?

Thanks in advance.
Jul 13 '08 #4
Steven Woody wrote:
>
*Please* don't quote sigs
>

In your previous post, I thing I don't fully understand the term 'mis-
alignment':
Most, if not all processors prefer types to be aligned to their natural
boundary, say 4 bytes for an int. When an int value is not aligned on a
4 byte boundary, the processor may require one or two extra bus cycles
to read the value form memory.

Some processors (Sparc for example) *require* types to be aligned to
their natural boundary. They will generate a hardware trap it you
attempt a misaligned access.

--
Ian Collins.
Jul 13 '08 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by codymanix | last post: by
11 posts views Thread by James Gregory | last post: by
9 posts views Thread by Giovanni Bajo | last post: by
1 post views Thread by Mike Margerum | last post: by
3 posts views Thread by GeLLcheN | last post: by
6 posts views Thread by Jack | last post: by
3 posts views Thread by Jimmy | last post: by
6 posts views Thread by Boltar | last post: by
2 posts views Thread by Henry Yiu | last post: by
27 posts views Thread by didacticone | last post: by
1 post views Thread by gcdp | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.