Re: [PATCH 2/2] Fix two C nits

[Vincent Lefevre <vincent@vinc17.net>]

On 2018-06-19 15:13:19 +0100, Peter Stephenson wrote:
> On Tue, 19 Jun 2018 15:46:29 +0200
> Vincent Lefevre <vincent@vinc17.net> wrote:
> > On 2018-06-18 10:22:41 +0100, Peter Stephenson wrote:
> > > On Sat, 16 Jun 2018 01:04:27 +0000
> > > Eitan Adler <lists@eitanadler.com> wrote:  
> > > > - avoid returning from a function that will never return
> > > >
> > > > diff --git a/Src/exec.c b/Src/exec.c
> > > > index d44527841..b36bcef64 100644
> > > > --- a/Src/exec.c
> > > > +++ b/Src/exec.c
> > > > @@ -4954,7 +4954,6 @@ getpipe(char *cmd, int nullexec)
> > > >      execode(prog, 0, 1, out ? "outsubst" : "insubst");
> > > >      cmdpop();
> > > >      _exit(lastval);
> > > > -    return 0;
> > > >  }  
> >
> > The _exit function is non-standard.
> 
> That means from the basic C point of view it's not safe simply to remove
> the return.  We are not in the game of guessing what the compiler knows.

It's safe because whether the "return 0;" line is here or not, this
will not change the behavior since this line is not reachable (even
if the compiler doesn't know this).

If the compiler doesn't know that _exit never returns, it will
typically add an instruction corresponding to the "return 0;",
but this instruction will never be executed. If the "return 0;"
is removed, then the compiler will not add such an instruction,
but may add a "jump" (which, again, will never be executed) and
this may also prevent some optimizations in the code that follows
(because the compiler would think that code that follows may also
be reached from this "if" block).

In short, the presence or not of the "return 0;" may have an effect
on the generated code (good or bad, this is potentially unknown),
but the behavior will remain the same.

> Anything we *can* detect about the compiler / configuration is
> fair game for improvement, however...

FYI, _exit is a builtin in GCC (according to the manual), so that
GCC necessarily knows and the presence or not of "return 0;" should
be equivalent.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)