What prevents __attribute__((packed)) from getting into ISO C/C++?

Question

This is one of the most important reasons for me to use C/C++ in writing some classes of system software, but it's been nothing more than a compiler extension which happens to be very common. Why isn't the committee considering to support it officially? Was it incompatible with any clauses in the existing spec, such as Does public and private have any influence on the memory layout of an object?

Dumdum

Alignment, most importantly. – Georgeta

There's no such thing as "ISO C/C++". Even though the colloquialism "C/C++" is rampant and often understandable, when you're asking specifically about standardisation I would expect attention to such details. – Georgeta

@KerrekSB Here it appears to be short for "ISO C and/or ISO C++". This is perfectly ordinary English usage... I just used the word "and/or" but you wouldn't complain that there's no logical operator called "and/or". – Misdirection

@KerrekSB "Why aren't ISO/IEC JTC1/SC22/WG21 committee and ISO/IEC JTC1/SC22/WG14 committee considering to include it in their responsible specs?" Are you satisfied? – Dumdum

@nodakai: Why should they? Packing structures does not make much sense in general nowadays, unles you have a very space-limited systrem and even those often have alignment requirements. Enforcing packing would inclrease code/run time which often is even less desirable on such platforms. It is better to manually pack by ordering the members in the declaration from larger to smaller. For marshalling packing alone is insufficient, as it does not care about encoding or endianess. – Cohbath

@Olaf "Packing structures does not make much sense in general nowadays" If your life is OK without it, I'd not urge you to use it... But it is still very important for applications like TCP packet inspector. – Dumdum

@nodakai: Yes, but it seems arbitrarily pointless to ask for the joint opinion of two largely unrelated bodies. It's like asking "why don't my girlfriend and your boss like sushi?". – Georgeta

@Olaf You want a common, standard way of allocating data in memory, using a struct to partition the data is the simplest way of doing that. Ordering the data from large to small is completely irrelevant to this discussion (consider s struct contating uint32_t:2, uint32_t:2). If you still don't understand why it's needed, think about a register length of 128bit that has to be written entirely and correctly. What would be easier than representing this with a packed struct? In any case, I don't see how your comment is relevant to this question, if you don't see why use it, don't use it – Laughingstock

@nodakai: No it is not. As I wrote, there ae better and implementation-independent ways to marshl/unmarshal serialised data. I had enough rubbish code relying unneccessarily on such hacks. (I don't talk about systems you have to squench every clock cycle out of the CPU, these need additional compiler-specifics anyway.) – Cohbath

@IshayPeled: Did I miss they removed structs from the C standard? This is about adding implementation-specific stuff to a general standard successfully aimed at a plethora of very different platforms. There is more to C than x86 or ARM! – Cohbath

An ISO committee is just not up to a task like this, its role is to make the stake holders equally unhappy. Everybody solved this common need a different way, equal unhappiness is only achieved by adding a 10th way to do it. A "benevolent dictator" can do this sort of thing, no good candidates in C and C++ land. – Redneck

@HansPassant Maybe Olaf it up to the job (; – Laughingstock

Answer 1

Why isn't the committee considering to support it officially?

Because nobody proposed it. The closest thing to such a proposal was N3986 (PDF), which only works for bitfields. The comments from the discussion suggest that the committee would be interested, but they want to understand what existing practice does before trying to move forward on standardizing it.

Since then, whomever was responsible for that proposal decided not to continue to pursue it.

Lyrebird