On 18 Feb 2011, at 13:12, Black, Michael (IS) wrote:

> I'm of the opinion that all such warnings should be permanently fixed.  Such 
> warnings do point to potential problems.
> And not by disabling the warning but by fixing the code (explicit casts for 
> example).

It's been a while since I last did multiplatform C development, but in 2005 I 
found that MSVC and the HP-UX compiler were always brilliant at pointing out 
'problems' which almost never mattered while missing severe (crash-causing) 
issues which were found by IBM's xlc, GNU GCC and clang.

> How many people try this and get worried about possible problems?  If you 
> simply fix the code once all those people will feel a whole lot better when 
> they crank up the warnings and see nothing.

There are plenty of cases which cause a warning from one compiler but if 
'fixed' in the obvious way will cause another warning from a different 
compiler: it becomes a case of whose warnings you want to get rid of.

> I went through this exercise myself for SQLite at one point and looked at 
> each and every warning to try and determine if there was a possible error 
> caused by all the miscasts.

Adding casts to get rid of warnings is usually the wrong answer in my 
experience. Certainly you should never cast the return value of a function call 
because that hides the problems you get when it's implicitly returning int 
because a required header is missing. I used to see a lot of C code (usually 
from Windows programmers - does MSVC encourage this?) which has stuff like this 
all over the place:

        struct something *fred = (struct something *)malloc(sizeof(struct 
something));

Casting the return from malloc is never necessary - void * is assignable to any 
non-function pointer type by definition.

It becomes an extremely bad idea when you're building on a platform with 64-bit 
pointers and a 32-bit int (such as everything I use) and you have the optimiser 
turned on – in this case if <stdlib.h> isn't included none of your allocations 
will work properly and your program will crash.

Best Regards,

Phil Willoughby
-- 
Managing Director, StrawberryCat Limited

StrawberryCat Limited is registered in England and Wales with Company No. 
7234809.

The registered office address of StrawberryCat Limited is:

107 Morgan Le Fay Drive
Eastleigh
SO53 4JH

_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to