Search of explicit type conversions in C style: a = (int)b;

Question

I have a question concerning the benefit of this diagnostic. One user suggested that we implemented search of all the explicit type conversions in C style in the PVS-Studio analyzer. That is, a diagnostic to detect constructs of this kind:

int *x = (int *)y;
float a = float(b);
float c = (float)(d);

Its purpose is to replace all these conversions with their safer versions - reinterpret_cast/static_cast/const_cast. During the process of such refactoring, some defects in code may well be detected.

Of course, this is not detection of crucial errors, and if we implement this diagnostic, it will be in the section [Customer's Specific Requests] and disabled by default.

But I even doubt the benefit of this diagnostic. So I decided to ask other users: does anybody else need this option of searching for explicit type conversions in C style? Would anybody like to perform this kind of refactoring in their code?

Answer 1

A common view (eg expressed by Stroustrup ) is that C-style casts are apt to hide errors. I assume that these views would motivate quite a number of people not to use them, so a anti-C-cast diagnostic would get some usage, I guess. I personally wouldn't care to do it because I avoid C-style casts anyway, but given legacy code, I'd find the search useful.

Answer 2

I would even go further, casts in general are a bad thing and code that uses them a lot is suspicious. This certainly the case for C, where the rules of implicit conversions that may happen is very limited and well defined by the language.

C++ is a bit more complicated because of overloading, but still, you shouldn't need much explicit casts. A design should always be such that there is one unique path to cast one type into another.

Cast are bad, because they easily hide problems if the type of the expression that is cast changes. In your example if y is changed from a pointer type to an integer type for example. But in any case C++ style casts are much better, be it alone that they are easier to search for, and that are really a pain to type, to people would naturally avoid them :) And just try to forbid reinterpret_cast completely or at least it should be really rare.

Answer 3

I understand the motivation of C++ cast in favor of C cast (essentially because C cast are sometime static_cast, sometime reinterpret_cast, with risk of surprises) but ... refactoring something that already works may introduce even unexpected bugs, simply because you may misinterpret what the original developer was going to do...

Unless you are reconsidering rewriting the logic (so you are not working "statement by statement", but also understanding the overall semantics), I will not do it.

Answer 4

does anybody else need this option of searching for explicit type conversions in C style?

yes. it's an easy means to introduce/hide bugs (eg the most direct update of your program may produce some warnings or errors).

i favor cpp style casts because they are eyesores, while c style casts are easily obscured (that is by design).

better yet, going through the process and fixing the programs to be typesafe (most casting is unnecessary in cpp) is often a better solution.

Would anybody like to perform this kind of refactoring in their code?

i got rid of all the old style casts and stuck with it along the way (some bugs as well). i am happier. depending on your codebase(s) and your level of trust of the developers that built it, it may not be a good use of time. it's a boring process, but time may end up being spent debugging the issues theta are masked (again, depends on the codebase).