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**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:

>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**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:

>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**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:

>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-hyperdimensional
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**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:

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

[Al Balmer]

On Mon, 3 Dec 2007 23:07:11 +0100 (CET), CJ <no****@nospam.invalid>
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.

Actually, I prefer a pragma, since it can be applied to structures
where it's needed, while not messing up the rest of the program. To be
done right, there needs to be a compile-time test which tells you
whether the implementation supports it.

As far as I'm concerned, memory savings is not usually an issue, but
forcing a structure layout to meet some external constraint may be.

--
Al Balmer
Sun City, AZ

[CJ]

On 3 Dec 2007 at 22:23, jacob navia wrote:

There is no keyword added:

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

gcc uses __attribute__ anyway in many other situations.

Yes, and relying on this sort of thing is a bad idea if you're trying to
write portable code.

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

I think a struct will always be aligned at least as strictly as the
alignment required by its first member.

>>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/.

Probably gcc/etc. want to allow the programmer to decide *for each
individual struct* whether it should be packed or not. This approach
will create terrible maintenance headaches - the pack/don't pack
directive will need to be present each time the compiler sees a
declaration of the struct.

[jacob navia]

CJ wrote:

On 3 Dec 2007 at 22:23, jacob navia wrote:

>There is no keyword added:

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

gcc uses __attribute__ anyway in many other situations.

Yes, and relying on this sort of thing is a bad idea if you're trying to
write portable code.

Has it occurred to you that there are environments/situations where
you are more interested in getting the program to RUN is much
more important than writing it portably?

I have worked in DSPs where there was only 80K RAM, and of that 70K
was used by the modem software.

I had to run in 10K.

Or, you have to layout your structure according to EXTERNAL
requirements like passing it character-wise through a
serial interface, and at the other side you can't assume any
"alignment" wasted space, etc etc!

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

I think a struct will always be aligned at least as strictly as the
alignment required by its first member.

You are mistaken.

struct foo {
char a;
double b;
char c;
};

The double will be aligned (in many machines) into an 8 byte
boundary

>

>>>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/.

Probably gcc/etc. want to allow the programmer to decide *for each
individual struct* whether it should be packed or not. This approach
will create terrible maintenance headaches - the pack/don't pack
directive will need to be present each time the compiler sees a
declaration of the struct.

Obviously the compiler has to see the declaration of the structure, so
it is imperative to put everything related to it in the declaration.
This poses no problem at all if you write your structure declarations
in header files...

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

[Al Balmer]

On Mon, 3 Dec 2007 23:35:49 +0100 (CET), CJ <no****@nospam.invalid>
wrote:

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

Probably gcc/etc. want to allow the programmer to decide *for each
individual struct* whether it should be packed or not. This approach
will create terrible maintenance headaches - the pack/don't pack
directive will need to be present each time the compiler sees a
declaration of the struct.

No, only on the definition.

--
Al Balmer
Sun City, AZ

[CJ]

On 3 Dec 2007 at 22:51, jacob navia wrote:

Has it occurred to you that there are environments/situations where
you are more interested in getting the program to RUN is much
more important than writing it portably?

I have worked in DSPs where there was only 80K RAM, and of that 70K
was used by the modem software.

I had to run in 10K.

Or, you have to layout your structure according to EXTERNAL
requirements like passing it character-wise through a
serial interface, and at the other side you can't assume any
"alignment" wasted space, etc etc!

One of the main advantages of writing in C is that it is widely
portable. If you don't care about portability, then sure, write in
C+extensions and drop down to assembly if you want. The fact that people
sometimes need to write unportable code doesn't justify polluting
standard C with obscure implementational details.

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

I think a struct will always be aligned at least as strictly as the
alignment required by its first member.

You are mistaken.

struct foo {
char a;
double b;
char c;
};

The double will be aligned (in many machines) into an 8 byte
boundary

This example does not contradict in any way what I wrote.

>>

>>>>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/.

Probably gcc/etc. want to allow the programmer to decide *for each
individual struct* whether it should be packed or not. This approach
will create terrible maintenance headaches - the pack/don't pack
directive will need to be present each time the compiler sees a
declaration of the struct.

Obviously the compiler has to see the declaration of the structure, so
it is imperative to put everything related to it in the declaration.
This poses no problem at all if you write your structure declarations
in header files...

