Writing portable C

My point was that "portable" isn't a binary thing. Sure, you could write C code that will run on anything from a PDP11, through an Android smartphone, up to the latest supercomputers, but do you really need to do that? By being pragmatic about what platforms you're actually targeting you can write code that is portable within that feature set, giving yourself and the compiler more opportunities to optimise for the platforms that 99% of your users will be using.

You can't compile the linux kernel with a Sun C compiler. Does that mean it's not portable?

 

I agree with Glitch. At some point you need to be realistic and target a class of platforms you actually care about. I think the real thing that is a problem is a lack of open-source / lack of maintenance of code-bases. Just because you use a more portable int type, doesn't mean you're going to recompile it for everyone. The code still needs to be available.
—and this is why typedefs are useful.

 

If you're planning on targeting those specific compilers, you could add checks for those versions and define your own integer types instead of using stdint.h:

Code (Text):

1. #ifdef _MSC_VER
2. #if _MSC_VER < 1900
3. typedef unsigned char uint8_t;
4. /* ... */
5. #else
6. #include "stdint.h"
7. #endif
8. #else
9. #include "stdint.h"
10. #endif

 

I disagree that 'portable' is not binary. Though, perhaps 'portable' is just too vague a word. My preference is to write code that adheres to the C standard, invoking no undefined behaviour nor relying on optional features. That way, my code is universally portable to any platform that provides a standards-compliant C implementation. To me, if it is written in C, but cannot be compiled with a C compiler, then it is not portable C.

Regardless, whether you disagree with BenoitRen's definition of 'portable' or not, this thread is about writing code that adheres to that standard of portability, not whether code should adhere to it in the first place. This is the typical StackOverflow behaviour of commenting on the question itself rather than answering it.

 

Premise: I know nothing about this particular scenario, and my C is rusty, so I might be talking out of my ass, but, can't you just use ANDs and ORs? Like:

Code (Text):

1. result = (long1 & 0xFFFF0000) | (long2 & 0x0000FFFF);

edit: I originally masked 8 bits out of 16 instead of 16 out of 32, thanks to Glitch for noticing, this is what I get when I post while half asleep.

 

I'm glad you pushed back on Stack Overflow behavior, although you forgot about all the incorrect answers that don't even compile :P

As far as adhering to C standards, I think it's hard to go wrong with using C99 when there's a C99 compiler for every platform known to man. Some folks will insist on strict ANSI C, but people are too used to having certain nice things:

1. Declaring their for loop counter in-line
2. Leaving "//" single-line comments
3. Not having to declare all their variables at the top of a function
4. Having a bool type.
5. Fixed-width integer types​

As far as using fixed-width integer types, this is the most incontrovertibly sound and fundamentally essential advice posted so far. It's also only possible to portably use fixed-width integer types in C99. Having been forced to use the Solaris Studio compiler in the past for SPARC and x86 Solaris, you could still claim portability to Solaris if you ask users to install GCC or Clang, which have binary distributions for some pretty old versions of Solaris and even z/OS.

I think the OP was just asking in a nutshell, "how can I minimize the amount of time it will take to add support for a new platform in the future?" Here's my crack at a straightforward, albeit intensely paranoid answer:

1. Stick to strict C99 in case you want to compile on a platform that doesn't support the latest version of GCC/Clang (e.g. SGI Irix). Make sure when you set the compiler flags on GCC/Clang that you explicitly set "-std=c99".

2. On your primary platform, set "-Wall -Wpedantic -Werror -Wextra -Walloc-zero -Wcast-align" to enforce compliance to the standard language spec, catch an OS-specific behavior (malloc(0)), and catch an arch-specific behavior (unaligned accesses).

3. Use the C standard library as much as possible and use POSIX only when absolutely necessary (e.g. for dealing with endianness). Never use Linux-specific or GNU-specific functions. Porting S&K Collection should not necessitate multithreading, so steer clear of pthreads and hthreads. For the same reason, don't send signals on POSIX platforms. Be sure to write a signal handler and make sure it behaves as similarly as possible to the Windows task manager ways of killing a process as possible.

4. If you're going to do anything OS-specific, compiler-specific (compiler intrinsics), or architecture specific (inline-ASM), remember to put a feature test macro around it (#ifdef) and to write some #else code that does the same thing more slowly. For example, if you write some code that does __sync_add_and_fetch, write an #else block that does a thread.

5. Don't convert ASCII characters to numbers and vice versa. I learned this the hard way when my code didn't work on z/OS, which uses EBCDIC. (EDIT) You won't have to deal with EBCDIC, but you don't know for sure whether your code page will be UTF-8 or just plain-old ASCII.

6. Don't assume the size of a struct (e.g. sizeof(my_struct)) will be the same on all platforms. Some platforms force structs to be word-aligned instead of byte-aligned if the processor in question doesn't support unaligned memory access (e.g. POWER/PPC arch).

