Re: [PATCH][4.15] gnttab: work around "may be used uninitialized" warning

[Jan Beulich <jbeulich@xxxxxxxx>]

On 11.03.2021 09:25, Roger Pau Monné wrote:
> On Thu, Mar 11, 2021 at 09:09:22AM +0100, Jan Beulich wrote:
>> On 10.03.2021 18:52, Julien Grall wrote:
>>> On 10/03/2021 16:21, Jan Beulich wrote:
>>>> On 10.03.2021 15:58, Julien Grall wrote:
>>>>> On 10/03/2021 10:13, Jan Beulich wrote:
>>>>>     2) A compiler will not be able to help us if we are adding code
>>>>> without initialized vaddrs.
>>>>>
>>>>> It also feels wrong to me to try to write Xen in a way that will make a
>>>>> 10 years compiler happy...
>>>>
>>>> As said above - we've worked around limitations quite a few times
>>>> in the past. This is just one more instance.
>>>
>>> I find amusing you wrote that when you complained multiple time when 
>>> someone was re-using existing bad pattern. :)
>>
>> Well, thing is - I don't view this as a bad pattern. The only question
>> really is whether NULL is a good initializer here. As per above a non-
>> canonical pointer may be better, but then we have quite a few places
>> elsewhere to fix.
> 
> Sorry for jumping in the middle but I think that would be a very
> dangerous move for Xen to do. We have been using implicit conversions
> of pointers to booleans all over the place, assuming that NULL ==
> false, hence NULL no longer mapping to false would break a lot of our
> code.  ie:
> 
> if ( foo )
>       free(foo);
> 
> Would no longer work as expected.

Funny you should give this example: Assuming you mean xfree(), it
specifically tolerates both NULL and ZERO_BLOCK_PTR (the latter
because xmalloc() may return it, and that's what it was invented
for). But yes - other non-NULL checking guards would indeed break.

I'm afraid every possible solution here has its downsides, and
the suggested change simply follows the pattern we used so far in
similar cases - without anyone objecting.

Jan