Alexandre Julliard wrote:
Aurimas Fišeras aurimas@gmail.com writes:
Alexandre Julliard wrote:
We only want it when an actual app depends on it, otherwise we'd have to add exception handlers in all functions. Note that the Windows behavior often varies across versions too.
So why are we fixing various "Possible NULL pointer dereference" errors reported by Coverity?
That's different, it's for cases where inspection of the code flow demonstrates that a NULL dereference can actually happen. In this case it would mean that some other part of the Wine code calls RegSetValueExA with a NULL pointer.
But that "some other part of Wine" was possibly called from external program via windows API?
Most likely the proper fix would then be in the caller.
I still don't see the clear difference between these cases.
If FunctionA calls FunctionW with (possibly) NULL pointer and FunctionW dereferences it we should fix FunctionA? But since FunctionA is windows API and it is far more likely to be called not from Wine itself but from "other programs", we don't fix neither FunctionA nor FunctionW, but expect that "other programs" will behave and won't call neither FunctionA nor FunctionW (nor FunctionX that calls FunctionA) with NULL pointers?
How to know when to fix NULL pointer dereferences if in most such cases code flow can be traced back to a windows API called by "other program"?