And if you happen not to follow this best practice, having a function
expecting to receive an unpacked struct and actually getting a packed
struct could lead to all sorts of subtle and hard-to-find bugs. Yuck!

[Al Balmer]

On Mon, 3 Dec 2007 22:46:06 +0000 (UTC), ro******@ibd.nrc-cnrc.gc.ca
(Walter Roberson) wrote:

>In article <fj**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:

>>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://docs.hp.com/en/B3901-90012/ch02s02.html

HP also uses

#pragma PACK n

where n is 1, 2, 4, 8, or 16. The reference there doesn't say how
to terminate the scope of a #pragma PACK . I have barely used HP
so I don't know if #pragma pack (lowercase) would be accepted.

Lowercase is OK. The scope is terminated by omitting the 'n',
reverting to the default alignment.

--
Al Balmer
Sun City, AZ

[Richard Tobin]

In article <44*********************@telenor.com>,
Tor Rustad <to********@hotmail.comwrote:

>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.

Obviously on such systems, for packing to be useful, the compiler must
do the work necessary to make it work, probably by using byte acesses
or special instructions.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[jameskuyper]

CJ wrote:
....

Probably gcc/etc. want to allow the programmer to decide *for each
individual struct* whether it should be packed or not. This approach
will create terrible maintenance headaches - the pack/don't pack
directive will need to be present each time the compiler sees a
declaration of the struct.

I don't see that as a significant problem. There should be exactly one
file containing a declaration of any given struct type, which is
directly or indirectly #included in every translation unit that needs
it. Therefore only one pair of pack/unpack directives is needed for
each struct type for which this is desired.

[jacob navia]

ja*********@verizon.net wrote:

CJ wrote:
...

>Probably gcc/etc. want to allow the programmer to decide *for each
individual struct* whether it should be packed or not. This approach
will create terrible maintenance headaches - the pack/don't pack
directive will need to be present each time the compiler sees a
declaration of the struct.

I don't see that as a significant problem. There should be exactly one
file containing a declaration of any given struct type, which is
directly or indirectly #included in every translation unit that needs
it. Therefore only one pair of pack/unpack directives is needed for
each struct type for which this is desired.

Microsoft scopes the packing directive with nesting

#pragma pack(push)
#pragma pack(4)
....
#pragma pack(pop)

gcc needs a declaration of packing for each structure.

Of course your remark is valid, this should be in the structure type
definition.

When you want several structures packed identically the Microsoft
syntax is slightly better.

Still I do not know if you can say
__attribute__ {(packed 4)} or not...
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Keith Thompson]

CJ <no****@nospam.invalidwrites:

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.

[...]

I don't think a command-line option is appropriate. It means that (a)
it applies to an entire translation unit, not to a single struct
declaration, and (b) it becomes *very* easy to compile one file with
the option and one without it, leading to different parts of the same
program having different ideas of how a structure is laid out. It
makes more sense for information about a type's representation to be
associated *in the source* with that type's declaration.

One possibility might be to provide a standardized pack pragma
*without* specifying exactly what it does, merely that it suggests
favoring space over performance when choosing the layout. Different
implementations, especially for different platforms, could handle it
differently, but it would be consistent within an application.
There's precedent for this in other languages (Pascal, Ada), and as an
extension in some C implementations.

Alternatively, the pack pragma (or perhaps another form of it) might
specify that there shall be *no* padding between members; member
access would have to use the equivalent of memcpy() in some cases.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

CJ wrote:

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.

I have come to the conclusion that Jacob looks only to the positive
aspects of a thought, and never considers the negative results or
consequences until far too late. I often do the same thing, but at
least I am occasionally willing to listen when the negatives are
pointed out.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

jacob navia wrote:

CJ wrote:

>jacob navia wrote:

.... snip ...

>>>
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".

Surely you mean "it's"?

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!

Since, having packed, you can no longer index arrays of these
beasties, please explain how you are going to address 100e6 of
them? Maybe you will allocate storage one at a time, and make an
array of those pointers? This will use up at least as much storage
as you have 'saved'. Of course the malloced pointers will each
waste at least as much storage as you saved in the individual
object. Net result, an extra 25% (or more) of memory usage.

BTW, whooping cranes whoop. Differences can whop. :-)

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

CJ wrote:

>

.... snip ...

>
And if you happen not to follow this best practice, having a
function expecting to receive an unpacked struct and actually
getting a packed struct could lead to all sorts of subtle and
hard-to-find bugs. Yuck!

