On Tue, Aug 02, 2022 at 01:39:31PM +0200, Marek Marczykowski-Górecki wrote: > On Mon, Aug 01, 2022 at 10:36:07AM +0100, Daniel P. Berrangé wrote: > > Generally we want to see errors triggered from new enums arriving, > > as it can be a sign that libvirt code needs a semantic change in > > order to continue operating correctly. It isn't always correct > > to assume that the 'default' case gives the correct behaviour. > > Isn't that the exact purpose of 'default' label? If use of 'default' > means "any of the other 5 specific values, but lets save some characters > to not name them explicitly", then IMHO better to name them > explicitly... > > I can see a value of -Werror=switch-enum when adding new (internal) enum > value, to find all the cases where code needs to be adjusted, but even > then a grep is probably sufficient enough. On the other hand, if there > are cases where indeed all the values of (internal API) enum needs to be > handled explicitly, maybe simply omit 'default' label and use > -Werror=switch? > > Anyway, if tracking all the enums values of all the used 3rd-party APIs > is desirable (like, noticing when libxl adds new disk type), then it > probably should be a separate CI job, not the default devel build. > Otherwise breakages like this will happen from time to time, and will > be annoyed for people on involved in specific code part at all. > > As a short term fix, maybe Xen's CI can build libvirt with > -Wno-error=switch-enum? I think makes sense for a 3rd party CI todo that, since these warnings are primarily targetted at libvirt upstream maintainers, so that we catch problems before code is committed. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
