Why #pragma pack() not take effect?

by **Jimmy** » Wed, 04 Jul 2007 16:15:55 GMT

Struct definition as following(on 32-bit Linux):

#pragma pack(push, 8)
struct MY_STRUCT
{
    char a[2];
    short b;
    short c;
    short d;
    int e;
    long long x;
    long long y;
};
#pragma(pop)

During the test, result of 'sizeof(struct MY_STRUCT)' is 28. Why not 32?
As I had expected, a,b,c,d will be packed into one 8-byte, e one and x, y
two. Ain't I right?

If I get wrong usage of #pragma pack(), could anyone please tell me how to
get it work correctly?

BTW, what on earth is the difference between __attribute__ align() and
#pragma pack()?

Thanks in advance!

by **Spoon** » Wed, 04 Jul 2007 17:18:55 GMT




What compiler on which platform are you using?

 http://www.**--****.com/ 

-fpack-struct[=n]

     Without a value specified, pack all structure members together 
without holes. When a value is specified (which must be a small power of 
two), pack structure members according to this value, representing the 
maximum alignment (that is, objects with default alignment requirements 
larger than this will be output potentially unaligned at the next 
fitting location.

What are you trying to accomplish?

You seem to actually want padding instead of packing.

by **Jimmy** » Wed, 04 Jul 2007 17:54:24 GMT



My platform is Red Hat Linux Enterprise 3. And I tried both gcc and cc and
got the same result.


 http://www.**--****.com/ 

Right, but it will take effect on all structs in the file compiled with this
option.



struct MY_STRUCT
{
    char a[2];
    short b;
    short c;
    short d;
    int e;              /* int e __attribute__ align(8);  */
    long long x;
    long long y;
};

    Actually yes. I want to get the member e 32-bit padded  wherea it can
have the
same structure as on a 64-bit platform such as HP-UX ia64.
    I can accomplish that via the commented form. However it's too
troublesome to
get all structs modified one by one, isn't it?

by **Jimmy** » Wed, 04 Jul 2007 18:26:40 GMT

>

Correct, the comment should be /* int e __attribute__ ((aligned(64)));  */

by jt » Wed, 04 Jul 2007 18:53:39 GMT






That's not enought information. You also need to know the archi-
tecture. And even different compilers on the same machine are in
principle allowed to use different sizes for the same type (and
use numbers of padding bytes in structures).






Padding can only be set in bytes, not bits (and byte meaning
the smallest addressable unit on the machine, not an 8-bit
quantity, so a byte could also have 16 or 32 bits or even 9
on some strange machines).


But then alignment isn't your only problem - there's also the
question of endian-ness. And, of course, neither a short, an
int or a long long need to have the same size on two different
architectures (and even if the result of sizeof is the same on
two machines this doesn't guarantee that the values have the
same number of bits). And things get even more interesting if
you throw floating point types into the mix;-)

The usual way to store data so that they can be exchanged
reliably between different systems (unless you want to re-
strict yourself to the exchange between systems for which
you know exactly how data are stored) is to convert  the
data to and store in ASCII.


Since it's rarely useful it's probably not really troublesome,
unless you're trying to use it for something it was not meant
for.
                              Regards, Jens
-- 
  \   Jens Thoms Toerring  ___       XXXX@XXXXX.COM 
   \__________________________       http://www.**--****.com/

by **Spoon** » Wed, 04 Jul 2007 19:27:58 GMT






Which architecture?


What's cc?

$ ls -l `which cc`


What size in bits do you expect for a char?
for a short?
for an int?
for a long long?

You might want to use the types defined in stdint.h
 http://www.**--****.com/ 


You might try asking on the GCC mailing list.

by **Keith Thompson** » Thu, 05 Jul 2007 04:37:32 GMT

"Jimmy" < XXXX@XXXXX.COM > writes:


[...]

That's hardly surprising:

% cat /etc/redhat-release 
Red Hat Enterprise Linux WS release 3 (Taroon Update 8)
% ls -l /usr/bin/cc
lrwxrwxrwx    1 root     root            3 Apr  2 16:20 /usr/bin/cc -> gcc

-- 
Keith Thompson (The_Other_Keith)  XXXX@XXXXX.COM   < http://www.**--****.com/ ~kst>
San Diego Supercomputer Center             <*>  < http://www.**--****.com/ ~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Why #pragma pack() not take effect?

Why #pragma pack() not take effect?

Jump to:

Next

Why #pragma pack() not take effect?

Re: Why #pragma pack() not take effect?

Re: Why #pragma pack() not take effect?

Why #pragma pack() not take effect?

Re: Why #pragma pack() not take effect?

Re: Why #pragma pack() not take effect?

Re: Why #pragma pack() not take effect?

Similar Threads:

Who is online