Not yuck. I am getting all sorts of useful ideas for creating
unmodifiable C programs that are totally portable. Very useful.
Once I supply a few of these to the appropriate firms I suspect I
will have my health insurance etc. taken care of for the rest of my
life.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

jacob navia wrote:

CJ wrote:

>jacob navia wrote:

.... snip ...

>
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/.

Yes. Here, at last, is a statement we can agree with. :-)

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

jacob navia wrote:

>

.... snip ...

>
Has it occurred to you that there are environments/situations
where you are more interested in getting the program to RUN is
much more important than writing it portably?

I have worked in DSPs where there was only 80K RAM, and of that
70K was used by the modem software.

I had to run in 10K.

What did you do with all that space? I have often built systems
than ran in a total of 16k or less (see the 8008) (or see some 6502
systems) (or see small CP/M 8080 systems).

I suspect you should have reworked the modem software. Should have
been easy to cut it all down to a single 64k memory space.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[jacob navia]

CBFalconer wrote:

jacob navia wrote:

>CJ wrote:

>>jacob navia wrote:

... snip ...

>>>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".

Surely you mean "it's"?

>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!

Since, having packed, you can no longer index arrays of these
beasties, please explain how you are going to address 100e6 of
them?

Why I couldn't make an array of 12 byte structures???

This supposition is wrong, and the conclusions then, are
also wrong.

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

[CBFalconer]

jacob navia wrote:

CBFalconer wrote:

>jacob navia wrote:

>>CJ wrote:
jacob navia wrote:

... snip ...

>>>>
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".

Surely you mean "it's"?

>>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!

Since, having packed, you can no longer index arrays of these
beasties, please explain how you are going to address 100e6 of
them?

Why I couldn't make an array of 12 byte structures???

Because the normal indexing instructions multiply by sizes, which
are expected to be a restricted set (say 1, 2, 4, 8, 16).
Otherwise each address requires loading the index and size,
multiplying, adding the base address, then performing some loading
that also depends on the size. The X86 is especially likely to use
this, and I would have thought you to be fairly conversant with its
assembly language.

This supposition is wrong, and the conclusions then, are
also wrong.

No, it may be possible to overcome, but the effort is not
worthwhile.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[jacob navia]

CBFalconer wrote:

jacob navia wrote:

>CBFalconer wrote:

>>jacob navia wrote:
CJ wrote:
jacob navia wrote:
>
... snip ...
>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".
Surely you mean "it's"?

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!
Since, having packed, you can no longer index arrays of these
beasties, please explain how you are going to address 100e6 of
them?

Why I couldn't make an array of 12 byte structures???

Because the normal indexing instructions multiply by sizes, which
are expected to be a restricted set (say 1, 2, 4, 8, 16).

This is wrong. You can do arrays from structures of ANY size (at least
in lcc-win)!

struct f { char data[12];};

This is a perfectly valid structure and can be stored in an array
if the user decide to do so. And yes, I will generate the
corresponding assembly.

Otherwise each address requires loading the index and size,
multiplying, adding the base address, then performing some loading
that also depends on the size. The X86 is especially likely to use
this, and I would have thought you to be fairly conversant with its
assembly language.

???
So what?

I will load the index, multiply by 12, and add the base . And it will
work.

>This supposition is wrong, and the conclusions then, are
also wrong.

No, it may be possible to overcome, but the effort is not
worthwhile.

So, how would you do an array of the following struct?

struct f { char data[49];};

Structures can be bigger than 16...
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Kenneth Brody]

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.

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

Gcc uses
__attribute__ {(packed)}

Has anyone seen other directives in other compilers?

#pragma pack(push)
and
#pragma pack(pop)

This pushes and pops the current pack value, allowing you to surround
your packs with:

#pragma pack(push)
#pragma pack(4)
... your 4-byte packing structs here ...
#pragma pack(pop)

This will not affect any packing outside of your own definitions.

[...]

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.

Under Windows, I have seen (admittedly non-standard) header files
which wrap these for you, and they are available in Windows and
MS-DOS compilers from several vendors.

pshpack1.h -- pack to 1 byte
pshpack2.h -- etc.
pshpack4.h
pshpack8.h
poppack.h -- restore packing size

So, you can use this across multiple vendors' Windows compilers
such as:

#include <pshpack4.h>
... your 4-byte packing structs here ...
#include <poppack.h>

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[James Kuyper]

CBFalconer wrote:

jacob navia wrote:

....

>Why I couldn't make an array of 12 byte structures???

Because the normal indexing instructions multiply by sizes, which
are expected to be a restricted set (say 1, 2, 4, 8, 16).
Otherwise each address requires loading the index and size,
multiplying, adding the base address, then performing some loading
that also depends on the size. The X86 is especially likely to use
this, and I would have thought you to be fairly conversant with its
assembly language.

I'm curious - you claim it can't be done, then describe precisely how it
is actually done. How do you reconcile having these two thoughts at the
same time?
It is doable, and has actually been done, and it is done pretty much the
way you describe. It's inherently somewhat less time-efficient than
structures whose members are aligned for time efficiency rather than
space efficiency, but memory space/execution speed trade-offs are
nothing new in the computer field.

[Ben Bacarisse]

jacob navia <ja***@nospam.comwrites:

Still I do not know if you can say
__attribute__ {(packed 4)} or not...

Well off-topic now, but you keep giving the wrong syntax. It is:

__attribute__ ((packed))

The double brackets allow attributes to be #defined away even when
using a pre-processor that does have variable arg macros. To get fine
control over the details of the packing you use the 'aligned' or
'aligned(n)' attribute either on the whole structure or on individial
members within it.

--
Ben.

[Richard]

CJ <no****@nospam.invalidwrites:

On 3 Dec 2007 at 22:23, jacob navia wrote:

>There is no keyword added:

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

gcc uses __attribute__ anyway in many other situations.

Yes, and relying on this sort of thing is a bad idea if you're trying to
write portable code.

"if".

Clearly, to use your phrase, you are not thinking this through. The type
of packing we are talking about is invariably NOT used in a portable
scenario anyway. In addition your comment about command line is fairly
silly - only certain structs need this type of packing and not the
entire module.

[REH]

On Dec 3, 4:23 pm, CJ <[e-mail]:

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.

Why is this non-portable? The Ada standard (and, thus, compilers)
have done this portably for years.

REH

[santosh]

REH wrote:

On Dec 3, 4:23 pm, CJ <[e-mail]:

>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.

Why is this non-portable? The Ada standard (and, thus, compilers)
have done this portably for years.

It not portable in C. Ada is totally different.

[REH]

On Dec 4, 11:45 am, santosh <[e-mail]:

REH wrote:

On Dec 3, 4:23 pm, CJ <[e-mail]:

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.

Why is this non-portable? The Ada standard (and, thus, compilers)
have done this portably for years.

It not portable in C.

You miss my point. The post I replied too suggested there was not a
way to do it portable. Obviously, it is currently not portable in C.
That does not imply there is not a way to make it portable in the
standard (though whether it should be it a different argument, and not
one I care about).

Ada is totally different.

Thank you, I am aware of that fact.

REH

[Richard Heathfield]

santosh said:

REH wrote:

>On Dec 3, 4:23 pm, CJ <[e-mail]:

>>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.

Why is this non-portable? The Ada standard (and, thus, compilers)
have done this portably for years.

It not portable in C. Ada is totally different.

I don't know Ada, but I guess I can guess, right? It is quite possible that
Ada makes structure packing portable by picking one strategy and insisting
on it. If so, well, yes, that would work. C, on the other hand, does not
do this (and in a different way, that works too, but it can be a trap for
the unwary).

Depending on your programming needs and preferences, you might call this an
obstacle to portability, or you might call it a sensible unwillingness to
place arbitrary restrictions on implementations.

In practice, the various struct packing strategies are not a serious
obstacle to portability. My approach is to ignore them completely except
where data interchange formats (eg file formats) are at stake, at which
point I recognise that I need to put a layer between the struct and the
point where data exchange occurs (whether it's a socket or a file or
whatever), so that I can sidestep the issue altogether.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[REH]

On Dec 4, 12:19 pm, Richard Heathfield <[e-mail]:

I don't know Ada, but I guess I can guess, right? It is quite possible that
Ada makes structure packing portable by picking one strategy and insisting
on it. If so, well, yes, that would work. C, on the other hand, does not
do this (and in a different way, that works too, but it can be a trap for
the unwary).

Depending on your programming needs and preferences, you might call this an
obstacle to portability, or you might call it a sensible unwillingness to
place arbitrary restrictions on implementations.

In practice, the various struct packing strategies are not a serious
obstacle to portability. My approach is to ignore them completely except
where data interchange formats (eg file formats) are at stake, at which
point I recognise that I need to put a layer between the struct and the
point where data exchange occurs (whether it's a socket or a file or
whatever), so that I can sidestep the issue altogether.

OT:
Ada has what are called representation specifications (rep. specs.).
You can define, down to the bit, where fields are laid out and how big
they are. I believe the latest standard (which I am only mildly
familiar with) also allows for defining endian. There can, of course,
be alignment issues. We have one compiler that allows anything, and
will create "fix up" code to workaround alignment issues, and another
that will not. So, it is not a perfect solution. But it is great
when you have to explicitly define an interface to another language,
hardware, etc.

REH

[Keith Thompson]

CJ <no****@nospam.invalidwrites:
[...]

Probably gcc/etc. want to allow the programmer to decide *for each
individual struct* whether it should be packed or not.

Of course. You don't want that capability?

If packing is controlled by a command-line option, as you suggest, it
will also affect structs declared in system headers. That would be
incredibly messy.

This approach
will create terrible maintenance headaches - the pack/don't pack
directive will need to be present each time the compiler sees a
declaration of the struct.

Having more than one definition for the same struct already creates a
terrible maintenance headache. The solution, with or without packing,
is to define a struct exactly once (in a header file if it needs to be
visible in more than one translation unit).

If something like #pragma pack became standard, it would in effect be
part of the struct definition, to be specified exactly once. As long
as the compiler generates correct code to access the struct and its
members, I don't see a problem. Like inline or register, it could
even be ignored with no change to the semantics of the program (unless
the program makes assumptions about the layout).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

CJ <no****@nospam.invalidwrites:
[...]

Probably gcc/etc. want to allow the programmer to decide *for each
individual struct* whether it should be packed or not.

Of course. You don't want that capability?

If packing is controlled by a command-line option, as you suggest, it
will also affect structs declared in system headers. That would be
incredibly messy.

This approach
will create terrible maintenance headaches - the pack/don't pack
directive will need to be present each time the compiler sees a
declaration of the struct.

Having more than one definition for the same struct already creates a
terrible maintenance headache. The solution, with or without packing,
is to define a struct exactly once (in a header file if it needs to be
visible in more than one translation unit).

If something like #pragma pack became standard, it would in effect be
part of the struct definition, to be specified exactly once. As long
as the compiler generates correct code to access the struct and its
members, I don't see a problem. Like inline or register, it could
even be ignored with no change to the semantics of the program (unless
the program makes assumptions about the layout).

[I accidentally posted this through rr.com; I'm re-posting through
aioe.org. Sorry if you see this twice.]

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[santosh]

Keith Thompson wrote:

<snip>

It seems that the UDP on rr.com has been lifted, as I can read this post
on Motzarella.org.

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

santosh said:

>REH wrote:

>>On Dec 3, 4:23 pm, CJ <[e-mail]:
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.

Why is this non-portable? The Ada standard (and, thus, compilers)
have done this portably for years.

It not portable in C. Ada is totally different.

I don't know Ada, but I guess I can guess, right? It is quite possible that
Ada makes structure packing portable by picking one strategy and insisting
on it. If so, well, yes, that would work. C, on the other hand, does not
do this (and in a different way, that works too, but it can be a trap for
the unwary).

I do know Ada, and that's not quite how it works.

Ada provides two ways to affect the layout of a record (equivalent to
a C struct), pragma Pack and record representation clauses.

If you specify

pragma Pack(Some_Type);

then the *recommended* behavior of the compiler is:

If a type is packed, then the implementation should try to
minimize storage allocated to objects of the type, possibly at the
expense of speed of accessing components, subject to reasonable
complexity in addressing calculations.

