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
