What to consider when writing portable C? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 8 years ago.

Improve this question

I'm starting a pet project, aimed at portability. It's a simple platform game and i'm planning to compile this to many different platforms with different toolchains. The video/input/system stuff is already abstracted by having multiple video drivers, which i include based on ifdef's around my code. Each platform makefile has a define of the platform (DC, NDS, PSP, etc.) and then i include the proper video drivers, which are C files with various functions called around my code.

However, i'm not sure about other caveats of portable applications in C. Should i redefine stuff from the stdlib? u8, u16, u32 and s8, s16, s32, etc? What knowledge can you share with me for this project?

Answer 1

Writing in C is more or less portable as long as you make no suppositions about the sizes of your types and the pointers you use to access them. I personally prefer using the types defined in stdint.h (http://pubs.opengroup.org/onlinepubs/7999959899/basedefs/stdint.h.html) - this defines like uint8_t, uint16_t ... - but feel free to research more alternatives, such as types.h (from POSIX Standard: 2.6 Primitive System Data Types) which defines them as u_int8_t etc ...

Possibly, you will end up at the end defining your own types based on what you managed to mangle together from the various sources found on the net ... such as: game_int_16 ,game_int_32 ...

Answer 2

A portable program is a program that:

• only uses the features of the language and library defined in the C Standard
• does not invoke undefined behavior
• does not depend on unspecified or implementation defined behavior.

For a list of undefined, unspecified and implementation defined behaviors, you can go the C Standard C11, Appendix J (Portability issues).