[Bug c/113528] New: gcc-13 meets PVS-studio

[Bug c/113528] New: gcc-13 meets PVS-studio

[dcb314 at hotmail dot com]

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

            Bug ID: 113528
           Summary: gcc-13 meets PVS-studio
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

The following article describes using static analyser PVS-studio to find
potential problems in gcc-13.

https://pvs-studio.com/en/blog/posts/cpp/1067/

It might be worth checking the ten problems listed. It might also be
worth checking that gcc trunk has no new problems, compared to gcc-13.

[Bug middle-end/113528] gcc-13 meets PVS-studio

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> Fragment N4

Is NOT an issue, based on all of the uses of add_char, the character is tested
before adding it ...

And there 256 can hold all values of signed char.

>Fragment N5

Is just a small codiing style issue and actually will be optimized directly to
the same thing really in this case as ' ' and '+' test bit will be in the same
word (the second word/element).


>Fragment N7

Not a bug, was done on purpose, see r5-958-ga33ad58be16a52 (PR 61242 and
https://gcc.gnu.org/pipermail/gcc-patches/2014-May/389815.html).

> Fragment N8

This code is software generated and the length is 0 in the GTY marker:
  ctf_dvdef_t ** GTY ((length ("0"))) ctfc_vars_list;

So not a bug.

> Fragment N9

Looks to be a way to avoid a goto, maybe now we could use a lamdba instead. So
just a coding style issue.


I have not looked into the other ones yet.

[Bug middle-end/113528] gcc-13 meets PVS-studio

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> Fragment N3

The number of json::array leaked is 2 per argument to gcov. Not enough to care
about since it exits after it finishes.  If you are passing 1000 files to gcov
well you have other issues to start with.

[Bug middle-end/113528] gcc-13 meets PVS-studio

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>Fragment N6

So in the tools GCC's code that currenly use gcov_read_profile_dir is not a
leak that matters because the program exits if that fails. So it is only an
issue if someone externally uses it.