[Bug bootstrap/80047] fixincludes/fixincl.c: PVS-Studio: Improper Release of Memory Before Removing Last Reference (CWE-401)

["egallager at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #9 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to CVS Commits from comment #8)
> The master branch has been updated by Xi Ruoyao <xry111@gcc.gnu.org>:
> 
> https://gcc.gnu.org/g:04c5a91d068c4ca2f09c2bc206fce00db9d1790b
> 
> commit r12-5234-g04c5a91d068c4ca2f09c2bc206fce00db9d1790b
> Author: Xi Ruoyao <xry111@mengyan1223.wang>
> Date:   Tue Nov 9 21:40:04 2021 +0800
> 
>     fixincludes: simplify handling for access() failure [PR21283, PR80047]
>     
>     POSIX says:
>     
>         On some implementations, if buf is a null pointer, getcwd() may
> obtain
>         size bytes of memory using malloc(). In this case, the pointer
> returned
>         by getcwd() may be used as the argument in a subsequent call to
> free().
>         Invoking getcwd() with buf as a null pointer is not recommended in
>         conforming applications.
>     
>     This produces an error building GCC with --enable-werror-always:
>     
>         ../../../fixincludes/fixincl.c: In function âprocessâ:
>         ../../../fixincludes/fixincl.c:1356:7: error: argument 1 is null but
>         the corresponding size argument 2 value is 4096 [-Werror=nonnull]
>     
>     It's suggested by POSIX to call getcwd() with progressively larger
>     buffers until it does not give an [ERANGE] error. However, it's highly
>     unlikely that this error-handling route is ever used.
>     
>     So we can simplify it instead of writting too much code.  We give up to
>     use getcwd(), because `make` will output a `Leaving directory ...`
> message
>     containing the path to cwd when we call abort().
>     
>     fixincludes/ChangeLog:
>     
>             PR other/21823
>             PR bootstrap/80047
>             * fixincl.c (process): Simplify the handling for highly
>               unlikely access() failure, to avoid using non-standard
>               extensions.

So... ok to close as FIXED then? Or leave open for backports?