Structure size directives

[jacob navia]

Since standard C doesn't provide any way for the programmer to direct
the compiler as to how to layout structures, most compilers provide some
way to do this, albeit in different forms.

Microsoft (and lcc-win) uses
#pragma pack(1)

Gcc uses
__attribute__ {(packed)}

Has anyone seen other directives in other compilers?

Specifically, Microsoft allows to pack structures with some integer
constant (pack(2) for instance), but gcc doesn't seem to allow this.

What other semantic differences could exist there?

I am writing this part of my tutorial, and I would like to make a table
about the constructs used by the various compilers. Note that under
windows you must know this kind of stuff since windows uses packed
structures extensively.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Walter Roberson]

In article <fj**********@a ioe.org>, jacob navia <ja***@nospam.o rgwrote:

>Since standard C doesn't provide any way for the programmer to direct
the compiler as to how to layout structures, most compilers provide some
way to do this, albeit in different forms.

>Microsoft (and lcc-win) uses
#pragma pack(1)

>Gcc uses
__attribute_ _ {(packed)}

>Has anyone seen other directives in other compilers?

http://techpubs.sgi.com/library/tpl/...04.html#Z26959

SGI IRIX

#pragma pack [n]

where [n] indicates an optional number 1, 2, 4, 8, or 16. The []
are not part of the syntax.

This differs from the Microsoft format in not having () and in having
a space after pack.
SGI includes these notes:

o SGI strongly discourages the use of #pragma pack , because it
is a nonportable feature and the semantics of this directive
may change in future compiler releases.

o A structure declaration must be subjected to identical
instances of a #pragma pack directive in all files, or else
misaligned memory accesses and erroneous structure member
dereferencing may ensue.

o References to fields in packed structures may be less efficient
than references to fields in unpacked structures.
--
"History is a pile of debris" -- Laurie Anderson

[jacob navia]

Walter Roberson wrote:

In article <fj**********@a ioe.org>, jacob navia <ja***@nospam.o rgwrote:

>Since standard C doesn't provide any way for the programmer to direct
the compiler as to how to layout structures, most compilers provide some
way to do this, albeit in different forms.

>Microsoft (and lcc-win) uses
#pragma pack(1)

>Gcc uses
__attribute_ _ {(packed)}

>Has anyone seen other directives in other compilers?

http://techpubs.sgi.com/library/tpl/...04.html#Z26959

SGI IRIX

#pragma pack [n]

where [n] indicates an optional number 1, 2, 4, 8, or 16. The []
are not part of the syntax.

This differs from the Microsoft format in not having () and in having
a space after pack.

Thanks Mr Roberson

>
SGI includes these notes:

o SGI strongly discourages the use of #pragma pack , because it
is a nonportable feature and the semantics of this directive
may change in future compiler releases.

o A structure declaration must be subjected to identical
instances of a #pragma pack directive in all files, or else
misaligned memory accesses and erroneous structure member
dereferencing may ensue.

This is obviously the same under windows. ALl files must see the same
directive.

o References to fields in packed structures may be less efficient
than references to fields in unpacked structures.

That is obvious too.

What would be nice is that standard C would allow this to be
defined in the language, with well defined semantics.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[CJ]

On 3 Dec 2007 at 21:11, jacob navia wrote:

> o References to fields in packed structures may be less efficient
than references to fields in unpacked structures.

That is obvious too.

What would be nice is that standard C would allow this to be
defined in the language, with well defined semantics.

Rubbish. Packing for structs is an implementation detail, and any
program relying on such details will be inherently non-portable.

[Walter Roberson]

In article <fj**********@a ioe.org>, jacob navia <ja***@nospam.o rgwrote:

>Walter Roberson wrote:

>SGI includes these notes:

> o A structure declaration must be subjected to identical
instances of a #pragma pack directive in all files, or else
misaligned memory accesses and erroneous structure member
dereferencing may ensue.

>This is obviously the same under windows. ALl files must see the same
directive.

Right, but it isn't the first thing that one thinks of when one
starts using #pragma pack, so it's probably worth mentioning
explicitly in the tutorial.
--
We regret to announce that sub-millibarn resolution bio-hyperdimensiona l
plasmatic space polyimaging has been delayed until the release
of Windows Vista SP2.

[jacob navia]

CJ wrote:

On 3 Dec 2007 at 21:11, jacob navia wrote:

