qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/3] qemu-error: make use of {error, warn}_repor


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 2/3] qemu-error: make use of {error, warn}_report_once_cond
Date: Wed, 29 Aug 2018 18:12:32 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Cornelia Huck <address@hidden> writes:

> {error,warn}_report_once() are a special case of the new functions
> and can simply switch to them.
>
> Signed-off-by: Cornelia Huck <address@hidden>
> ---
>  include/qemu/error-report.h | 10 ++--------
>  1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/include/qemu/error-report.h b/include/qemu/error-report.h
> index d2a6515e68..4e4c0e757c 100644
> --- a/include/qemu/error-report.h
> +++ b/include/qemu/error-report.h
> @@ -58,10 +58,7 @@ void warn_report_once_cond(bool *printed, const char *fmt, 
> ...)
>          static bool print_once_;                \
>          bool ret_print_once_ = !print_once_;    \
>                                                  \
> -        if (!print_once_) {                     \
> -            print_once_ = true;                 \
> -            error_report(fmt, ##__VA_ARGS__);   \
> -        }                                       \
> +        error_report_once_cond(&print_once_, fmt, ##__VA_ARGS__); \
>          unlikely(ret_print_once_);              \
>      })
>  
> @@ -74,10 +71,7 @@ void warn_report_once_cond(bool *printed, const char *fmt, 
> ...)
>          static bool print_once_;                \
>          bool ret_print_once_ = !print_once_;    \
>                                                  \
> -        if (!print_once_) {                     \
> -            print_once_ = true;                 \
> -            warn_report(fmt, ##__VA_ARGS__);    \
> -        }                                       \
> +        warn_report_once_cond(&print_once_, fmt, ##__VA_ARGS__); \
>          unlikely(ret_print_once_);              \
>      })

Hmm.  The macros return a value, while the functions do not.  Doesn't
this contradict the commit message's claim the macros are รค special case
of the new functions"?

If you make the functions return the value, too, the macros become
simpler.  Moving complexity from macros to functions feels like a good
deal, even when it's just a little bit of complexity like here.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]