Re: Structure size directives

Tor Rustad <tor_rustad@xxxxxxxxxxx> writes:
Keith Thompson wrote:
Tor Rustad <tor_rustad@xxxxxxxxxxx> writes:
[...]
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-5265/6n7c29ck7?l=en&a=view&q=pack

I've already expressed my opinion of this behavior (that it's a bug,
even if it's not a violation of the standard).

This isn't a SPARC only thing, in addition to Windows/MIPS, the
Microsoft compiler doc state this:

"Itanium: An application must explicitly call SetErrorMode with
SEM_NOALIGNMENTFAULTEXCEPT to have the system automatically fix
alignment faults. The default setting is for the system to make
alignment faults visible to an application." [1]

Sure, lots of CPUs don't allow non-aligned accesses, or at least don't
allow them without an extra effort.

[...]

In my opinion, if a compiler is going to support structure members
that don't have the alignment for the member's type, it's the
compiler's job to generate code that will access that member in a way
that (apart from performance and code size) is indistinguishable from
accessing an aligned member.

Well, I don't think most system programmers agrees with you, since
this leads to code bloat, hiding of translation details and do hurt
performance.

System programmers who are concerned about code bloat et al can just
not use packed structures.

C is close to a WYSIWYG language, which helps in generating compact,
predictable code, the language add little obfuscation for system
developers. The spirit of C, is to trust the programmer and not stop
him/her from doing exactly what asked.

If I instruct the compiler to do explicit alignment, that is what it
should provide. I can understand if application programmers don't care
much if the compiler generate some fix-up code to handle alignment
issues, but others don't want it.

Here's my point. Suppose a compiler allows a declaration like this:

struct foo {
char c;
int i;
};
#pragma pack(struct foo)
struct foo obj;
obj.i = 42;

Assume sizeof(int)==4, and int normally requires 4-byte alignment.
Assume that without the #pragma pack, "i" would be allocated at an
offset of 4 bytes, and with the #pragma pack, it would be allocated at
an offset of 1 byte (misaligned).

*If* the compiler supports this, then it had better let me access
obj.i by name without causing my program to crash. It can do whatever
it needs to do to make this happen; I don't much care about the
machine-code details, any more than I care about how it would access
obj.i if it weren't misaligned.

As a programmer, if I use "#pragma pack", I'm *explicitly* asking for
less memory usage at the possible expense of larger and slower code.
That's what it's for. If I don't want to accept the cost, I won't use
the pragma.

If I try to access obj.i and the compiler ignores the misalignment,
generating code that causes my program to blow up, then the compiler
has lied to me. It claims to implement packed structures, but it
really doesn't. And when the compiler sees a reference to obj.i, it
*knows* that it's misaligned.

Ok, maybe the documentation tells me to expect this, but a documented
bug is still a bug. And as I've said before, this wouldn't be a
violation of the standard; it's still a bug.

The same applies if, say, "#pragma STDC PACK" were made a part of a
future C standard. If the implementation or the language lets me
declare a member, it had better let me access it. If it won't let me
access it, it shouldn't let me declare it.

[...]

I've worked in languages that have the equivalent of packed
structures, and this is what they do.

And in such languages, packing comes with a price.. e.g. what could
have been done via a single load, now require two loads. In a HPC
cluster, you don't want such "packing" on a memory bound programs.

Of course it comes with a price.

I don't know that you wouldn't want such packing in an HPC cluster, or
on any other system; the savings in memory *might* outweigh the costs.
It's going to depend on the application, and it should be up to the
programmer.

Now if you want to argue that "#pragma pack" is a bad idea, I won't
necessarily disagree with you. I don't think I've ever used it
myself, and I don't necessarily advocate adding it to the standard.
I don't object either to providing the feature, or to leaving it out.
I object to implementing it badly.

--
Keith Thompson (The_Other_Keith) <kst-u@xxxxxxx>
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"
.

Relevant Pages

  • Re: Structure size directives
    ... When you target a specific architecture, the alignment requirements are know apriori, so system developers do make use of explicit alignment and knows what they are doing. ... struct foo obj; ... offset of 4 bytes, and with the #pragma pack, it would be allocated at ... There are really two different cases here, you talk about the usage of "pack" to minimize padding in a struct, while I talk about the "pack " usage, which specify alignmentof struct members. ...
    (comp.lang.c)
  • Re: Structure size directives
    ... the compiler as to how to layout structures, most compilers provide some ... Note that when you use #pragma pack, ... struct or union will be at the pack alignment. ...
    (comp.lang.c)
  • Re: A malloc question
    ... reliably store 100 chars followed by a struct in this memory, ... the alignment of p+100 may not be suitable for the struct. ... the paddings for memory alignment are ... malloc() will see a request of 24 byte allocation. ...
    (comp.lang.c)
  • Re: realloc() implicit free() ?
    ... block size as a request for one byte, and let the alignment mechanisms raise it as they will. ... is therefore suitably aligned for any type (`struct s' in particular), the value can be assigned to any type of pointer, and can then be used to access an object of that type. ... of the Standard can distort its meaning. ...
    (comp.lang.c)
  • Re: "free space" with declared type (alignment discussion)
    ... >>a function pointer member, a struct pointer member, and maybe a few ... > It doesn't put any extra constraint on alignment beyond this. ... > To assess actual alignment constraints, a structure might be used to figure how ...
    (comp.lang.c)