> Yes, but C doesn't really have a way to distinguish between:
> 
> typedef XXX foo;
> const foo *bar;
> 	wibble((foo *)bar);
> and
> 	wombat((int *)bar);
> 
> The former simply casts away const-ness, while maintaining the pointer 
> type.  The latter discards const-ness and changes the type.

And unfortunately:
int fubar;
	wombat((foo *)fubar));
doesn't generate any warings at all.

Similarly with (and other definitions from above):

extern void xyz(size_t);

	xyz((size_t)fubar);
requires the cast to keep the cmpiler quiet,
but that means that no error will be generated for:
	xyz((size_t)bar);
even though the latter is almost certainly wrong.

With a limited number of casts in code it is relatively easy to spot
ones that shouldn't be there.  As soon as you get the proliferation
of casts required to remove implicit integral conversions the chance
of spotting the odd, erronous one, is much, much, harder.

I've been known to convert 'char *' to 'unsigned char *' using:
#define UNCHAR(c) ((unsigned char *)0 + ((c) - (char *)0))
rather than a simple cast because it does the required type checking.

> I agree with that one to some extent, but some folk argue that return 
> types should always be checked  -- sometimes having exceptions would be 
> useful...

In general they should be checked, but there a some functions which
return a value that isn't an error status, and others where it really
isn't worth while.

Look at time(3), asprintf(3) as well as the usual culprit printf(3).
Also close(3), fclose(3) other takers?

	David

-- 
David Laight: david@l8s.co.uk