[libvirt] [PATCH] conf: Fix initialization value of 'multi' in PCI address

Xian Han Yu xhyubj at linux.vnet.ibm.com
Fri Aug 12 10:17:48 UTC 2016



On 8/11/2016 9:54 PM, Martin Kletzander wrote:
> On Thu, Aug 11, 2016 at 10:46:28AM +0100, Daniel P. Berrange wrote:
>> On Thu, Aug 11, 2016 at 05:39:06PM +0800, Xian Han Yu wrote:
>>>
>>>
>>> On 8/11/2016 5:00 PM, Daniel P. Berrange wrote:
>>> > On Thu, Aug 11, 2016 at 10:55:44AM +0200, Andrea Bolognani wrote:
>>> > > On Thu, 2016-08-11 at 14:48 +0800, Xian Han Yu wrote:
>>> > > > > The default is not OFF, though, it's ABSENT :)
>>> > > > > In fact, as far as I can tell, OFF isn't ever used explicitly
>>> > > > > either for assignment or comparison. And false is plain wrong
>>> > > > > from a datatype point of view.
>>> > > > How about we change all three occurrences as boris list above
>>> > > > into VIR_TRISTATE_SWITCH_ABSENT.
>>> > > Sure, that's exactly what I suggested :)
>>> > IMHO, we should just do what Michael suggested right at the start 
>>> of this
>>> > thread and use  {0}, instead of manually initializing each field to
>>> > 0, or a constant hiding the 0.
>>>
>>> That maybe change back again in the future, if this struct add a new 
>>> member
>>> or current member need to be  not zero-initialized.
>>
>> Lets do what makes sense now, not in some hypothetical future that may
>> never happen.
>>
>
> {0} will initialize the whole struct to zeroes as if you did
>
>  memset(&s, 0, sizeof(s));
>
> and structures in libvirt are designed so that all zeroes are defaults
> unless there are virStructNew() functions that properly initialize the
> non-zero values.  So this will work as long as this structure is not the
> exception (in which case we need to redo all the initializations
> anyway).  That's why {0} is the nicest solution, IMHO.

OK, I understand, we will change these three initializations to {0}.

Regards,
Xian Han

>
> Martin (not Michal ;) )
>
>> Regards,
>> Daniel
>> -- 
>> |: http://berrange.com      -o- 
>> http://www.flickr.com/photos/dberrange/ :|
>> |: http://libvirt.org              -o- http://virt-manager.org :|
>> |: http://autobuild.org       -o- http://search.cpan.org/~danberr/ :|
>> |: http://entangle-photo.org       -o- http://live.gnome.org/gtk-vnc :|
>>
>> -- 
>> libvir-list mailing list
>> libvir-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/libvir-list
>
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160812/26440a4f/attachment-0001.htm>


More information about the libvir-list mailing list