On Fri, 21 Jan 2022, Michal Prívozník wrote: > On 1/20/22 18:23, Ani Sinha wrote: > > > > > > On Thu, Jan 20, 2022 at 21:29 Michal Prívozník <mprivozn@xxxxxxxxxx > > <mailto:mprivozn@xxxxxxxxxx>> wrote: > > > > On 1/20/22 16:48, Ani Sinha wrote: > > > > > > > > > > > > > > AKA kicking the can one more time 🙃 > > > > Well, I should have been more careful and not merge the patch in the > > first place. Changing API behavior is something we should never do. > > > > Looking at the code closer, it looks like all callers of this function > > would need to ignore the reported error so that their behavior is not > > changed. At this point, does it make sense to report an error in the > > function? > > > > > > The callers can decide what do with the error raised by the function. We > > should not write functions that cannot fail. > > > > But that's not what the commit does, is it. It changed some public APIs > from best effort to fail early. That is the side effect and I consider it as a bug. Imagine we add some more code into that function tomorrow and there is an error path. Now because of this bug, we will have to ignore the error condition and not report it. How ridiculous is that? We should have kept the patch as is and fix the callers so that the public APIs were not broken. > Libvirt's promise and value is in stability of its APIs. We want users > to update libvirt without having to rewrite their app (or even rebuild > it = ABI stability). And the commit broke that promise. It's only fair > that it is reverted until proper solution is found. > I have no argument with the above.
