Re: [PATCH] vasnprintf: silence some clang false positives

[Bruno Haible]

Hi Eric,

> Bruno, would you be okay with this patch?

> +     * lib/vasnprintf.c (VASNPRINTF) [ENSURE_ALLOCATION]: Teach clang
> +     that ENSURE_ALLOCATION guarantees a non-null result.

> +    else if (!result)                                                        
> \
> +      abort ()

No, this patch is wrong. ENSURE_ALLOCATION does not guarantee a non-NULL
'result'. In fact, in the invocations at lines 2060, 2094, 2188, 2222, 2316,
2350, 2565, 2820, 2880, 3379, 4565, 5321, 5347, 5353, 5358, the 'needed'
argument may be 0, and when at the same time the 'allocated' variable is
also 0, the 'result' will be NULL. You patch would add an invocation of
abort() in these cases.

In fact, the comments in lines 1813..1815 say it: result is only guaranteed
to be != NULL when length > 0 (or allocated > 0).

Independently of this particular issue, I'm not in favour of adding code
to placate erroneous clang warnings in an ad-hoc manner, for two reasons:

  1) Tools like 'clang' evolve. Maybe today it has an insufficient data flow
     analysis, but in three years it will have a better one. Time is better
     spent encouraging the 'clang' developers to improve their inferencing
     engine.

  2) There will always be situations where the tool cannot determine the
     invariants of a program automatically. For these cases, the language
     needs a way to assert invariants. What is the way to assert invariants
     that clang understands? Is 'assert(condition)' or
     'if (!condition) abort();' enough?

     (It's like with loose vs. strict typing in Common Lisp or C#: It's
     possible to write code where variables don't have type information
     in the program. The compiler may or may not be able to infer it.
     If you want to be sure that the compiler understands the types, you
     have to state them explicitly.)

So, what I'd like to see is a standard way to declare invariants (assertions)
in a way that clang and other static analysis tools (maybe GCC in the future?)
could understand. Of course, these declarations should have no negative
impact on the speed of the program. (When you declare types in CL or C#, it
also never degrades the performance.)

Bruno
-- 
In memoriam Dora Gerson <http://en.wikipedia.org/wiki/Dora_Gerson>