Re: Type Safety cleanup diff

[Robert Love <rml novell com>]

< if ((data = g_object_get_data (G_OBJECT (dialog), "data")))
> if ((data = (DialogCBData *)g_object_get_data (G_OBJECT (dialog), "data")))

I actually do not like this sort of "type safety".  It is needed in C++,
where the void pointer promotion rules are different, but in C it just
hides bugs.

Let's take an example,

	struct foo *p = bar ();

If bar() returns a void pointer, this code is fine.  Let's say we do the
typecast, anyway

	struct foo *p = (struct foo *) bar ();

We are still fine, of course.  In neither case do we emit a warning and
in both cases the compiled code is the same.  We've just added
verbosity.

Now let's assume that bar() is changed to return a bar structure.  Or,
even, that is always returned a bar structure.

Now the first example generates a warning, correctly, telling us that
bar and foo are not the same thing.  The second example, however, no
longer generates a warning.  We have successfully hid an API breakage
from the compiler by forcing the typecast--a typecast that was not
needed!

One more example:

	char *p = malloc (1369);

In lieu, we can force the typecast, which is needed on C++:

	char *p = (char *) malloc (1369);

Now presume that <stdlib.h> is not included, which is amazingly and
disgustingly common.  The first example will return "int to pointer
conversion" warnings.  The second example, sadly, will not.  We hid the
fact that malloc() is not defined.

So all these sorts of typecasts do are hide bugs.  They never improve
the code.  They never stop warnings.  So, in C, I don't see the point.
I wish C++ did not have the void pointer promotion rules it has, either.

Dan might feel differently, though.  ;-)

In general, I am all for clean up.  I love getting the compiler to
generate more warnings and fixing those warnings.  But this case ain't
it.

	Robert Love