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>