Potent Portability?

Everyone writes portable code … right?  Or maybe your code is not as portable as you think it is.  Consider the lowly type-cast.  Do you know what is happening when you do a type-cast in your code?

The C99 and C11 standards address this issue in detail, but the standards may surprise you.

Let us start with an easy one:  convert a uint8_t variable to a uint16_t variable.  Section part 1 of C11 states:

When a value with integer type is converted to another integer type other than _Bool, if the value can be represented by the new type, it is unchanged.

Okay, seems straightforward enough.  That covers many other cases including uint8_t to int16_t, uint8_t to uint32_t, uint16_t to int32_t, and so on.  Even though this is straightforward and the value is unchanged, it is not necessarily a “free” operation as the process will often require instructions to perform sign extension.  So keep that in mind if your code is space or time critical (e.g. an ISR).

But what about other changes of signed-ness, or shortening the bit-length, or some combination of both?  In this case, the value is not able to be “represented by the new type”.  Part 2 of states:

Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type.

So when converting a value to uint8_t, the resultant value is found by repeatedly adding or subtracting 256 until the value is between 0 and 255, inclusive.  The situation is the same for uint16_t and 65536, and so on for other types.  Note that this works for signed or unsigned values as the original type.  Also note that this does not describe the functionality of the compiler or the resultant machine code, but only the mechanism to know the resultant value. Any number of tricks can be used by the compiler to get to the correct value (e.g. truncation).

We have one more case, and part 3 of covers that:

Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised.

Wow, really!?!?  This says that a cast to a signed value in which the original value is not able to be represented in the resultant type is implementation-defined … i.e. it is not portable.  Now go back to that first paragraph again … is your code as portable as you thought it was?

Am I suggesting abolishing all type-casts to signed integers?  Certainly not.  Some might argue that the behavior is well-established in 95% of compilers and processors but keep in mind that both the 2nd and 3rd cases above result in a potential loss of information and should thus not be flippantly ignored.  Other considerations that can matter when dealing with type-casting involve endianness or the signedness of char, as well as all manners of implicit casting that take place in an operation involving multiple types.  So keep vigilant about your types and type-casting and do your best to create more portable code.



Featured DISTek Expert




Software Engineer

Technical Strengths:

MATLAB, Model Based System Design (MBSD) with Simulink & Stateflow modeling, MATLAB tool design, developing MiL/SiL tests using a common simulation testing framework.

Past Experience

Developed and maintained Simulink (SiL/MiL) model based engine system performance analysis automation tools. Developed tools for Simulink model integration and modification. Developed and integrated embedded code utilizing an AUTOSAR framework.

DISTek Employee Since:


What I love about my job:

I love the challenging tasks I encounter on a daily basis allowing me to learn something new every day while getting exposed to new tools & technology. Knowledgeable collaborations throughout the process help tasks get completed smoothly and adds valuable new connections. DISTek has a work culture that is flexible and adaptable to meet my work and family balance in life.

Click HERE to become a DISTek EXPERT!