Re: [PATCH v7 1/2] libxc: Report consistent errors in xc_resource_op

["Anthony PERARD" <anthony.perard@vates.tech>]

On Tue, Feb 24, 2026 at 09:28:57AM +0000, Teddy Astie wrote:
> Le 23/02/2026 à 17:15, Jan Beulich a écrit :
> > On 23.02.2026 17:06, Teddy Astie wrote:
> >> xc_report_op returns -1 in some error conditions.
> >> Make sure it returns -ENOMEM in out of memory errors and -EINVAL
> >> in invalid usages errors.
> >
> > Isn't this a move in the wrong direction? -1 as a return value is quite okay.
> > errno wants setting to indicate the cause of the error (if called functions
> > don't already set it properly).
> >
>
> To me, passing error through errno here feels more like a workaround
> rather than a proper error handling. It doesn't feel consistent in libxc
> overall (some functions returns a negative value corresponding to a
> error number while some others -1; in some cases we update errno).
>
> What are the error handling rules for xenctrl ?

They are written down. See
    https://elixir.bootlin.com/xen/v4.21.0/source/tools/include/xenctrl.h#L76

    Unless otherwise specified, each function here returns zero or a
    non-null pointer on success; or in case of failure, sets errno and
    returns -1 or a null pointer.

    Unless otherwise specified, errors result in a call to the error
    handler function, which by default prints a message to the
    FILE* passed as the caller_data, which by default is stderr.
    (This is described below as "logging errors".)

    The error handler can safely trash errno, as libxc saves it across
    the callback.

`errno` isn't a workaround, it is the way many libc functions and other
passes generic error code. It may feel awkward, but that C.

If some functions don't update `errno`, it might be because the syscall
already set `errno` and there's no need to change it.

Thanks,


--
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech