* [Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes
[not found] <bug-21823-4@http.gcc.gnu.org/bugzilla/>
@ 2021-11-11 13:07 ` egallager at gcc dot gnu.org
2021-11-11 16:51 ` xry111 at mengyan1223 dot wang
` (4 subsequent siblings)
5 siblings, 0 replies; 10+ messages in thread
From: egallager at gcc dot gnu.org @ 2021-11-11 13:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823
Eric Gallager <egallager at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bkorb at gnu dot org,
| |xry111 at mengyan1223 dot wang
--- Comment #6 from Eric Gallager <egallager at gcc dot gnu.org> ---
There's a patch for related bug 80047 that would make this worse:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583820.html
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes
[not found] <bug-21823-4@http.gcc.gnu.org/bugzilla/>
2021-11-11 13:07 ` egallager at gcc dot gnu.org
@ 2021-11-11 16:51 ` xry111 at mengyan1223 dot wang
2021-11-11 16:52 ` xry111 at mengyan1223 dot wang
` (3 subsequent siblings)
5 siblings, 0 replies; 10+ messages in thread
From: xry111 at mengyan1223 dot wang @ 2021-11-11 16:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823
--- Comment #7 from Xi Ruoyao <xry111 at mengyan1223 dot wang> ---
New patch, for both PR 80047 and this one.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes
[not found] <bug-21823-4@http.gcc.gnu.org/bugzilla/>
2021-11-11 13:07 ` egallager at gcc dot gnu.org
2021-11-11 16:51 ` xry111 at mengyan1223 dot wang
@ 2021-11-11 16:52 ` xry111 at mengyan1223 dot wang
2021-11-13 18:34 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 10+ messages in thread
From: xry111 at mengyan1223 dot wang @ 2021-11-11 16:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823
--- Comment #8 from Xi Ruoyao <xry111 at mengyan1223 dot wang> ---
(In reply to Xi Ruoyao from comment #7)
> New patch, for both PR 80047 and this one.
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584164.html
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes
[not found] <bug-21823-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2021-11-11 16:52 ` xry111 at mengyan1223 dot wang
@ 2021-11-13 18:34 ` cvs-commit at gcc dot gnu.org
2021-11-13 21:31 ` egallager at gcc dot gnu.org
2021-11-15 0:13 ` egallager at gcc dot gnu.org
5 siblings, 0 replies; 10+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-11-13 18:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823
--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes
[not found] <bug-21823-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2021-11-13 18:34 ` cvs-commit at gcc dot gnu.org
@ 2021-11-13 21:31 ` egallager at gcc dot gnu.org
2021-11-15 0:13 ` egallager at gcc dot gnu.org
5 siblings, 0 replies; 10+ messages in thread
From: egallager at gcc dot gnu.org @ 2021-11-13 21:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823
--- 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>:
>
> 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.
Is it ok to close this as FIXED now? Or should we leave it open for backports?
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes
[not found] <bug-21823-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2021-11-13 21:31 ` egallager at gcc dot gnu.org
@ 2021-11-15 0:13 ` egallager at gcc dot gnu.org
5 siblings, 0 replies; 10+ messages in thread
From: egallager at gcc dot gnu.org @ 2021-11-15 0:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823
Eric Gallager <egallager at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #11 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Eric Gallager from comment #10)
> Is it ok to close this as FIXED now? Or should we leave it open for
> backports?
Closing per comments in bug 80047
^ permalink raw reply [flat|nested] 10+ messages in thread