C / C++ best practices with signed / unsigned ints and function calls

Question

I am asking this question for two different languages: C and C++.

What is best practice when calling functions that have an opposite integer sign expectation to what we require in our code?

For example:

uint32       _depth;                        // uint32 = DWORD
int          depth;

_BitScanForward(&_depth, (uint32)input);    // DWORD, DWORD
depth = (int)_depth;

_BitScanForward is expecting DWORD (uint32) parameters. The variable input is of int16 type and I need to process the result _depth as an int32 in my code.

1. Do I need to care about casting input as shown? I know the complier will probably do it for me, but what is best practice?
2. Is it acceptable to declare _depth as int32 and therefore avoid having to cast it afterwards as shown?

NOTE:

My comment about the complier is based on experience. I wrote code that compiled with no warnings in VS but crashed on execution. Turned out I was calling a function with an incorect width int. So I don't leave this topic up to the compiler any more.

EDIT:

The answers are helpful, thanks. Let me refine my question. If there are no width issues, i.e. the function is not expecting a narrower int than what is being passed in (obvioulsy will fail), then is it okay to rely on the compiler to handle sign and width differences?

Answer 1

I would strongly recommend to hide that function into a custom wrapper function which agrees with your preferred API (and within this function do proper explicit casting). In the case of using compiler-specific functions this has the additional advantage that it will be much easier to port it to different compilers (should you ever want to do that), by just re-implementing that wrapper function.

Answer 2

It is very important to write an explicit cast when going from any integer type that is narrower than int to any integer type that is the same width or wider than int. If you don't do this, the compiler will first convert the value to int, because of the "integer promotion" rules, and then to the destination type. This is almost always wrong, and we wouldn't design the language this way if we were starting from scratch today, but we're stuck with it for compatibility's sake.

System-provided typedefs like uint16_t, uint32_t, WORD, and DWORD might be narrower, wider, or the same size as int; in C++ you can use templates to figure it out, but in C you can't. Therefore, you may want to write explicit casts for any conversion involving these.

Answer 3

Well It kind of depends on your usage etc:

If I can use the type which is needed I just use the type.

If not: Your compiler should warn you in the cases where you implicitly convert datatypes which may result in over/underflows. So I have those warnings on usually and change the implicit conversion to explicit ones.

There I have 2 different approaches:

If I am like 100% sure that I never over/underflow the boundaries between signed/unsigned int I use static_cast. (usually for conversion of different APIs. Like size() returning int vs size_t).

When I am not sure or it may be possible I am beyond the boundaries I use boost::numeric_cast. This throws an exception when you cast beyond boundaries and thus shows when this happens.

The approach with the exceptions adheres to the practice to fail hard/crash/terminate if something goes wrong instead of continuing with corrupt data and then crash somewhere else or do other things with undefined data.

Answer 4

First your compiler will make the casts implicit and will give you a warning on any meaningful warning level.

Both casts you perform are casts where the compiler (or your coworkers) cannot easily decide if they are correct, therefor an explicit casting or explicit conversion with a boundary test is best practice. Which you choose depends on your knowledge of the data. The safest way is to check boundary conditions. The cheapest way is to simply cast (in C++ please use static_cast not C-style casts).