qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v2] util/qemu-option: Document the get_opt_value() function


From: Markus Armbruster
Subject: Re: [PATCH v2] util/qemu-option: Document the get_opt_value() function
Date: Tue, 07 Jul 2020 14:04:37 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Thomas Huth <thuth@redhat.com> writes:

> On 07/07/2020 07.35, Markus Armbruster wrote:
>> Richard Henderson <richard.henderson@linaro.org> writes:
>> 
>>> On 6/29/20 12:08 AM, Philippe Mathieu-Daudé wrote:
>>>> Coverity noticed commit 950c4e6c94 introduced a dereference before
>>>> null check in get_opt_value (CID1391003):
>>>>
>>>>   In get_opt_value: All paths that lead to this null pointer
>>>>   comparison already dereference the pointer earlier (CWE-476)
>>>>
>>>> We fixed this in commit 6e3ad3f0e31, but relaxed the check in commit
>>>> 0c2f6e7ee99 because "No callers of get_opt_value() pass in a NULL
>>>> for the 'value' parameter".
>>>>
>>>> Since this function is publicly exposed, it risks new users to do
>>>> the same error again. Avoid that documenting the 'value' argument
>>>> must not be NULL.
>>>
>>> I think we should also add some use of __attribute__((nonnull(...))) to 
>>> enforce
>>> this within the compiler.
>>>
>>> I recently did this without a qemu/compiler.h QEMU_FOO wrapper within
>>> target/arm.  But the nonnull option has optional arguments, so it might be
>>> difficult to wrap in macros.
>> 
>> Do we support building with a compuler that lacks this attribute?
>
> It seems to be available in GCC 4.0 already:
>
> https://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Function-Attributes.html
>
> ... so the answer to your question is certainly "no". All supported
> compilers should have this attribute.

Why a macro then?




reply via email to

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