0

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?

vinnylinux
  • 7,050
  • 13
  • 61
  • 127
  • and you searched online? – Mitch Wheat Feb 10 '14 at 13:04
  • Yes, i did. But i found many different approaches, some pretty complex and aiming at projects that include networking, filesystem access and so on. Even huge frameworks for portability. I don't have any of that, i'm looking for a minimal approach and some minor tips from people who already wrote portability-focused apps, specially on non-standard platforms. – vinnylinux Feb 10 '14 at 13:07
  • as you say, it's a big topic...(not my downvote BTW) – Mitch Wheat Feb 10 '14 at 13:08
  • Is your question specifically about `u8`, `u16`, `u32`, etc. What are these btw. If you want to define quantities for an 8-bit, 16-bit, etc unsigned or signed quantity, what's wrong with `uint8_t` and so on – Brandin Feb 10 '14 at 13:23
  • There are hundreds of cases in C that fall under the categories _unspecified_ and _implementation-defined_ behavior. So to answer the question, we'd have to write a whole book - the question is too broad. – Lundin Feb 10 '14 at 13:41

2 Answers2

3

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).

ouah
  • 142,963
  • 15
  • 272
  • 331
  • What you describe isn't a "portable" program, it's a standards-conforming program. If you plan to support more than one compiler, those two things are not the same. – Frerich Raabe Feb 10 '14 at 13:20
  • 1
    @FrerichRaabe what I describe is more or less the definition of a strictly conforming program and as C committee put it in the C99 Rationale document *"A strictly conforming program is another term for a maximally portable program*". – ouah Feb 10 '14 at 13:42
  • @FrerichRaabe Point 3 in this answer addresses all portability issues in a C program. And since there's such a number of crappy compilers out there, you really want to make the program strictly conforming as well. – Lundin Feb 10 '14 at 13:44
  • @ouch Except that's what the C99 document says, it's not the first specification of some sort which tries to define terms such as "standard" or "portable" without caring too much about reality (HTML specification, anyone?). To *actually* make a program portable, you just have to try it on a dozen different compilers and see how well they actually implement the specification. – Frerich Raabe Feb 10 '14 at 14:15
  • 1
    @FrerichRaabe The problem behind that is ISO. When they make an ISO standard, they have all these rules about being impartial. They cannot favour certain technologies that would give certain companies a market advantage. For example, the C standard couldn't favour the two's complement computers, that implement one byte as 8 bits. No, it had to support obscure mumbo-jumbo computers as well, in case Bob's garage company decides to make a 27 bit one's complement computer. Many cases of implementation-defined behavior in C seem to come from such politics. – Lundin Feb 10 '14 at 14:21
  • Which is more portable? C89 or C99? – vinnylinux Feb 11 '14 at 11:23
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 ...

Ferenc Deak
  • 34,348
  • 17
  • 99
  • 167
  • It's safe to say that stdint.h types will be stable? – vinnylinux Feb 10 '14 at 13:13
  • 1
    Considering that those have been in C standard for a while now, I'd say they are very stable. – user694733 Feb 10 '14 at 13:15
  • @vinnylinux No, I had problems with them using MSVS till the point that I had to manually create the file. See: http://stackoverflow.com/questions/126279/c99-stdint-h-header-and-ms-visual-studio – Ferenc Deak Feb 10 '14 at 13:16
  • @fritzone Doesn't the latest MSVS have those headers? It is not too hard to create that header, if using old compiler. It is a problem that will slowly disappear anyway. – user694733 Feb 10 '14 at 13:20
  • @fritzone It's because MSVS in C mode is a completely non-conforming compiler. If you compile with a real C compiler, it will have stdint.h. – Lundin Feb 10 '14 at 14:25
  • 1
    @Lundin I agree... however time has taught me to accept and deal with real life situation instead of the waiting for the next chapter in the saga of standard's conformance. – Ferenc Deak Feb 10 '14 at 19:06