Re: vasnprintf.c vs GCC11's -Wanalyzer-null-argument (and glibc-2.31)

[Bruno Haible]

Hi Jim,

> I built latest gcc from git and then attempted to build things with it.
> I noticed this new warning while trying to build diffutils, but
> haven't had time to address:

The vast majority of -Wanalyzer* warnings that we have seen so far were false
alarms [1].

This one is a false alarm as well. The compiler is complaining that in
vasnprintf.c:1962

        if (cp != dp->dir_start)                                       // <== 
1951
          {
            size_t n = dp->dir_start - cp;                             // <== 
1953
            size_t augmented_length = xsum (length, n);                // <== 
1954

            ENSURE_ALLOCATION (augmented_length);                      // <== 
1956
            /* This copies a piece of FCHAR_T[] into a DCHAR_T[].  Here we
               need that the format string contains only ASCII characters
               if FCHAR_T and DCHAR_T are not the same type.  */
            if (sizeof (FCHAR_T) == sizeof (DCHAR_T))
              {
                DCHAR_CPY (result + length, (const DCHAR_T *) cp, n);  // <== 
1962

DCHAR_CPY = memcpy could be invoked with result = NULL. But when you look
at all assignments to 'result', result is only assigned NULL in line 1916,
and here allocated = 0. By the logic of the ENSURE_ALLOCATION macro, 'result'
is only assigned a new value when 'allocated' is, and vice versa.
Now, since in line 1953 n > 0 (due to line 1951), in line 1954 augmented_length
is also > 0 (by the definition of xsum), hence ENSURE_ALLOCATION in line 1956
gets invoked with a positive argument, thus in line 1927
   if ((needed) > allocated)
must evaluate to true. The compiler's logic did not see this; it proposed
a code path where in line 1927 the condition evaluates to false — which
cannot happen.

So, in the current state, looking at -fanalyzer / -Wanalyzer outputs is
still a waste of time.

I don't want to modify the source code to silence false alarms from this
(yet immature) tool.

Bruno

[1] https://lists.gnu.org/archive/html/bug-gnulib/2020-05/msg00118.html