From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 4D40A3858403; Sat, 13 Nov 2021 21:31:45 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4D40A3858403
From: "egallager at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes
Date: Sat, 13 Nov 2021 21:31:45 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: other
X-Bugzilla-Version: 4.0.0
X-Bugzilla-Keywords: build, easyhack, patch
X-Bugzilla-Severity: trivial
X-Bugzilla-Who: egallager at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-21823-4-qV9omBkgTm@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-21823-4@http.gcc.gnu.org/bugzilla/>
References: <bug-21823-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Nov 2021 21:31:45 -0000

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

--- Comment #10 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to CVS Commits from comment #9)
> The master branch has been updated by Xi Ruoyao <xry111@gcc.gnu.org>:
>=20
> https://gcc.gnu.org/g:04c5a91d068c4ca2f09c2bc206fce00db9d1790b
>=20
> commit r12-5234-g04c5a91d068c4ca2f09c2bc206fce00db9d1790b
> Author: Xi Ruoyao <xry111@mengyan1223.wang>
> Date:   Tue Nov 9 21:40:04 2021 +0800
>=20
>     fixincludes: simplify handling for access() failure [PR21283, PR80047]
>=20=20=20=20=20
>     POSIX says:
>=20=20=20=20=20
>         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.
>=20=20=20=20=20
>     This produces an error building GCC with --enable-werror-always:
>=20=20=20=20=20
>         ../../../fixincludes/fixincl.c: In function =C3=A2process=C3=A2:
>         ../../../fixincludes/fixincl.c:1356:7: error: argument 1 is null =
but
>         the corresponding size argument 2 value is 4096 [-Werror=3Dnonnul=
l]
>=20=20=20=20=20
>     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.
>=20=20=20=20=20
>     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().
>=20=20=20=20=20
>     fixincludes/ChangeLog:
>=20=20=20=20=20
>             PR other/21823
>             PR bootstrap/80047
>             * fixincl.c (process): Simplify the handling for highly
>               unlikely access() failure, to avoid using non-standard
>               extensions.

Is it ok to close this as FIXED now? Or should we leave it open for backpor=
ts?=