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