public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] fixincludes: don't abort() on access failure [PR103306]
@ 2021-11-18 11:01 Xi Ruoyao
  2021-11-23  0:37 ` Jeff Law
  0 siblings, 1 reply; 6+ messages in thread
From: Xi Ruoyao @ 2021-11-18 11:01 UTC (permalink / raw)
  To: gcc-patches; +Cc: Bruce Korb, Eric Gallager, Zdenek Sojka, Jakub Jelinek

Some distro may ship dangling symlinks in include directories, triggers
the access failure.  Skip it and continue to next header instead of
being to panic.

Restore to old behavior before r12-5234 but without resurrecting the
problematic getcwd() call, by using the environment variable "INPUT"
exported by fixinc.sh.

Tested on x86_64-linux-gnu, with a dangling symlink in /usr/include.

fixincludes/

	PR bootstrap/103306
	* fixincl.c (process): Don't call abort().
---
 fixincludes/fixincl.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/fixincludes/fixincl.c b/fixincludes/fixincl.c
index a17b65866c3..81939ee5ffa 100644
--- a/fixincludes/fixincl.c
+++ b/fixincludes/fixincl.c
@@ -1352,10 +1352,19 @@ process (void)
 
   if (access (pz_curr_file, R_OK) != 0)
     {
-      /* Some really strange error happened.  */
-      fprintf (stderr, "Cannot access %s: %s\n", pz_curr_file,
+      /* It may happens if for e. g. the distro ships some broken symlinks
+       * in /usr/include.  */
+
+      /* "INPUT" is exported in fixinc.sh, which is the pwd where fixincl
+       * runs.  It's used instead of getcwd to avoid allocating a buffer
+       * with unknown length.  */
+      const char *cwd = getenv ("INPUT");
+      if (!cwd)
+	cwd = "the working directory";
+
+      fprintf (stderr, "Cannot access %s from %s: %s\n", pz_curr_file, cwd,
 	       xstrerror (errno));
-      abort ();
+      return;
     }
 
   pz_curr_data = load_file (pz_curr_file);
-- 
2.34.0


-- 
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] fixincludes: don't abort() on access failure [PR103306]
  2021-11-18 11:01 [PATCH] fixincludes: don't abort() on access failure [PR103306] Xi Ruoyao
@ 2021-11-23  0:37 ` Jeff Law
  2021-11-23  9:31   ` Xi Ruoyao
  0 siblings, 1 reply; 6+ messages in thread
From: Jeff Law @ 2021-11-23  0:37 UTC (permalink / raw)
  To: Xi Ruoyao, gcc-patches; +Cc: Jakub Jelinek, Zdenek Sojka, Bruce Korb



On 11/18/2021 4:01 AM, Xi Ruoyao via Gcc-patches wrote:
> Some distro may ship dangling symlinks in include directories, triggers
> the access failure.  Skip it and continue to next header instead of
> being to panic.
>
> Restore to old behavior before r12-5234 but without resurrecting the
> problematic getcwd() call, by using the environment variable "INPUT"
> exported by fixinc.sh.
>
> Tested on x86_64-linux-gnu, with a dangling symlink in /usr/include.
>
> fixincludes/
>
> 	PR bootstrap/103306
> 	* fixincl.c (process): Don't call abort().
> ---
>   fixincludes/fixincl.c | 15 ++++++++++++---
>   1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/fixincludes/fixincl.c b/fixincludes/fixincl.c
> index a17b65866c3..81939ee5ffa 100644
> --- a/fixincludes/fixincl.c
> +++ b/fixincludes/fixincl.c
> @@ -1352,10 +1352,19 @@ process (void)
>   
>     if (access (pz_curr_file, R_OK) != 0)
>       {
> -      /* Some really strange error happened.  */
> -      fprintf (stderr, "Cannot access %s: %s\n", pz_curr_file,
> +      /* It may happens if for e. g. the distro ships some broken symlinks
> +       * in /usr/include.  */
> +
> +      /* "INPUT" is exported in fixinc.sh, which is the pwd where fixincl
> +       * runs.  It's used instead of getcwd to avoid allocating a buffer
> +       * with unknown length.  */
Formatting nits.  We don't use '*' at the start of comment lines. Drop 
the '*' like this

   /* blah blah blah
      more text.  */


> +      const char *cwd = getenv ("INPUT");
> +      if (!cwd)
> +	cwd = "the working directory";
> +
> +      fprintf (stderr, "Cannot access %s from %s: %s\n", pz_curr_file, cwd,
>   	       xstrerror (errno));
> -      abort ();
> +      return;
>       }
If INPUT is always exported, why not just print it? ie, would CWD after 
actually be NULL?

jeff

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] fixincludes: don't abort() on access failure [PR103306]
  2021-11-23  0:37 ` Jeff Law
