public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug analyzer/110543] New: RFE: Add optional trim of the analyzer diagnostics through system headers.
@ 2023-07-04 13:07 vultkayn at gcc dot gnu.org
  2023-08-14 18:05 ` [Bug analyzer/110543] " cvs-commit at gcc dot gnu.org
  2023-08-14 18:24 ` vultkayn at gcc dot gnu.org
  0 siblings, 2 replies; 3+ messages in thread
From: vultkayn at gcc dot gnu.org @ 2023-07-04 13:07 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 110543
           Summary: RFE: Add optional trim of the analyzer diagnostics
                    through system headers.
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: analyzer
          Assignee: dmalcolm at gcc dot gnu.org
          Reporter: vultkayn at gcc dot gnu.org
  Target Milestone: ---

See https://godbolt.org/z/sb9dM9Gqa for a reproducer on trunk.

Given an issue on std::shared_ptr<>, the analyzer emits a path that I'd like to
optionally shorten, by trimming it.
Looking at the reproducer, I believe it would be desirable the analyzer emits
similar diagnostics for smart pointers as it is for raw pointers, i.e. the
diagnostic should not dive into the standard library, but rather stop at the
faulting frame.

Thus behaves as follow, _by default_:

<source>: In function 'int main()':
<source>:5:8: warning: dereference of NULL 'a' [CWE-476]
[-Wanalyzer-null-dereference]
    5 |   a->x = 4; /* Diagnostic would path should stop here rather than going
to shared_ptr_base.h */
      |   ~~~~~^~~
  'int main()': events 1-2
    |
    |    4 |   std::shared_ptr<A> a;
    |      |      ^
    |      |      |
    |      |      (1) 'a' is NULL
    |    5 |   a->x = 4; /* Diagnostic path should stop here rather than going
to shared_ptr_base.h */
    |      |   ~~~~~~~~
    |      |        |
    |      |        (2) dereference of NULL 'a'
    | 

A flag akin to -fanalyzer-trim-diagnostic-path=<maxdepth>|std would then be
introduced to do so, with a default value of std.
Such option would be useful for future support of C++, but could be extended to
any "system header", thus also be used in C.


A slight variation would be to trim all but the last exceeding event, so that
the user would still get feedback on template deducted types.

What do you think ?

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-08-14 18:24 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-04 13:07 [Bug analyzer/110543] New: RFE: Add optional trim of the analyzer diagnostics through system headers vultkayn at gcc dot gnu.org
2023-08-14 18:05 ` [Bug analyzer/110543] " cvs-commit at gcc dot gnu.org
2023-08-14 18:24 ` vultkayn at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).