Re: [PATCH 1/7] tools/xenalyze: Work around GCC-15 -Werror=nonnull false positive

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 15/06/2026 5:15 pm, Anthony PERARD wrote:
> On Sat, Jun 13, 2026 at 12:09:18AM +0100, Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> ---
>> CC: Anthony PERARD <anthony.perard@xxxxxxxxxx>
>> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
>> CC: Michal Orzel <michal.orzel@xxxxxxx>
>> CC: Doug Goldstein <cardoe@xxxxxxxxxx>
>> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>> CC: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
>> CC: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
>>
>> I don't particularly like this, but I see no better option.  It's clearly 
>> some
>> kind of VRA failure, yet we don't see it with GCC 15 in other distros.  I
>> suspect that Musl (as opposed to glibc) might be relevant, and perhaps even 
>> as
>> simple as not realising that error() is terminal for a non-zero input.
> While it's true in this case, maybe it's a bit too complicated for gcc
> to find out? error() is terminal only if the first argument is greater
> than opt.tolerance, but there's a check that it can't be too high (when
> parsing options) and ERR_SYSTEM is above that.
>
> If I do that:
>
>      void error(enum error_level l, struct record_info *ri)
>      {
>     -    if ( l > opt.tolerance )
>     +    if ( l > opt.tolerance || l > ERR_MAX_TOLERABLE)
>
> gcc seems happy enough.
>
> And I've notice the compilation error only happens with `debug=n`.
>
> What do you thing of changing the error() function instead of hidding
> NULL-less of the pointer?

:-/

I'd not even spotted that this was a local function called error(),
shadowing the standard library function of the same name.

In which case it isn't a false positive; it's a correct diagnostic,
because the local function _can_ return without exiting.

I'll take your approach, but flipping the checks around so the
opt.tolerance check can be optimised out.

~Andrew