On Tue, 2019-05-21 at 16:28 +0200, Ján Tomko wrote: > On Mon, May 20, 2019 at 03:24:06PM +0200, Andrea Bolognani wrote: > > On Mon, 2019-05-20 at 14:59 +0200, Ján Tomko wrote: > > > Of course, there is a huge overlap between iterating over all devices > > > and just those with an info, but since the callers do request *Info* > > > I don't think they should expect it to be NULL. > > > > I realize that. I even toyed with the idea of renaming > > virDomainDeviceInfoIterate() to virDomainDeviceIterate() to get rid > > of the inconsistency, but I didn't feel like it would be worth the > > churn and though that documenting the expectations would be enough. > > I think there would be less churn that way, see my proposal: > Message-Id: <cover.1558448715.git.jtomko@xxxxxxxxxx> > https://www.redhat.com/archives/libvir-list/2019-May/msg00607.html Well of course you're avoiding most of the churn I was mentioning: you're adding a new function instead of renaming the existing one! That's cheating ;) I don't much like the idea of adding a separate function that does almost the same thing but not quite, because that will ultimately result in the same situation we have now: someone will add a new callback and (reasonably) expect it to be called for all devices, but that won't happen because the original code uses the DeviceInfo variant instead of the Device one. That's unnecessary friction. Not to mention that your new function also happens to iterate over all consoles, which the existing variant doesn't. That's an extra little inconsistency that we really don't need to introduce. So I still prefer my approach. As said earlier, I'm also not entirely convinced keeping the existing function name is a good idea, so I'll happily rename it at the same time as I'm updating and documenting its contract. Especially once that's done, I don't see any problem with passing the callback a pointer that might be NULL and expecting the user to check before using it, as that's par for the course when using the C language. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
