Dereference of null ptrs after an ERR has been executed

[Alexandre Julliard]

Jeff Latimer <lats at yless4u.com.au> writes:

> What is the policy for handling the dereferencing of pointers that have 
> previously been determined to be NULL and an ERR message has been 
> issued.  It seems that there are many cases where Coverity has found 
> that the test is made but the code falls through to the dereference.  In 
> a number of cases to a TRACE.  Are we trying to throw an exception in 
> these cases but assuming that the problem is unlikely and not worth 
> further handling.  Essentially, it seems that if this is the policy then 
> we can mark the Coverity entries as ignore.  In some cases it seems that 
> the only problem may be the TRACE and there is no other reference which 
> implies that an else may solve the problem ie.
>
> if (!ptr) ERR "msg"
> else TRACE

That sort of code doesn't make much sense. Either a null pointer is
valid input and it should be handled properly, or it isn't and there's
no point in having an ERR, we might as well crash and get a full
backtrace.

-- 
Alexandre Julliard
julliard at winehq.org