@ 2021-11-23  9:31   ` Xi Ruoyao
  2021-11-23 15:39     ` [PATCH v2] " Xi Ruoyao
  2021-11-23 16:12     ` [PATCH] " Jeff Law
  0 siblings, 2 replies; 6+ messages in thread
From: Xi Ruoyao @ 2021-11-23  9:31 UTC (permalink / raw)
  To: Jeff Law, gcc-patches; +Cc: Jakub Jelinek, Zdenek Sojka, Bruce Korb

On Mon, 2021-11-22 at 17:37 -0700, Jeff Law wrote:
> 
> 
> On 11/18/2021 4:01 AM, Xi Ruoyao via Gcc-patches wrote:
> > Some distro may ship dangling symlinks in include directories,
> > triggers
> > the access failure.  Skip it and continue to next header instead of
> > being to panic.
> > 
> > Restore to old behavior before r12-5234 but without resurrecting the
> > problematic getcwd() call, by using the environment variable "INPUT"
> > exported by fixinc.sh.
> > 
> > Tested on x86_64-linux-gnu, with a dangling symlink in /usr/include.
> > 
> > fixincludes/
> > 
> >         PR bootstrap/103306
> >         * fixincl.c (process): Don't call abort().
> > ---
> >   fixincludes/fixincl.c | 15 ++++++++++++---
> >   1 file changed, 12 insertions(+), 3 deletions(-)
> > 
> > diff --git a/fixincludes/fixincl.c b/fixincludes/fixincl.c
> > index a17b65866c3..81939ee5ffa 100644
> > --- a/fixincludes/fixincl.c
> > +++ b/fixincludes/fixincl.c
> > @@ -1352,10 +1352,19 @@ process (void)
> >   
> >     if (access (pz_curr_file, R_OK) != 0)
> >       {
> > -      /* Some really strange error happened.  */
> > -      fprintf (stderr, "Cannot access %s: %s\n", pz_curr_file,
> > +      /* It may happens if for e. g. the distro ships some broken symlinks
> > +       * in /usr/include.  */
> > +
> > +      /* "INPUT" is exported in fixinc.sh, which is the pwd where fixincl
> > +       * runs.  It's used instead of getcwd to avoid allocating a buffer
> > +       * with unknown length.  */
> Formatting nits.  We don't use '*' at the start of comment lines. Drop
> the '*' like this
> 
>    /* blah blah blah
>       more text.  */

Strangely contrib/check_GNU_style.sh does not warn about this.

> 
> > +      const char *cwd = getenv ("INPUT");
> > +      if (!cwd)
> > +       cwd = "the working directory";
> > +
> > +      fprintf (stderr, "Cannot access %s from %s: %s\n", pz_curr_file, cwd,
> >                xstrerror (errno));
> > -      abort ();
> > +      return;
> >       }
> If INPUT is always exported, why not just print it? ie, would CWD after 
> actually be NULL?

INPUT is set by fixinc.sh.  During GCC building process fixincl is
always invoked by fixinc.sh.  However someone may run fixincl executable
directly for debugging.

-- 
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH v2] fixincludes: don't abort() on access failure [PR103306]
  2021-11-23  9:31   ` Xi Ruoyao
