[Top][All Lists]

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

Re: [PATCH 0/4] vhost-user: avoid g_return_val_if() in get/set_config()

From: Markus Armbruster
Subject: Re: [PATCH 0/4] vhost-user: avoid g_return_val_if() in get/set_config()
Date: Wed, 18 Nov 2020 17:27:44 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Marc-André Lureau <marcandre.lureau@gmail.com> writes:

> Hi
> On Wed, Nov 18, 2020 at 1:17 PM Stefan Hajnoczi <stefanha@redhat.com> wrote:
>> Markus Armbruster pointed out that g_return_val_if() is meant for
>> programming
>> errors. It must not be used for input validation since it can be compiled
>> out.
>> Use explicit if statements instead.
>> This patch series converts vhost-user device backends that use
>> g_return_val_if() in get/set_config().
>> Stefan Hajnoczi (4):
>>   contrib/vhost-user-blk: avoid g_return_val_if() input validation
>>   contrib/vhost-user-gpu: avoid g_return_val_if() input validation
>>   contrib/vhost-user-input: avoid g_return_val_if() input validation
>>   block/export: avoid g_return_val_if() input validation
> The condition is the same for all the patches, checking the message config
> payload is large enough. Afaict, the value is set by the client, so it
> could be a runtime error, and thus explicit checking is required.
> Nevertheless, one nice thing about g_return* macros, is that it provides an
> error message when the condition fails, which helps. Could you replace it?
> (fwiw, I think g_return* macros are so convenient, I would simply make
> G_DISABLE_CHECKS forbidden and call it a day)

Nice or not, they are as inappropriate for input validation as assert()

    If expr evaluates to FALSE, the current function should be
    considered to have undefined behaviour (a programmer error). The
    only correct solution to such an error is to change the module that
    is calling the current function, so that it avoids this incorrect

reply via email to

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