How portable does your code need to be?

[eryjus]

Hi,

I was thinking this evening, and this question came to mind. Now, I better define what I mean by 'portable' to eliminate confusion: I mean the ability for your code to compile using multiple compilers; I do not mean the ability of the compiled code to run on many different versions of hardware.

To date, I have tried to not use the compiler-specific features that are available in an effort to keep my code portable. But why? I have built a cross compiler. I do not intend to move it to another platform (well, not from Linux to windows, anyway; if I do, I will stay in the Linux family). So, I say to myself tonight: "Self, why are you being so stupid? Go ahead and use the GCC-specific features and make it your own."

So, have I just had an epiphany that is really common knowledge and I'm just catching up? Or, have a made a conceptual leap that I shouldn't have and really should try to stay away from these compiler specific features?

Thanks!

[Combuster]

There's a few things that you should be aware of:
- GCC is an aging project, with LLVM competing in the high end and various embedded compilers in the low end. It might not be the default forever.
- Some of the "gcc" features are actually implemented by several open-source compilers, typically the ones that are notoriously missing from C99 like struct packing.

As far as you want to go with using compiler-specifics is in the end your choice, as there's enough to be said for either way.

[zeusk]

Hi,

I was thinking this evening, and this question came to mind. Now, I better define what I mean by 'portable' to eliminate confusion: I mean the ability for your code to compile using multiple compilers; I do not mean the ability of the compiled code to run on many different versions of hardware.

To date, I have tried to not use the compiler-specific features that are available in an effort to keep my code portable. But why? I have built a cross compiler. I do not intend to move it to another platform (well, not from Linux to windows, anyway; if I do, I will stay in the Linux family). So, I say to myself tonight: "Self, why are you being so stupid? Go ahead and use the GCC-specific features and make it your own."

So, have I just had an epiphany that is really common knowledge and I'm just catching up? Or, have a made a conceptual leap that I shouldn't have and really should try to stay away from these compiler specific features?

Thanks!

I often found myself in the same place, until i learned a trick from linux. You can use pre-processor defines as substitute for directly calling those gcc features and depending on the compiler, change their syntax or remove them completely by defining them in compiler specific header. It has worked with me till now more so since gcc is the main compiler I use.

gcc is old and can often create not-so great code compared to llvm/clang but If you're into embedded stuff you will often find manufacturers supporting gcc more than any other compiler. Infact until recently linux was gcc dependent which is being fixed by a few guys who are already able to compile it using llvm.

C preprocessor is a powerful tool, but abusing it in excess can cause headaches or files with more redundant compile time code than the actual code.

[Jezze]

I don't know if it is important but it can at least be fun to try different compilers and that could be reason enough to keep it portable. I tried to compile my kernel with tcc. It did compile but the binary didn't boot. Sad because that compiler is FAST and I really would have liked to use it. Around 9 times(!) the speed of gcc and about 7 times the speed of clang. I honestly thought the first time i had written ls instead of make.

[bluemoon]

For me, I try to keep things ordered:
- Things that are architecture specific (eg. inline assembly, plain asm, architecture specific task) are grouped, so that whenever a change is needed it's easily spotted.
- Compiler specific stuff are minimized, except a few common features like structure packing, that can be easily port to other compiler by #define or /string/replace/
- Try not to abuse ABI, but when its abused (like when doing syscall), make it easy to be spotted.

I do not enforce absolute portable, but my idea is to keep things in order so my life is easier when I need to support another compiler.

[Nessphoro]

Structure padding, can be easily done with #pragma. And its portable between GCC and VSC++ compilers.

[JamesM]

Structure padding, can be easily done with #pragma. And its portable between GCC and VSC++ compilers.

#pragmas are less portable than __attribute__'s, in my opinion. __attribute__((packed)) is not just a GNU extension, it's standardised by ARM in its ACLE (ARM C Language Extensions), so most compilers provide it.