On 12/5/25 07:08, Akihiko Odaki wrote: > On 2025/11/26 0:49, Dmitry Osipenko wrote: >> On 11/25/25 15:09, Alex Bennée wrote: >>> Dmitry Osipenko <[email protected]> writes: >>> >>>> Make virtio_gpu_virgl_unmap_resource_blob() return -1 for more >>>> consistency >>>> of error propagation style in the code, adhering to QEMU's devel/style >>>> recommendations and preparing code for further code changes >>>> utilizing this >>>> function. >>> I'm not so sure of that. If the function is a pass/fail then we tend to >>> prefer using bools in newer code. If you need richer internal error >>> reporting then start using your errno defines. If this is user visible >>> (i.e. during configuration) then we can make more of Error* and friends. >> >> The current code is a mix of all variants. Will be good to stick with >> one. >> >> Akihiko, what are your thoughts on the best option for the errors >> handling? Would you also prefer bools? > > Sorry, I missed this. > > I'm for bools. It allows compilers to enforce having either of two > values, whose semantics is defined in include/qapi/error.h "true on > success / false on failure"; it says functions should also have "Error > **errp" but I think the semantics of bool can be applied for those > without the parameter. > > If you are still not sure or there are disagreements, I think it is > better to ask Markus Armbruster, who maintains the error reporting > facility shared for the whole codebase.
Thanks for the reply. The bools are fine with me. I removed patches changing the error handling in a next version of this patchset as they are a bit controversial and not essential for this series. -- Best regards, Dmitry
