Splint

Originally Posted by Dave_Sinkula

So that mostly leaves us the WinAPI.

Well, some people are more comfortable having the casts there. Others are required to use them. Using explicit type casts does not make one an inferior programmer to one who does not use them, just as not using them does not make one inferior to one who uses them.

For some, it appears to be a religious issue.

It reminds me of those guitarists who look down on anyone who uses a capo. While it's true that transposition to any key can be done without a capo, for people who's technique depends on the voicing of the chords, a capo is required to get the correct chord shapes.

For some, explicit casts are an expression of their programming style.

Give it a rest!

We like to argue the fine print here.


Quzah.

Casts are a forced conversion, which basically amount to saying "STFU, I know what I'm doing".

Whilst this looks like the C idiom of "the programmer is always right", this is not the same as "the programmer knows what he is doing". The side effect of casting is that it essentially cripples any tools from being able to tell you anything meaningful about the code.

I too have worked on projects in the past where programs were cast to death, and the only reason was to ensure that the code compilied without warnings on all the compilers used on the project. The coding standard at the time merely stated that the code should "compile without warnings". Of course the cast was merely the easy way out rather than attempt to understand the underlying reason for the warning (or in some cases, actually bother to learn C in the first place).
Any moron can write warning free code in C if you cast every bloody expression in sight, but that doesn't make for easy to read code, bug free code or code which tools can analyse for bugs.

Well I'll take a cast over a compiler warning any day. If you have a large project, and avoid casts that remove warnings, then you pretty much make the compiler warning feature worthless. When I compile a library written by someone else and see 200+ warnings, it frustrates me. Sure, most (or all) of those warning are probably due to a lack of casts, but what if you have something like "x used without having been initialized" in there somewhere? It becomes easy to miss when it is just 1 of 200 warnings.

I always cast when the compiler tells me too, but not otherwise. Splint wanted me to cast my ints to doubles when I passed them to pow(), but that's a bit too much overkill for me. I try to keep my programs free of warnings, but I don't think I'm going to pay that much attention to everything Splint tells me. But still, I'll probably use it every now and then to get a second opinion, so to speak. In case I've overlooked something.

Thanks for all the replies, guys.
-tretton

Originally Posted by tretton

I always cast when the compiler tells me too, but not otherwise. Splint wanted me to cast my ints to doubles when I passed them to pow(), but that's a bit too much overkill for me.

That warning would tell me that I either should have declared the variables as doubles in the first place or that I should have made my own pow() function for ints.
Kurt

I have to admit that my first reaction to a warning that suggests that I need a cast is to look to see what I did wrong. It's generally fixable without the cast, though this probably depends somewhat on what kind of code you're writing.

Originally Posted by ZuK

That warning would tell me that I either should have declared the variables as doubles in the first place or that I should have made my own pow() function for ints.

Are you guys serious? I mean, it compiles without a single warning, it's just Splint that is a bit stingy. The prototype for pow() is double pow(double b, double p), so if I have two ints, a and b, and call pow(a, b) - this is bad?

Well, I installed splint just to see what you're talking about. I ran it on code I've been working on today, and this is my favorite "warning" from splint ...

Code:

sift2.c:104:11: Storage e->h3 becomes null

/* here's the line of code */
  e->h3 = NULL;

Hmm, no kidding ... it's null because I want to initialize it as such.

You have to understand what splint is good for ... it takes a paranoid look at your code and gives you the opportunity to review potential problems. If you have compiler warnings turned up and your code compiles without generating warnings, then it's okay from a syntax point of view ...

There's nothing wrong with using splint, but you have to interpret the results.

Originally Posted by tretton

Are you guys serious? I mean, it compiles without a single warning, it's just Splint that is a bit stingy. The prototype for pow() is double pow(double b, double p), so if I have two ints, a and b, and call pow(a, b) - this is bad?

Another point of view:

Code:

#include <math.h>

double foo(int a, int b)
{
   return pow(a, b);
}

Code:

test.c 5 error [Info 747] Significant prototype coercion (arg. no. 1) int to double
test.c 5 error [Info 747] Significant prototype coercion (arg. no. 2) int to double

Explanation in manual:

747 Significant prototype coercion (Context) Type to Type -- The type specified in the prototype differed from the type provided as an argument in some significant way. Usually the two types are arithmetic of differing sizes or one is float and the other integral. This is flagged because if the program were to be translated by a compiler that does not support prototype conversion, the conversion would not be performed.

So PC-lint flags this diagnostic as informational, and informs me of a potential error. Whether or not I as a programmer choose to understand the issue and/or correct it is up to me.