(There's a bit more to it than that.)

In C, a standardized "#pragma PACK" or "#pragma STDC PACK" could do
exactly the same thing. It would not impose any specific strategy,
and code that uses it could be just as portable as code that doesn't
use it, as long as it doesn't depend on the specific layout of the
structure.

It would mean that there would be two unspecified strategies for
structure layout, one to be used in the absence of the pragma, and one
to be used in its presence. It would merely be a suggestion to the
compiler, not unlike "register" or "inline". The purpose would be to
save space, not to match a particular externally imposed layout.

(An Ada record representation clause can specify the *exact* layout of
each member of a record. I don't think anyone has suggested such a
thing for C.)

Note: I'm not necessarily advocating standardizing a pack pragma for
C, just commenting on how it should be defined if it is standardized.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

santosh <sa*********@gmail.comwrites:

Keith Thompson wrote:

<snip>

It seems that the UDP on rr.com has been lifted, as I can read this post
on Motzarella.org.

I don't see it on aioe.org, though.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Al Balmer]

On Tue, 04 Dec 2007 12:25:24 -0800, Keith Thompson <ks***@mib.org>
wrote:

>(An Ada record representation clause can specify the *exact* layout of
each member of a record. I don't think anyone has suggested such a
thing for C.)

For my purposes, that would be the only variety of any use. I
generally wouldn't care as much about saving space as forcing a
particular layout.

--
Al Balmer
Sun City, AZ

[CBFalconer]

James Kuyper wrote:

CBFalconer wrote:

>jacob navia wrote:

...

>>Why I couldn't make an array of 12 byte structures???

Because the normal indexing instructions multiply by sizes, which
are expected to be a restricted set (say 1, 2, 4, 8, 16).
Otherwise each address requires loading the index and size,
multiplying, adding the base address, then performing some loading
that also depends on the size. The X86 is especially likely to use
this, and I would have thought you to be fairly conversant with its
assembly language.

I'm curious - you claim it can't be done, then describe precisely
how it is actually done. How do you reconcile having these two
thoughts at the same time?

It is doable, and has actually been done, and it is done pretty much
the way you describe. It's inherently somewhat less time-efficient
than structures whose members are aligned for time efficiency rather
than space efficiency, but memory space/execution speed trade-offs
are nothing new in the computer field.

I don't think I said "couldn't be done", but I may have said "a
pain" and "inefficient". Yes, there are cases when it has to be
done. But the idea is to avoid them.

Jacob is working with a machine that is especially forgiving of
misalignment, the X86. Also, failing to keep an eye on the code
generated for simple operations leads to C++ bloat.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[Flash Gordon]

jacob navia wrote, On 03/12/07 19:45:

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.

<snip>

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.

If the library headers are written properly then you should not need to
know about the packing because just including win.h (or whatever) should
sort it all out for you.

Of course, on one occasion I did debug a problem for someone at work
which was caused by a header doing this type of stuff not working
properly in Borland C++ Builder. I have vague memories that it was a bug
in the version of the header provided specifically for Borland, but it
is years ago so I could be wrong.

Anyway, I would recommend leaving this type of stuff for an "advanced"
chapter clearly labelled as covering implementation specific extensions
which should only be used when actually required (and yes, I accpet that
sometimes you need to know about this sort of thing).

Oh, and I've used compilers where there was no concept of "packed"
because there was no penalty for any alignment.
--
Flash Gordon

[Chris Torek]

>In article <fj**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:

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

(As someone else noted, this should use double parentheses, not
parentheses within braces.)

>>Has anyone seen other directives in other compilers?

In article <fj**********@canopus.cc.umanitoba.ca>
Walter Roberson <ro******@ibd.nrc-cnrc.gc.cawrote:

>http://docs.hp.com/en/B3901-90012/ch02s02.html

HP also uses

#pragma PACK n

where n is 1, 2, 4, 8, or 16. ...

As this shows, there is another problem here. What are the
constraints on the "n" in PACK n or pack(n)? Is the "n" required
to be a power of two, or is it a number that specifies a power of
two, or is it something else entirely?

There are also "align" directives, which are different from "pack"
directives; and some compilers may have "endian" directives,
especially on CPUs that are endian-ambidextrous, as it were. (The
SPARC in particular can specify an endianness with each load or
store. This endianness is XORed with the current CPU endianness
and the MMU per-page endianness; all three are separately specified.)

>... on the other hand, the messiness also gives an indication as
to why it might not be as easy as expected to standardize a single
#pragma pack

Indeed.

In any case, "pack" and "align" directives are the wrong solution,
or at least, an insufficient solution. If you really want to solve
the problem in general, you should provide a complete "representation"
specification. You must decide, in the process of defining your
representation specification, whether to allow for non-contiguous
spans, how many bits can be in a value, and how many bits can be
spanned. You should also decide whether to allow for "forbidden"
combinations. For instance, if the actual bit layout is:

bits 0, 4, and 143: specify an unsigned value between 0 and 7

bit 1: unused

bits 2, 3, 5, 6, 7: specify an unsigned value between 0 and 31,
but values between 16 and 23 are invalid

bits 8 through 35: unused
bits 36 through 71: specify a signed 36-bit value (this is a
36-bit CPU)
bits 72 through 142: specify an unsigned 71-bit value

will your compiler support this, and if so, how?
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[jameskuyper]

CBFalconer wrote:

James Kuyper wrote:

....

I'm curious - you claim it can't be done, then describe precisely
how it is actually done. How do you reconcile having these two
thoughts at the same time?

It is doable, and has actually been done, and it is done pretty much
the way you describe. It's inherently somewhat less time-efficient
than structures whose members are aligned for time efficiency rather
than space efficiency, but memory space/execution speed trade-offs
are nothing new in the computer field.

I don't think I said "couldn't be done", but I may have said "a
pain" and "inefficient". Yes, there are cases when it has to be
done. But the idea is to avoid them.

You said:

Since, having packed, you can no longer index arrays of these
beasties, please explain how you are going to address 100e6 of
them? ...

You didn't say it would be a pain or inefficient for an implementation
to support indexing into an array of packed structures. You said, flat
out, that it couldn't be done.

Jacob is working with a machine that is especially forgiving of
misalignment, the X86. Also, failing to keep an eye on the code
generated for simple operations leads to C++ bloat.

Packed structures are certainly more expensive on machines that are
less forgiving of misalignment. Anyone choosing to use packed
structures should understand that they are, in effect, telling the
compiler that memory space is significantly more important to them
then execution speed; if they don't actually feel that way, that's
their mistake. I've seen compilers for several other architectures
that had this feature; I doubt that they did so purely as an
advertising gimmick. I've never tested that feature on any of those
compilers, so I can't be sure, but I presume that any such compiler
would generate code with at least minimally acceptable efficiency even
when processing data in packed arrays; otherwise they wouldn't offer
the option.

[Tor Rustad]

Richard Tobin wrote:

In article <44*********************@telenor.com>,
Tor Rustad <to********@hotmail.comwrote:

>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.

Obviously on such systems, for packing to be useful, the compiler must
do the work necessary to make it work, probably by using byte acesses
or special instructions.

IMO, "packing" should be avoided anyway. On architectures with alignment
requirements, it's a terrible idea to use e.g.

#pragma pack(1)

"If you use #pragma pack to align struct or union members on boundaries
other than their natural boundaries, accessing these fields usually
leads to a bus error on SPARC."
- http://docs.sun.com/app/docs/doc/819...&a=view&q=pack

Furthermore, it's a rather bad idea on most RISC architectures, it's a
fault. The system may, or may not mask the fault. Typically, unaligned
access will *at least* give a performance penalty, as it do on x86.

Windows, typically mask such alignment faults on the x86 by default,
except for [1]. However, this don't always need to be the case, for e.g.
MIPS, the MSDN doc state an explicit Win32 call was needed:

SetErrorMode(GetErrorMode() | SEM_NOALIGNMENTFAULTEXCEPT);

to make Windows automatically do the fix-up on alignment faults.

MIPS is a rather exotic case, but programmers shouldn't expect that x64
will be so forgiving to alignment faults, as x86 has been. Don't be
surprised if the penalty become significant bigger in this case.
[1] IIRC, unaligned access to 128-bit SSE/SSE2-based "types" trigger GPF.

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

[CBFalconer]

REH wrote:

CJ <[e-mail]:

>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.

Why is this non-portable? The Ada standard (and, thus, compilers)
have done this portably for years.

The last time I looked there were considerable differences between
the C standard and the Ada standard. I see no reference to packing
in the C standard.

This also illustrates the foolishness of discussing non-standard
compiler features in this newsgroup.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

ja*********@verizon.net wrote:

CBFalconer wrote:

.... snip ...

>
You said:

>Since, having packed, you can no longer index arrays of these
beasties, please explain how you are going to address 100e6 of
them? ...

You didn't say it would be a pain or inefficient for an
implementation to support indexing into an array of packed
structures. You said, flat out, that it couldn't be done.

You snipped my statement, as follows:

>" No, it may be possible to overcome, but the effort is not
" worthwhile.

which is not "flat out, that it couldn't be done". In other
words, I cavilled in advance.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com