From: Jeff King <peff@peff.net>
To: "René Scharfe" <l.s.r@web.de>
Cc: Stefan Beller <stefanbeller@gmail.com>,
gitster@pobox.com, git@vger.kernel.org
Subject: Re: [PATCH] mailsplit.c: remove dead code
Date: Sun, 17 Aug 2014 04:14:45 -0400 [thread overview]
Message-ID: <20140817081444.GI23808@peff.net> (raw)
In-Reply-To: <53EA430E.8050905@web.de>
On Tue, Aug 12, 2014 at 06:38:38PM +0200, René Scharfe wrote:
> Am 11.08.2014 um 23:11 schrieb Stefan Beller:
> >This was found by coverity. (Id: 290001)
> >
> >the variable 'output' is only assigned to a value inequal to NUL,
> >after all gotos to the corrupt label.
> >Therefore we can conclude the two removed lines are actually dead code.
>
> After reading the above for the first time I thought it meant the opposite
> of what's actually going on. Perhaps it's the placement of "only", the
> comma or a flawed understanding of grammar on my part?
>
> In any case, there is only one way to reach the label named corrupt, and the
> variable named output is always NULL if that branch is taken. That means
> the removed code was a no-op. With those two lines gone you also don't need
> to initialize output anymore, by the way.
>
> And since there is only a single goto, you could move the three remaining
> error handling lines up to the if statement. Keeping condition and
> dependent code together would be an improvement, I think.
I think that would be a correct refactoring of the current code, but I
have to wonder why the other die cases are not using "goto corrupt" in
the first place.
The other thing this code path does is unlink the file "name". In the
current code, this is _also_ a noop. We "goto corrupt" before we
actually open the output file. So like the fclose(output), it is
cleaning up an operation that was never started. It can just go away.
But the bigger question is: should the other code paths be cleaning up
the file? It probably doesn't matter, as mailsplit is typically run in
a temporary directory in the first place, so it is up to the caller to
clean up any half-formed cruft. And if we did want to clean up cruft, we
should probably do it with an atexit/signal handler to catch more cases.
Given that we are not cleaning up now and nobody has complained, I'd be
inclined to say we should not. And the unlink can just go away, and all
errors can just call die().
-Peff
prev parent reply other threads:[~2014-08-17 8:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-11 21:11 [PATCH] mailsplit.c: remove dead code Stefan Beller
2014-08-12 16:38 ` René Scharfe
2014-08-12 21:21 ` Stefan Beller
2014-08-12 21:37 ` Matthieu Moy
2014-08-12 21:38 ` Junio C Hamano
2014-08-12 21:50 ` Junio C Hamano
2014-08-12 21:56 ` Matthieu Moy
2014-08-12 22:58 ` Jonathan Nieder
2014-08-17 8:14 ` Jeff King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140817081444.GI23808@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=l.s.r@web.de \
--cc=stefanbeller@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 NNTP newsgroup(s).