@ 2021-11-23 15:39     ` Xi Ruoyao
  2021-11-23 19:35       ` Committed: " Xi Ruoyao
  2021-11-23 16:12     ` [PATCH] " Jeff Law
  1 sibling, 1 reply; 6+ messages in thread
From: Xi Ruoyao @ 2021-11-23 15:39 UTC (permalink / raw)
  To: gcc-patches; +Cc: Jakub Jelinek, Zdenek Sojka, Bruce Korb, Jeff Law

[v2: format fix]

Some distro may ship dangling symlinks in include directories, triggers
the access failure.  Skip it and continue to next header instead of
being to panic.

Restore to old behavior before r12-5234 but without resurrecting the
problematic getcwd() call, by using the environment variable "INPUT"
exported by fixinc.sh.

Tested on x86_64-linux-gnu, with a dangling symlink intentionally
injected into /usr/include.

fixincludes/

	PR bootstrap/103306
	* fixincl.c (process): Don't call abort().
---
 fixincludes/fixincl.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/fixincludes/fixincl.c b/fixincludes/fixincl.c
index a17b65866c3..92909baf85f 100644
--- a/fixincludes/fixincl.c
+++ b/fixincludes/fixincl.c
@@ -1352,10 +1352,19 @@ process (void)
 
   if (access (pz_curr_file, R_OK) != 0)
     {
-      /* Some really strange error happened.  */
-      fprintf (stderr, "Cannot access %s: %s\n", pz_curr_file,
+      /* It may happens if for e. g. the distro ships some broken symlinks
+	 in /usr/include.  */
+
+      /* "INPUT" is exported in fixinc.sh, which is the pwd where fixincl
+	 runs.  It's used instead of getcwd to avoid allocating a buffer
+	 with unknown length.  */
+      const char *cwd = getenv ("INPUT");
+      if (!cwd)
+	cwd = "the working directory";
+
+      fprintf (stderr, "Cannot access %s from %s: %s\n", pz_curr_file, cwd,
 	       xstrerror (errno));
-      abort ();
+      return;
     }
 
   pz_curr_data = load_file (pz_curr_file);
-- 
2.34.0



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] fixincludes: don't abort() on access failure [PR103306]
  2021-11-23  9:31   ` Xi Ruoyao
  2021-11-23 15:39     ` [PATCH v2] " Xi Ruoyao
@ 2021-11-23 16:12     ` Jeff Law
  1 sibling, 0 replies; 6+ messages in thread
From: Jeff Law @ 2021-11-23 16:12 UTC (permalink / raw)
  To: Xi Ruoyao, gcc-patches; +Cc: Jakub Jelinek, Zdenek Sojka, Bruce Korb



On 11/23/2021 2:31 AM, Xi Ruoyao wrote:
> On Mon, 2021-11-22 at 17:37 -0700, Jeff Law wrote:
>>
>> On 11/18/2021 4:01 AM, Xi Ruoyao via Gcc-patches wrote:
>>> Some distro may ship dangling symlinks in include directories,
>>> triggers
>>> the access failure.  Skip it and continue to next header instead of
>>> being to panic.
>>>
>>> Restore to old behavior before r12-5234 but without resurrecting the
>>> problematic getcwd() call, by using the environment variable "INPUT"
>>> exported by fixinc.sh.
>>>
>>> Tested on x86_64-linux-gnu, with a dangling symlink in /usr/include.
>>>
>>> fixincludes/
>>>
>>>          PR bootstrap/103306
>>>          * fixincl.c (process): Don't call abort().
>>> ---
>>>    fixincludes/fixincl.c | 15 ++++++++++++---
>>>    1 file changed, 12 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/fixincludes/fixincl.c b/fixincludes/fixincl.c
>>> index a17b65866c3..81939ee5ffa 100644
>>> --- a/fixincludes/fixincl.c
>>> +++ b/fixincludes/fixincl.c
>>> @@ -1352,10 +1352,19 @@ process (void)
>>>    
>>>      if (access (pz_curr_file, R_OK) != 0)
>>>        {
>>> -      /* Some really strange error happened.  */
>>> -      fprintf (stderr, "Cannot access %s: %s\n", pz_curr_file,
>>> +      /* It may happens if for e. g. the distro ships some broken symlinks
>>> +       * in /usr/include.  */
>>> +
>>> +      /* "INPUT" is exported in fixinc.sh, which is the pwd where fixincl
>>> +       * runs.  It's used instead of getcwd to avoid allocating a buffer
>>> +       * with unknown length.  */
>> Formatting nits.  We don't use '*' at the start of comment lines. Drop
>> the '*' like this
>>
>>     /* blah blah blah
>>        more text.  */
> Strangely contrib/check_GNU_style.sh does not warn about this.
It should.  Though in fairness, that checker is new relative to the 
overall live of the GCC project and obviously not 100% complete. Patches 
are always appreciated :-)



>
>>> +      const char *cwd = getenv ("INPUT");
>>> +      if (!cwd)
>>> +       cwd = "the working directory";
>>> +
>>> +      fprintf (stderr, "Cannot access %s from %s: %s\n", pz_curr_file, cwd,
>>>                 xstrerror (errno));
>>> -      abort ();
>>> +      return;
>>>        }
>> If INPUT is always exported, why not just print it? ie, would CWD after
>> actually be NULL?
> INPUT is set by fixinc.sh.  During GCC building process fixincl is
> always invoked by fixinc.sh.  However someone may run fixincl executable
> directly for debugging.
Good point.  With the formatting nit fixed, this is fine for the trunk.

