Re: [Qemu-devel] [PATCH v6 1/5] util: Introduce error reporting functions with fatal/abort

[Markus Armbruster]

Thomas Huth <address@hidden> writes:

> On 02.02.2016 19:53, Markus Armbruster wrote:
>> Lluís Vilanova <address@hidden> writes:
> ...
>
>>> diff --git a/include/qemu/error-report.h b/include/qemu/error-report.h
>>> index 7ab2355..6c2f142 100644
>>> --- a/include/qemu/error-report.h
>>> +++ b/include/qemu/error-report.h
>>> @@ -43,4 +43,23 @@ void error_report(const char *fmt, ...) GCC_FMT_ATTR(1, 
>>> 2);
>>>  const char *error_get_progname(void);
>>>  extern bool enable_timestamp_msg;
>>>  
>>> +/* Report message and exit with error */
>>> +void QEMU_NORETURN error_vreport_fatal(const char *fmt, va_list ap) 
>>> GCC_FMT_ATTR(1, 0);
>>> +void QEMU_NORETURN error_report_fatal(const char *fmt, ...) 
>>> GCC_FMT_ATTR(1, 2);
>> 
>> This lets people write things like
>> 
>>     error_report_fatal("The sky is falling");
>> 
>> instead of
>> 
>>     error_report("The sky is falling");
>>     exit(1);
>> 
>> or
>> 
>>     fprintf(stderr, "The sky is falling\n");
>>     exit(1);
>> 
>> I don't think that's an improvement in clarity.
>
> The problem is not the existing code, but that in a couple of new
> patches, I've now already seen that people are trying to use
>
>      error_setg(&error_fatal, ... );
>
> to do error reporting - which is IMHO the most ugliest way to do this,
> because I'd really not expect error_setg() to (always) exit QEMU when I
> quickly read through the sources.

I agree that this pattern is not wanted.

> We fortunately do not have that in the sources yet (only some few spots
> with error_abort), but to prevent that people start using that, it would
> be good to have a error_report_fatal() function instead, I think.

I doubt an error_report_fatal() function would be much better at
stopping this pattern than the existing error_report(); exit(1) is.

> Alternatively, if you really want to see the exit(1) in the sources, I
> think this should be mentioned in the coding guidelines ... or are you
> fine with error_setg(&error_fatal, ...), Markus?

No, I'm not.

I think this is a checkpatch job, supported by a suitable update to the
docs in error.h.