7. Always use fixed-width integer types instead of long and short when you need a 64-bit or 16-bit integer.

8. Should you find yourself saving binary data to a file, always write it out in big-endian format just as TCP and IP packet metadata is big-endian. Be prepared to define your own inline functions for converting to/from big/little endian as needed.

9. Remember to use the volatile keyword when working with any kind of buffer that could be shared between the CPU and some other piece of hardware acceleration.

10. Factor your graphics and sound code as separately from your game logic as humanly-possible, because this will necessarily have to be rewritten for other platforms.

Bonus. Contrary to one of OP's points, you can safely use unions. Just don't try to use them for C++-style inheritance + dynamic polymorphism. Here's an example where they are necessary:

struct tiny_rpc {

enum {

error=-1,
unknown=0,
hello=1,
goodbye=2,
text=3​

} type;
union { // IIRC, anonymous unions are part of C99

struct hello {...};
struct goodbye { ... };
struct text {...};​

};​

};​

I can edit with more stuff I remember from my experience writing code that ran on Linux, AIX, Windows, Solaris, z/OS, HP/UX, and FreeBSD if it pops up in my head, but I think this would reduce your portability problems by about 95%.

Appendix: Also, if you ever need to spawn a child process, then never fork without exec'ing and don't do anything in between fork() and exec(), as Windows doesn't have fork(). Just use posix_spawn() to achieve the same behavior as Windows process spawning. I put this in "appendix" because porting S&K Collection doesn't involve spawning child processes.

 

Interesting that you say that and then go on to repeat the exact same argument that we've been making. Nobody is saying "don't write portable code"; we're saying "work out what you mean by 'portable' and then write code that fits that definition".

To answer the question: what nineko suggests will work (reinterpret it as an unsigned long and mask with 0xFFFF0000). It's technically not "portable", as per Clownacy's definition, becuase it assumes 2's comp arithmetic but, realistically, it will work on any platform you can get your hands on.

Edit to add: note that we're assuming long is 32bits here which, again, is not strictly portable. It's usually either 32 or 64 bit. You can pick an appropriate mask based on the size of long

 

Slow your roll there, brother man! I wasn't talking about anything someone said in this thread, just Stack Overflow itself.

I just really hate Stack Overflow because it's a piss poor surrogate for well-thought out documentation, and it's a cesspool of Dunning-Kruger hackers who gatekeep people who just want to make stuff that makes the world a better place. More so, I hate it because I'm fixing code full of snippets of bad Stack Overflow answers copied verbatim right now.

I saw the posts about doing bit manipulations on signed integers, and I was satisfied with other peoples' answers, absent context on why bit hacking is necessary.

FWIW, I read Clownacy's blog post proscribing the use of fixed-width integer types, and I think it's based on the assumption that the code using it is performance-critical all or at least most of the time. Given the "culture" of C programming I think it's a fair assumption and his advice when followed will reduce the amount of bad code in the world. However, there are other important reasons to use C99 in 2024, chiefly that you can write a program with no external dependencies: only what your OS's libc gives you. This alone justifies writing core utilities like ls, cat, awk, etc. in C99. Fixed-width integer types in conjunction with trapping overflow/underflow is a good way to detect bad behavior in test cases. For a QUIC implementation or software implementations of IP, UDP, and TCP, it's a more expressive way to explain what's what and is a more intuitive way to use inline functions that convert big endian to host endianness.

As far as recommendations not to use C99 because of Microsoft's politically-driven refusal to adopt C99 in MSVC, I think using Clang on Windows for portability's sake is less painful than writing ANSI C,

 

I thought that's the direction you were going because you mentioned trying to support as many compilers as possible and MSVC < 2015 not having support for the full C99 spec.

When you asked about portability, I wasn't sure if you were trying to just be as compatible as possible with future platforms and platforms that currently receive maintenance, or if you wanted to leave the door open for discontinued platforms like pre-Vista Windows NT or Windows 9x.

Speaking of discontinued platforms, are you only targeting platforms that guarantee hardware floating point support and use virtual memory, or are you interested in embedded platforms like Nintendo DS/3DS? The amount of work you need to do to remain portable varies depending on your answer.

Also, are you interested in WebAssembly? That has some idosyncratic rules of its own as well, in which case you will not be able to read/write save and config files directly, but will need to write some JavaScript code to do it for you and then make C calls to that JS code.

Now that I think about it, if you targeted your decomp to WebAssembly, that could be a panacea for portability (not that I tried it before). Anything that can run Firefox or Chromium could run your C code.

 

You're right, I was half asleep and I masked 8 bits out of 16 instead of 16 out of 32, thanks for proofreading it for me and for confirming that it would work!

I'll amend my original post to rectify my mistake.