10

Every C compiler offers the option to "pack" C structures (e.g. __attribute__ ((__packed__)), or #pragma pack()). Now, we all know that packing is required, if we'd like to send or store data in a reliable way. This must also have been a requirement since the first days of the C language.

So I wonder why packed structures are not part of the C language specification? They're not even in C99 or C11 even though the necessity of having them is known for decades now? What I am missing? Why is it compiler specific?

|improve this question
  • 2
    They aren't necessary to write pure C code. – user253751 Aug 16 '14 at 9:23
7

I guess it's because it's depending on the combination of target CPU / compiler used. This means that it's better to be a compiler directive (as it's related to that) than a language aspect, because how to spec that? The only way they could do it is with union.

Raymond's article gives some insight in why this is: http://www.catb.org/esr/structure-packing/

|improve this answer
  • Very interesting article. (+1) – Giorgio Aug 16 '14 at 9:11
  • What difficulty would there be in allowing code to say "I need a structure holding 12 bytes; field X must behave as a 32-bit integer stored as four octets little-endian at offset 0; field Y must behave as a 64-bit integer stored as octets bytes little-endian at offset 4"? Code to handle that on any platform shouldn't be any worse than the kind of thing compilers already have to for bitfields, and in cases where the programmer happens to specify alignment that matches the native machine could be much more efficient. On other machines, it would be less efficient but still portable. – supercat May 25 '16 at 15:24
5

There are three main factors.

  1. Some processors cannot access unaligned data (for example an integer or float starting on an odd address). Attempting to do triggers an exception.
  2. Some processors can access unaligned data, but at a performance cost.
  3. Most structures are accessed by a single set of C/C++ source code, and interoperability with other languages is the exception, not the rule.

With these factors in mind, both the standard and all C/C++ compilers routinely pad structures to ensure optimal alignment for the processor, but also provide mechanisms to override this if needed for the purposes of interop.

This is by no means something that has been overlooked. It is extremely well understood and the current situation is by design. The latest versions of the C++ standard have extensive support for handling alignment issues, which perhaps you are not familiar with.

|improve this answer
  • Any argument that could be made against packed structures could also be used to justify making bitfields an optional feature. Accessing members of packed structures would be slow on some processors, fast on others, but having compilers try to replace user-code workarounds for the lack of unaligned-access features with more efficient code is far more complicated than simply having compilers let programmers specify what they need. – supercat May 25 '16 at 15:18
  • @supercat: what are you arguing for (or against)? I don't get it. – david.pfx May 28 '16 at 13:56
  • I'm of the opinion that bitfields should be optional, but if bitfields are going to be a mandatory feature then it would make sense to extend them in a way that allows explicit control of struct layout. Otherwise, the net effect is that compilers have to do 90% of the work that would be needed for full control of layout, but programmers only reap 10% of the benefit. – supercat May 28 '16 at 17:11
  • @supercat: bit-fields are integers and follow the same bit layout ordering rules as integers: implementation defined. Struct members are ordered on character boundaries as declared, possibly with packing inserted. They are conceptually quite separate. [You'll need to ask another question if you want to expand on your proposal, but I don't think it would work at all.] – david.pfx May 29 '16 at 14:31
0

It is compiler-specific because it is not in the standard. And it's not in the standard because it would be difficult to specify in a way that wouldn't require lots of implementation effort for compilers of obscure platforms with enforced alignment restrictions.

And none of that effort has much justification, because every compiler/platform that anyone using a C89 or later compiler cares about already has it implemented.

|improve this answer
  • 2
    ??? You answered to the question "Why is not in the standard language" by saying "because is not in the standard"... – Emilio Garavaglia Aug 16 '14 at 9:41
  • That's what I thought first, but then again, one could specify the feature like "if struct is defined with the keyword 'packed' its size is guaranteed to be the same as the added size of each individual member. on platforms that do not support unaligned memory access, access to one of the struct member values is undefined behaviour." This would allow developers on platforms without unaligned access to at least know the structs size and the offset of each individual member... – grasbueschel Aug 16 '14 at 9:54
  • 1
    It would be possible to make unaligned access work on systems that don't support it in hardware by implementing such structs as an array of bytes and performing the necessary bit-shifting and &/| operations to read/write the values of each field. – dan04 Aug 16 '14 at 17:06
  • 1
    @dan04: On many processors, a compiler could generate code for unaligned access that was more efficient than using a sequence of byte reads and shifts. Having a syntax for that would make it easier for such compilers to generate efficient code than requiring them to recognize all the different way programmers might try to write code to assemble bytes into longer types. – supercat May 25 '16 at 15:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.