Thanks,
jeff


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Committed: [PATCH v2] fixincludes: don't abort() on access failure [PR103306]
  2021-11-23 15:39     ` [PATCH v2] " Xi Ruoyao
@ 2021-11-23 19:35       ` Xi Ruoyao
  0 siblings, 0 replies; 6+ messages in thread
From: Xi Ruoyao @ 2021-11-23 19:35 UTC (permalink / raw)
  To: gcc-patches; +Cc: Jakub Jelinek, Zdenek Sojka, Bruce Korb, Jeff Law

Committed as r12-5477.

On Tue, 2021-11-23 at 23:39 +0800, Xi Ruoyao via Gcc-patches wrote:
> [v2: format fix]
> 
> Some distro may ship dangling symlinks in include directories, triggers
> the access failure.  Skip it and continue to next header instead of
> being to panic.
> 
> Restore to old behavior before r12-5234 but without resurrecting the
> problematic getcwd() call, by using the environment variable "INPUT"
> exported by fixinc.sh.
> 
> Tested on x86_64-linux-gnu, with a dangling symlink intentionally
> injected into /usr/include.
> 
> fixincludes/
> 
>         PR bootstrap/103306
>         * fixincl.c (process): Don't call abort().
> ---
>  fixincludes/fixincl.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/fixincludes/fixincl.c b/fixincludes/fixincl.c
> index a17b65866c3..92909baf85f 100644
> --- a/fixincludes/fixincl.c
> +++ b/fixincludes/fixincl.c
> @@ -1352,10 +1352,19 @@ process (void)
>  
>    if (access (pz_curr_file, R_OK) != 0)
>      {
> -      /* Some really strange error happened.  */
> -      fprintf (stderr, "Cannot access %s: %s\n", pz_curr_file,
> +      /* It may happens if for e. g. the distro ships some broken symlinks
> +        in /usr/include.  */
> +
> +      /* "INPUT" is exported in fixinc.sh, which is the pwd where fixincl
> +        runs.  It's used instead of getcwd to avoid allocating a buffer
> +        with unknown length.  */
> +      const char *cwd = getenv ("INPUT");
> +      if (!cwd)
> +       cwd = "the working directory";
> +
> +      fprintf (stderr, "Cannot access %s from %s: %s\n", pz_curr_file, cwd,
>                xstrerror (errno));
> -      abort ();
> +      return;
>      }
>  
>    pz_curr_data = load_file (pz_curr_file);

-- 
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-11-23 19:35 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-18 11:01 [PATCH] fixincludes: don't abort() on access failure [PR103306] Xi Ruoyao
2021-11-23  0:37 ` Jeff Law
2021-11-23  9:31   ` Xi Ruoyao
2021-11-23 15:39     ` [PATCH v2] " Xi Ruoyao
2021-11-23 19:35       ` Committed: " Xi Ruoyao
2021-11-23 16:12     ` [PATCH] " Jeff Law

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).