[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Eric Gallager  ---
(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

[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[egallager at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Eric Gallager  ---
(In reply to CVS Commits from comment #9)
> The master branch has been updated by Xi Ruoyao :
> 
> https://gcc.gnu.org/g:04c5a91d068c4ca2f09c2bc206fce00db9d1790b
> 
> commit r12-5234-g04c5a91d068c4ca2f09c2bc206fce00db9d1790b
> Author: Xi Ruoyao 
> 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?

[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Xi Ruoyao :

https://gcc.gnu.org/g:04c5a91d068c4ca2f09c2bc206fce00db9d1790b

commit r12-5234-g04c5a91d068c4ca2f09c2bc206fce00db9d1790b
Author: Xi Ruoyao 
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.

[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

--- Comment #8 from Xi Ruoyao  ---
(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

[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

--- Comment #7 from Xi Ruoyao  ---
New patch, for both PR 80047 and this one.

[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||bkorb at gnu dot org,
   ||xry111 at mengyan1223 dot wang

--- Comment #6 from Eric Gallager  ---
There's a patch for related bug 80047 that would make this worse:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583820.html

[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Severity|normal  |trivial

[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||easyhack
 CC||pinskia at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to Alfred M. Szmidt from comment #4)
>> Created attachment 9857 [details]
>> Don't use arbitrary limits.
>> 
>> The following fixes fixincludes.
>> 
>> fixincludes/ChangeLog
>> 2005-09-16  Alfred M. Szmidt  
>> 
>>  * fixincl.c (quoted_file_exists): Use xmalloc to allocate memory
>>  for FNAME.
>>  (create_file): Use xmalloc to allocate memory for FNAME.
>> 
>>  * server.c (server_setup): Use dynamic allocation for BUFF.
> 
>Please send this patch to the gcc-patches mailing list for review, if it
> still
>applies
> 
> MAXPATHLEN is still used in fixincludes.  Seeing that this patch is
> over 10 years, I am not sure it even applies and thus a good idea to
> forward it to gcc-patches for review.  The fix is simple enough in
> fixincludes (simply use xmalloc).

ok, adding "easyhack" keyword then

[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[ams at gnu dot org]

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

--- Comment #4 from Alfred M. Szmidt  ---
   > Created attachment 9857 [details]
   > Don't use arbitrary limits.
   > 
   > The following fixes fixincludes.
   > 
   > fixincludes/ChangeLog
   > 2005-09-16  Alfred M. Szmidt  
   > 
   >* fixincl.c (quoted_file_exists): Use xmalloc to allocate memory
   >for FNAME.
   >(create_file): Use xmalloc to allocate memory for FNAME.
   > 
   >* server.c (server_setup): Use dynamic allocation for BUFF.

   Please send this patch to the gcc-patches mailing list for review, if it
still
   applies

MAXPATHLEN is still used in fixincludes.  Seeing that this patch is
over 10 years, I am not sure it even applies and thus a good idea to
forward it to gcc-patches for review.  The fix is simple enough in
fixincludes (simply use xmalloc).

[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Alfred M. Szmidt from comment #2)
> Created attachment 9857 [details]
> Don't use arbitrary limits.
> 
> The following fixes fixincludes.
> 
> fixincludes/ChangeLog
> 2005-09-16  Alfred M. Szmidt  
> 
>   * fixincl.c (quoted_file_exists): Use xmalloc to allocate memory
>   for FNAME.
>   (create_file): Use xmalloc to allocate memory for FNAME.
> 
>   * server.c (server_setup): Use dynamic allocation for BUFF.

Please send this patch to the gcc-patches mailing list for review, if it still
applies

[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-19 
14:01 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-06-19 14:01:30
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823

[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c   |other


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823

[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||21824
  nThis||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823