>> o References to fields in packed structures may be less efficient
than references to fields in unpacked structures.

That is obvious too.

What would be nice is that standard C would allow this to be
defined in the language, with well defined semantics.

Rubbish. Packing for structs is an implementation detail, and any
program relying on such details will be inherently non-portable.

Its surely not a "detail".

If I have
struct foo {
int32_t val;
char *m;
};

Using normal packing rules in 64 bit systems, this makes
16 bytes, using "packed" layout it will be only
12 bytes. This is fully 25 percent of memory usage!

If I have 100 million of those, the difference is a whooping
25 million!

The fact that MANY (if not all) compilers give the programmer
a way to specify this is a testimnoy of the universal need
behind this.

P.S. It would be nice to avoid polemic... "Rubbish" means
here just that you do not agree with me I suppose

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Walter Roberson wrote:

In article <fj**********@a ioe.org>, jacob navia <ja***@nospam.o rgwrote:

>Walter Roberson wrote:

>>SGI includes these notes:

>> o A structure declaration must be subjected to identical
instances of a #pragma pack directive in all files, or else
misaligned memory accesses and erroneous structure member
dereferencing may ensue.

>This is obviously the same under windows. ALl files must see the same
directive.

Right, but it isn't the first thing that one thinks of when one
starts using #pragma pack, so it's probably worth mentioning
explicitly in the tutorial.

Yes!

Actually I will include text that says in essence exactly what SGI
says.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[CJ]

On 3 Dec 2007 at 21:48, jacob navia wrote:

Its surely not a "detail".

If I have
struct foo {
int32_t val;
char *m;
};

Using normal packing rules in 64 bit systems, this makes
16 bytes, using "packed" layout it will be only
12 bytes. This is fully 25 percent of memory usage!

If I have 100 million of those, the difference is a whooping
25 million!

The fact that MANY (if not all) compilers give the programmer
a way to specify this is a testimnoy of the universal need
behind this.

The best way for the compiler to give the programmer a way to specifiy
this is surely through a command-line option (for example, as part of an
"optimize for size" option) and not by adding pointless new keywords to
the language. It would be very bad if programmers started making
non-portable assumptions that a struct was packed, rather than using
offsetof and the other proper mechanisms provided by C.

P.S. It would be nice to avoid polemic... "Rubbish" means
here just that you do not agree with me I suppose

It means that the statement you made was obviously nonsense, and badly
thought-out.

[jacob navia]

CJ wrote:

On 3 Dec 2007 at 21:48, jacob navia wrote:

>Its surely not a "detail".

If I have
struct foo {
int32_t val;
char *m;
};

Using normal packing rules in 64 bit systems, this makes
16 bytes, using "packed" layout it will be only
12 bytes. This is fully 25 percent of memory usage!

If I have 100 million of those, the difference is a whooping
25 million!

The fact that MANY (if not all) compilers give the programmer
a way to specify this is a testimnoy of the universal need
behind this.

The best way for the compiler to give the programmer a way to specifiy
this is surely through a command-line option (for example, as part of an
"optimize for size" option) and not by adding pointless new keywords to
the language.

There is no keyword added:

#pragma is used for precisely that: unportable compiler directives.

gcc uses __attribute__ anyway in many other situations.

It would be very bad if programmers started making
non-portable assumptions that a struct was packed, rather than using
offsetof and the other proper mechanisms provided by C.

Then, excuse me but WHAT you propose when you do NOT want that
a structure is aligned? How would you do it?

Specifically in the case above, where you have a structure
several million times in RAM?

>P.S. It would be nice to avoid polemic... "Rubbish" means
here just that you do not agree with me I suppose

It means that the statement you made was obviously nonsense, and badly
thought-out.

OK. You have thought it out better than gcc/microsoft/sun/sgi/.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Tor Rustad]

[Better choice for subject, would be "struct padding ..."]

jacob navia wrote:

Since standard C doesn't provide any way for the programmer to direct
the compiler as to how to layout structures, most compilers provide some
way to do this, albeit in different forms.

Most C compilers? Out of how many?
Unaligned accesses to objects, should be banned. It has nothing to do
with portable C code, it might trigger a core dump on non-x86 CPU.

FYI, C++:

http://www.open-std.org/jtc1/sc22/wg...docs/n1262.pdf

--
Tor <bw****@wvtqvm. vw | tr i-za-h a-z>