• 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?

SideBar