Re: [libvirt-go PATCH 2/2] Introduce DomainMigrateMaxSpeedFlags constant

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Feb 11, 2019 at 03:23:31PM +0000, Daniel P. Berrangé wrote:
> On Mon, Feb 11, 2019 at 04:11:55PM +0100, Erik Skultety wrote:
> > Also enforce the enum type for MigrateSetMaxSpeed and MigrateGetMaxSpeed
> > functions which previously accepted generic uint32 type since the flags
> > haven't been in use.
>
> FWIW, Erik asked me about this change off-list.
>
> Technically changing the flags parameter from uint32 to the named
> enum type is considered an API incompatible change. In practice
> though, the flags parameter was unused in the past, so applications
> should normally have been passing an untyped '0' inline.eg
>
>    dom.MigrateSetMaxSpeed(1024*1024, 0)
>
> Go will happily do type inference there, so with this change it will
> simply interpret '0' as being a value in the enum type. There should
> not be any compile breakage in this case.
>
> Where it could be a problem is if the app used an intermediate typed
> variable
>
>   var flags uint32
>   flags = 0
>   dom.MigrateSetMaxSpeed(1024*1024, flags)
>
> This could conceivably affect some app, but I think it is fairly
> unlikely since there's no compelling reason for the app to have used
> a variable for flags given that it was unused. On balance with previous
> cases like this I took the view that it is preferrable to change the
> enum type so we get better type checking over the long term, despite
> this small risk/

I'll include this in the commit message so that it doesn't get lost on the list
and is easier to be found.

Thanks,
Erik


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux