FixedWidthTypes

default

markdown

---
title: FixedWidthTypes
---

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

Uploading file...

Sidebar

Edit message:

Cancel

Editing FixedWidthTypes

Sidebar