Using compiler features vs "the hard way"

[Fanael]

I admit I never worked on the ARM, so I am ignorant of its alignment requirements.

It's not about ARM only, it's about majority of architectures being currently in use - the exceptions are x86, PowerPC in big-endian mode, some newer ARMs, and pretty much nothing else.

[JamesM]

The problem is that there's no portable way to do that, (even with defines thanks to pragma pack).

__attribute__((packed)) is supported by all mainstream compilers and is a de facto standard.

[Solar]

__attribute__((packed)) is supported by all mainstream compilers and is a de facto standard.

Ah?

Which compilers other than GCC support that syntax? None that I know of...

[JamesM]

__attribute__((packed)) is supported by all mainstream compilers and is a de facto standard.

Ah?

Which compilers other than GCC support that syntax? None that I know of...

Clang, the ARM Compiler, IIR...

[Solar]

I could make the same claim for "#pragma pack(1)", which is supported by GCC and MSVC alike. Does that make it a "de facto standard" too?

[Brynet-Inc]

__attribute__((packed)) is supported by all mainstream compilers and is a de facto standard.

Ah?

Which compilers other than GCC support that syntax? None that I know of...

PCC, Clang/LLVM..

[Owen]

Standard conforming:

Code: Select all

#include <stdalign.h>

struct MyPackedStruct alignas(char)
{
    int firstMember alignas(char);
    short secondMember alignas(char);
    ....
};

Not portable, however (though it is posisble to define alignas in terms of MSVC __declspec(aligned) and GCC __attribute__((aligned)).) For C++, "alignas" is a native operator.

[Solar]

OK, I admit that I heard of those compilers but didn't use them.

So, let's see... I couldn't find good docs on the Altera IIR, so I'll drop that one.

__attribute__((packed)) is supported by GCC, Clang, LLVM, xlC, and PCC.

#pragma pack(1) is supported by GCC, Clang, LLVM, xlC, PCC, and MSVC.

So much for "de facto standards".

[Fanael]

__attribute__((packed)) is supported by [...] LLVM

#pragma pack(1) is supported by [...] LLVM

LLVM is not a C compiler - if anything, it's the compiler of its own assembly language. Therefore it doesn't support any C constructs, let alone non-standard ones.

Sure, there are compilers that use LLVM as their backend, but you mentioned both of them already: llvm-gcc is simply GCC with the added ability of emitting LLVM IR and using LLVM pipeline (it doesn't change the frontend), and Clang is the LLVM's native compiler.

So what do you mean by "LLVM"?

[bubach]

After some googling I suspect that #pragma pack() is way more compatible across compilers. GCC, Turbo C, MSVC, Watcom and lots of others has support for it. It's much more a de facto standard than __attribute__((packed)). Since I had a hunch it would be supported on anything but GCC I was actually surprised to see this text in the GCC manual: "For compatibility with Microsoft Windows compilers, GCC supports a set of #pragma directives...". Who would have thought.

[Civillian]

I am confused about #pragma pack().
Does it affect the compiler settings for each file, or just for the file where it was found?

Edit: I found this, according to which only the struct declaration following the pragma is affected.

[Solar]

Nononono...

As far as there can be a "specification" for anything following "#pragma" (which, by definition, is implementation-defined), "#pragma pack(1)" affects all structures following the directive in the current translation unit.

Check out the relevant part of the GCC docs. Especially the part about "#pragma pack()" resetting the alignment to whatever it was when translation began should clear things up.

[JamesM]

Nononono...

As far as there can be a "specification" for anything following "#pragma" (which, by definition, is implementation-defined), "#pragma pack(1)" affects all structures following the directive in the current translation unit.

Check out the relevant part of the GCC docs. Especially the part about "#pragma pack()" resetting the alignment to whatever it was when translation began should clear things up.

Yep, and GCC doesn't really support #pragma push/pop, which would help here. In general I favour __attribute__ over #pragmas. Even though __attribute__ is a GNU extension, all compilers implement it for compatibility and dont complain about it in strict modes. #pragmas just scream nonportable to me.

Sure, there are compilers that use LLVM as their backend, but you mentioned both of them already: llvm-gcc is simply GCC with the added ability of emitting LLVM IR and using LLVM pipeline (it doesn't change the frontend), and Clang is the LLVM's native compiler.

So what do you mean by "LLVM"?

You're being pretty pedantic here. Clang is the C language frontend for the LLVM compiler infrastructure and falls under the LLVM project umbrella.

[Solar]

GCC doesn't really support #pragma push/pop, which would help here.

Uh... the link I gave says it does?

Even though __attribute__ is a GNU extension, all compilers implement it...

...with the exception of MSVC...

#pragmas just scream nonportable to me.

No more or less than __attribute((pack))__.

But I will shut up now. I don't have strong feelings one way or the other, I just try to drill a hole into GNU things wherever I can.

[Fanael]

You're being pretty pedantic here. Clang is the C language frontend for the LLVM compiler infrastructure and falls under the LLVM project umbrella.

Yes, I know I'm pedantic and I know Clang is their own frontend. Still, Solar mentioned both Clang and LLVM as if they were distinct compilers. This can be pretty confusing to people who are not familiar with LLVM project family.