From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27124 invoked by alias); 19 Jun 2018 14:38:40 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 43068 Received: (qmail 12314 invoked by uid 1010); 19 Jun 2018 14:38:40 -0000 X-Qmail-Scanner-Diagnostics: from joooj.vinc17.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(155.133.131.76):SA:0(-1.9/5.0):. Processed in 1.222384 secs); 19 Jun 2018 14:38:40 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: vincent@vinc17.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Date: Tue, 19 Jun 2018 16:38:34 +0200 From: Vincent Lefevre To: zsh-workers@zsh.org Subject: Re: [PATCH 2/2] Fix two C nits Message-ID: <20180619143834.GA17383@zira.vinc17.org> Mail-Followup-To: zsh-workers@zsh.org References: <20180616010427.2916-2-lists@eitanadler.com> <20180618092243eucas1p133cc109ed17712cd4253a72da472fa54~5NsPXgtMr0676306763eucas1p1g@eucas1p1.samsung.com> <20180619134629.GA15318@zira.vinc17.org> <20180619141321eucas1p194af5292bb4f5030e0536c500ef9c6c5~5lTSLcvNm0521405214eucas1p1I@eucas1p1.samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180619141321eucas1p194af5292bb4f5030e0536c500ef9c6c5~5lTSLcvNm0521405214eucas1p1I@eucas1p1.samsung.com> X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/1.10+31 (9cdd8847) vl-108074 (2018-06-19) On 2018-06-19 15:13:19 +0100, Peter Stephenson wrote: > On Tue, 19 Jun 2018 15:46:29 +0200 > Vincent Lefevre wrote: > > On 2018-06-18 10:22:41 +0100, Peter Stephenson wrote: > > > On Sat, 16 Jun 2018 01:04:27 +0000 > > > Eitan Adler 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 - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)