This is the sixth in a continuing series of blog posts describing simple coding rules that help keep bugs out of embedded C programs.
Rule: Whenever the width, in bits or bytes, of an integer value matters in the program, fixed width data types shall be used in place of char, short, int, long, or long long. The signed and unsigned fixed width integer types shall be as shown in the table below.
| Integer Width | Signed Type | Unsigned Type |
| 8 bits / 1 byte | int8_t | uint8_t |
| 16 bits / 2 bytes | int16_t | uint16_t |
| 32 bits / 4 bytes | int32_t | uint32_t |
| 64 bits / 8 bytes | int64_t | uint64_t |
Reasoning: The ISO C standard allows implementation-defined widths for char, short, int, long, and long long types, which leads to portability problems. Though the 1999 standard did not change this underlying issue, it did introduce the uniform type names shown in the table, which are defined in the new header file stdint.h. These are the names to use even if you have to create the typdefs by hand.
Coding Standard Rule #5
Coding Standard Rule #7
These rules are excerpts from the Embedded C Coding Standard book.
Tags: embedded, programming, safety, standards
Oops. Gotta watch those angle brackets when you’re writing for the Web.
Anyway, even though your reference to “stdint.h” got swallowed, I must agree: to me it’s by far the most useful feature of the C99 standard. I created my own version of that header for the C compiler I use for my Microchip work (Knudsen), and in my C++ code I use the Boost “boost/cstdint.hpp” library for the C++ compilers that don’t already have a stdint.h.It’s one less chance for confusion when I switch among the three or four different compilers I use regularly!
Indeed – coming up with your own stdint.h to use when you have a toolset that doesn’t have it isn’t very hard.I have one that I borrowed and modified from the public domain one in the MinGW toolchain. Also, Paul Hsieh has a portable one with a BSD license: http://www.azillionmonkeys.com/qed/pstdint.h