On Tue, May 31, 2016 at 13:05:16 +0200, Michal Privoznik wrote:
> On 31.05.2016 12:52, Peter Krempa wrote:
>> On Tue, May 31, 2016 at 12:33:26 +0200, Michal Privoznik wrote:
>>> As unlikely as it might seem, func passed to this function can
>>> return NULL. And in some cases it indeed does so:
>>> virDomainDefGetVcpuSched and virDomainDefGetIOThreadSched.
>>> However, the function I'm fixing blindly dereference value func
>>> returned thus leading to SIGSEGV.
>>
>> Same as in the coverity case complaining about this it won't happen here
>> since we are iterating a known list of items that was collected
>> beforehand and thus no crashing will happen.
>>
>
> Well, having covery reports a false positive is one thing, being unable
> to compile is another one. This is what I was afraid of and expressed it
> here:
>
>
https://www.redhat.com/archives/libvir-list/2016-May/msg02063.html
>
> On the other hand, you use more recent compiler than I do, so you'll hit
> these error sooner O:-) IOW, one day we will have to deal with this. Again.
I'm thinking of disabling that warning at all since it's making us work
it around in cases where it clearly doesn't make sense. It's very
similar to the warning of comparison between signed and unsigned.
Is it? What about the following code:
char *c = NULL;
*c = 'a';
Should you get a warning here or not? I would like to see a warning. But
I agree that it is a question of personal preference.
Michal