Thomas Huth <th...@redhat.com> writes: > On 07/07/2020 07.35, Markus Armbruster wrote: >> Richard Henderson <richard.hender...@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?
