[Bug analyzer/110172] New: Leak false positives from -fanalyzer with -fexceptions (even on C code)

[Bug analyzer/110172] New: Leak false positives from -fanalyzer with -fexceptions (even on C code)

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110172

            Bug ID: 110172
           Summary: Leak false positives from -fanalyzer with -fexceptions
                    (even on C code)
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: analyzer
          Assignee: dmalcolm at gcc dot gnu.org
          Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

As noted by Reddit user "kr90df" here:
https://www.reddit.com/r/C_Programming/comments/13wl8qi/improvements_to_static_analysis_in_the_gcc_13/jndkr80/
we get a false +ve from -Wanalyzer-va-list-leak on this C code when
-fexceptions is enabled:

#include <stdio.h>
#include <stdarg.h>

int printerr(char *msg, ...) 
{ 
    va_list ap;
    va_start(ap, msg);
    vfprintf(stderr, msg, ap);
    va_end(ap);

    return(-1);
}

See https://godbolt.org/z/zrxsrYE4j

<source>: In function 'printerr':
<source>:12:1: warning: missing call to 'va_end' [-Wanalyzer-va-list-leak]
   12 | }
      | ^
  'printerr': events 1-2
    |
    |    7 |     va_start(ap, msg);
    |      |     ^~~~~~~~
    |      |     |
    |      |     (1) 'va_start' called here
    |......
    |   12 | }
    |      | ~    
    |      | |
    |      | (2) missing call to 'va_end' to match 'va_start' at (1)
    |

[Bug analyzer/110172] Leak false positives from -fanalyzer with -fexceptions (even on C code)

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110172

--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Quoting:
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fexceptions

"""
-fexceptions

    Enable exception handling. Generates extra code needed to propagate
exceptions. For some targets, this implies GCC generates frame unwind
information for all functions, which can produce significant data size
overhead, although it does not affect execution. If you do not specify this
option, GCC enables it by default for languages like C++ that normally require
exception handling, and disables it for languages like C that do not normally
require it. However, you may need to enable this option when compiling C code
that needs to interoperate properly with exception handlers written in C++. You
may also wish to disable this option if you are compiling older C++ programs
that don’t use exception handling.
"""

[Bug analyzer/110172] Leak false positives from -fanalyzer with -fexceptions (even on C code)

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110172

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #2 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
According to
https://www.gnu.org/software/libc/manual/html_node/Registering-New-Conversions.html,
people may custom vfprintf with printf_function.  If the printf_function is
implemented in C++ and throws, then yes there is indeed a leak.

So the warning is not so false with Glibc.

[Bug analyzer/110172] Leak false positives from -fanalyzer with -fexceptions (even on C code)

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110172

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I mentioned that on IRC. I'm not sure glibc can even handle exceptions from
those functions. Is that supported at all? Does printf clean up its own
allocations and locks in that case? IMHO it should be UB for printf_function to
exit via an exception.

[Bug analyzer/110172] Leak false positives from -fanalyzer with -fexceptions (even on C code)

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110172

--- Comment #4 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #3)
> I mentioned that on IRC. I'm not sure glibc can even handle exceptions from
> those functions. Is that supported at all? Does printf clean up its own
> allocations and locks in that case? IMHO it should be UB for printf_function
> to exit via an exception.

They compile vfprintf.c with -fexceptions, so it looks like they are at least
attempting to make it work.  And if they don't want to support it at all, they
should've use __nothrow attribute or noexcept(true) for vfprintf then we
wouldn't see the warning.

[Bug analyzer/110172] Leak false positives from -fanalyzer with -fexceptions (even on C code)

[fw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110172

Florian Weimer <fw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fw at gcc dot gnu.org

--- Comment #5 from Florian Weimer <fw at gcc dot gnu.org> ---
printf is a cancellation point, and can therefore throw. Cancellation is in
POSIX, it's not a glibc extension. I don't think anyone has ever brought up the
need for cancellation handlers that call va_end. I do not think it is possible
to write them.

POSIX should probably specify that va_end is a no-op, or that it is not
required if vfprintf etc. are canceled.