• Pros and Cons of fixed width types from C99's stdint.h
• Fixed width types for platform code and binary codecs
• Motivation for standard types for independent code
• Use of semantic typedefs
• Discriminating uintptr_t vs intptr_t vs void* vs size_t

General Portability

• If you choose fixed width types then there is less chance of code breaking when moved onto a different platform
  • I think that's a fallacy.
  • Where we're needlessly using INT16? or UINT16?, we're actually trying to guarantee that int hold a 16-bit value. That's already guaranteed by the C standard anyway.
  • Similarly with INT32? or UINT32?, where the C standard guarantees a long will hold the necessary values.
  • Consider also the CHAR8?*, UINT8?*, string.h mess we've got. It really would be simpler to use plain char for strings.

Overflow

• Using standard types int and char is only ok if you are absolutely sure that they are never going to overflow under any circumstances / platforms / compilers.
  • Overflow applies just as much to fixed-width types - if we're going to do any arithmetic on a fixed-width type, we still have to bounds check it.

Linking to standard libraries

• There's a huge advantage to standard types in being able to link against different standard libraries without vigorous sprinklings of bug-hiding casts.
• Systems programmers have gone to the effort of abstracting the underlying platform in implementing a standard library - it seems wasteful to ignore that.

Guarantee of existance

• [u]int[8|16|32]_t are not guaranteed to exist - a library for an 8-bit micro *could* define only int8_t and uint8_t.
• All compliant libraries are required to define [u]int_least[8|16|32]_t however, so maybe we ought to use those... :)

Static type checking

• it gives Lint a greater chance of picking up errors.
  • Nope, lint already knows about the width of the platform's standard types.
  • If we want better checking we should use purely-semantic typedefs (e.g. typedef UINT16? CRC16?_T) more and turn on lint's strong type checks.

Performance

• As for the performance hit, we are talking about code that has to run efficiently on a 16-bit embedded micro, if that code is then ported to a PC platform then speed of execution is hardly going to be an issue.
  • Agree. The performance advantage is negligeable.
  • But why prevent the compiler from doing its job?