Re: [Xen-devel] [PATCH 09/11] tools/xc: pass errno to callers of xc_domain_save

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Olaf Hering writes ("Re: [PATCH 09/11] tools/xc: pass errno to callers of 
xc_domain_save"):
> On Thu, Mar 06, Ian Jackson wrote:
> > I can't help wondering if this patch would be a lot smaller if it were
> > done by having ERROR and PERROR, and the cleanup part of
> > xc_domain_save, preserve errno.
> 
> Something like this for the macros?
> 
> diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
> index a610f0c..8b791b6 100644
> --- a/tools/libxc/xc_private.h
> +++ b/tools/libxc/xc_private.h
> @@ -123,9 +123,15 @@ void xc_report_progress_step(xc_interface *xch,
>  #define DPRINTF(_f, _a...) xc_report(xch, xch->error_handler, XTL_DETAIL,0, 
> _f , ## _a)
>  #define DBGPRINTF(_f, _a...) xc_report(xch, xch->error_handler, XTL_DEBUG,0, 
> _f , ## _a)
>  
> -#define ERROR(_m, _a...)  xc_report_error(xch,XC_INTERNAL_ERROR,_m , ## _a )
> -#define PERROR(_m, _a...) xc_report_error(xch,XC_INTERNAL_ERROR,_m \
> -                  " (%d = %s)", ## _a , errno, xc_strerror(xch, errno))
> +#define ERROR(_m, _a...)  do { int __errno = errno; \
> +        xc_report_error(xch,XC_INTERNAL_ERROR,_m , ## _a ); \
> +        errno = __errno; \
> +        } while (0)
> +#define PERROR(_m, _a...) do { int __errno = errno; \
> +        xc_report_error(xch,XC_INTERNAL_ERROR,_m " (%d = %s)", \
> +        ## _a , errno, xc_strerror(xch, errno)); \
> +        errno = __errno; \
> +        } while (0)

Yes, except the temporary should be called "error_macro_errno" or
something.

The "__thing" convention is one found in various places (including
parts of the hypervisor) but it is wrong because:

  * Identifiers starting with "__" (and in some contexts "_") are
    reserved for the C implementation (ie the compiler and libc)
    and must not be used.

  * The names of these internal variables should contain the macro
    name, so that if several different macros are combined in one bit
    of code, they don't end up with name clashes.  (That leaves only
    sort-of-recursive invocations which is not usually a problem.)

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel