* [PATCH] mailsplit.c: remove dead code
@ 2014-08-11 21:11 Stefan Beller
2014-08-12 16:38 ` René Scharfe
0 siblings, 1 reply; 9+ messages in thread
From: Stefan Beller @ 2014-08-11 21:11 UTC (permalink / raw)
To: gitster, git; +Cc: 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.
Signed-off-by: Stefan Beller <stefanbeller@gmail.com>
---
builtin/mailsplit.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/builtin/mailsplit.c b/builtin/mailsplit.c
index 06296d4..b499014 100644
--- a/builtin/mailsplit.c
+++ b/builtin/mailsplit.c
@@ -93,8 +93,6 @@ static int split_one(FILE *mbox, const char *name, int allow_bare)
return status;
corrupt:
- if (output)
- fclose(output);
unlink(name);
fprintf(stderr, "corrupt mailbox\n");
exit(1);
--
2.1.0.rc2
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] mailsplit.c: remove dead code
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-17 8:14 ` Jeff King
0 siblings, 2 replies; 9+ messages in thread
From: René Scharfe @ 2014-08-12 16:38 UTC (permalink / raw)
To: Stefan Beller, gitster, git
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.
> Signed-off-by: Stefan Beller <stefanbeller@gmail.com>
> ---
> builtin/mailsplit.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/builtin/mailsplit.c b/builtin/mailsplit.c
> index 06296d4..b499014 100644
> --- a/builtin/mailsplit.c
> +++ b/builtin/mailsplit.c
> @@ -93,8 +93,6 @@ static int split_one(FILE *mbox, const char *name, int allow_bare)
> return status;
>
> corrupt:
> - if (output)
> - fclose(output);
> unlink(name);
> fprintf(stderr, "corrupt mailbox\n");
> exit(1);
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] mailsplit.c: remove dead code
2014-08-12 16:38 ` René Scharfe
@ 2014-08-12 21:21 ` Stefan Beller
2014-08-12 21:37 ` Matthieu Moy
2014-08-12 22:58 ` Jonathan Nieder
2014-08-17 8:14 ` Jeff King
1 sibling, 2 replies; 9+ messages in thread
From: Stefan Beller @ 2014-08-12 21:21 UTC (permalink / raw)
To: l.s.r, gitster, git; +Cc: Stefan Beller
This was found by coverity. (Id: 290001)
The variable 'output' is assigned to a value
after all gotos to the corrupt label.
Remove the goto by moving the errorhandling code to the
condition, which detects the error.
Signed-off-by: Stefan Beller <stefanbeller@gmail.com>
Helped-by: René Scharfe <l.s.r@web.de>
---
builtin/mailsplit.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
If I understood correctly, this is what you had in mind?
Thanks,
Stefan
diff --git a/builtin/mailsplit.c b/builtin/mailsplit.c
index 06296d4..763cda0 100644
--- a/builtin/mailsplit.c
+++ b/builtin/mailsplit.c
@@ -53,14 +53,16 @@ static int keep_cr;
*/
static int split_one(FILE *mbox, const char *name, int allow_bare)
{
- FILE *output = NULL;
+ FILE *output;
int fd;
int status = 0;
int is_bare = !is_from_line(buf.buf, buf.len);
- if (is_bare && !allow_bare)
- goto corrupt;
-
+ if (is_bare && !allow_bare) {
+ unlink(name);
+ fprintf(stderr, "corrupt mailbox\n");
+ exit(1);
+ }
fd = open(name, O_WRONLY | O_CREAT | O_EXCL, 0666);
if (fd < 0)
die_errno("cannot open output file '%s'", name);
@@ -91,13 +93,6 @@ static int split_one(FILE *mbox, const char *name, int allow_bare)
}
fclose(output);
return status;
-
- corrupt:
- if (output)
- fclose(output);
- unlink(name);
- fprintf(stderr, "corrupt mailbox\n");
- exit(1);
}
static int populate_maildir_list(struct string_list *list, const char *path)
--
2.1.0.rc2
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] mailsplit.c: remove dead code
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 22:58 ` Jonathan Nieder
1 sibling, 1 reply; 9+ messages in thread
From: Matthieu Moy @ 2014-08-12 21:37 UTC (permalink / raw)
To: Stefan Beller; +Cc: l.s.r, gitster, git
Stefan Beller <stefanbeller@gmail.com> writes:
> + if (is_bare && !allow_bare) {
> + unlink(name);
> + fprintf(stderr, "corrupt mailbox\n");
> + exit(1);
> + }
Not directly related to your patch, but shouldn't this be using
die(_("corrupt mailbox"));
instead?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mailsplit.c: remove dead code
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
0 siblings, 2 replies; 9+ messages in thread
From: Junio C Hamano @ 2014-08-12 21:38 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Stefan Beller, l.s.r, git
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Stefan Beller <stefanbeller@gmail.com> writes:
>
>> + if (is_bare && !allow_bare) {
>> + unlink(name);
>> + fprintf(stderr, "corrupt mailbox\n");
>> + exit(1);
>> + }
>
> Not directly related to your patch, but shouldn't this be using
>
> die(_("corrupt mailbox"));
>
> instead?
Doesn't the exit status of mailsplit matter to its existing
invokers?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mailsplit.c: remove dead code
2014-08-12 21:38 ` Junio C Hamano
@ 2014-08-12 21:50 ` Junio C Hamano
2014-08-12 21:56 ` Matthieu Moy
1 sibling, 0 replies; 9+ messages in thread
From: Junio C Hamano @ 2014-08-12 21:50 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Stefan Beller, René Scharfe, Git Mailing List
... answering to myself, the only invoker does not seem to care,
so I do not mind if the fprintf/exit gets turned into die() in a
follow-up patch.
Thanks.
On Tue, Aug 12, 2014 at 2:38 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Stefan Beller <stefanbeller@gmail.com> writes:
>>
>>> + if (is_bare && !allow_bare) {
>>> + unlink(name);
>>> + fprintf(stderr, "corrupt mailbox\n");
>>> + exit(1);
>>> + }
>>
>> Not directly related to your patch, but shouldn't this be using
>>
>> die(_("corrupt mailbox"));
>>
>> instead?
>
> Doesn't the exit status of mailsplit matter to its existing
> invokers?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mailsplit.c: remove dead code
2014-08-12 21:38 ` Junio C Hamano
2014-08-12 21:50 ` Junio C Hamano
@ 2014-08-12 21:56 ` Matthieu Moy
1 sibling, 0 replies; 9+ messages in thread
From: Matthieu Moy @ 2014-08-12 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stefan Beller, l.s.r, git
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Stefan Beller <stefanbeller@gmail.com> writes:
>>
>>> + if (is_bare && !allow_bare) {
>>> + unlink(name);
>>> + fprintf(stderr, "corrupt mailbox\n");
>>> + exit(1);
>>> + }
>>
>> Not directly related to your patch, but shouldn't this be using
>>
>> die(_("corrupt mailbox"));
>>
>> instead?
>
> Doesn't the exit status of mailsplit matter to its existing
> invokers?
Not within Git. I doubt anybody checks if the exit status is 1 and
relies on that for corrupt mailboxes, but OTOH, changing the code may
not be worth the trouble.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mailsplit.c: remove dead code
2014-08-12 21:21 ` Stefan Beller
2014-08-12 21:37 ` Matthieu Moy
@ 2014-08-12 22:58 ` Jonathan Nieder
1 sibling, 0 replies; 9+ messages in thread
From: Jonathan Nieder @ 2014-08-12 22:58 UTC (permalink / raw)
To: Stefan Beller; +Cc: l.s.r, gitster, git
Stefan Beller wrote:
> This was found by coverity. (Id: 290001)
[...]
> Signed-off-by: Stefan Beller <stefanbeller@gmail.com>
> Helped-by: René Scharfe <l.s.r@web.de>
> ---
> builtin/mailsplit.c | 17 ++++++-----------
> 1 file changed, 6 insertions(+), 11 deletions(-)
The idea is to simplify error handling (removing cleanup of the
'output' var) by making it more obvious that there is only one kind of
error, right?
For what it's worth, it looks good to me (and much clearer than the
last version). It's always possible to reintroduce goto-based error
handling later if another kind of error is introduced, and in the
meantime this is simpler and does not change behavior.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Thanks.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mailsplit.c: remove dead code
2014-08-12 16:38 ` René Scharfe
2014-08-12 21:21 ` Stefan Beller
@ 2014-08-17 8:14 ` Jeff King
1 sibling, 0 replies; 9+ messages in thread
From: Jeff King @ 2014-08-17 8:14 UTC (permalink / raw)
To: René Scharfe; +Cc: Stefan Beller, gitster, git
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-08-17 8:15 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 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).