From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 4/4] transport: drop "int cmp = cmp" hack
Date: Mon, 25 Mar 2013 17:06:25 -0400 [thread overview]
Message-ID: <20130325210625.GA16386@sigill.intra.peff.net> (raw)
In-Reply-To: <7vfvzjxnq9.fsf@alter.siamese.dyndns.org>
On Mon, Mar 25, 2013 at 12:50:54PM -0700, Junio C Hamano wrote:
> >> transport.c: In function 'get_refs_via_rsync':
> >> transport.c:127:29: error: 'cmp' may be used uninitialized in this
> >> function [-Werror=uninitialized]
> >> transport.c:109:7: note: 'cmp' was declared here
> >>
> >> gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
> >
> > Right, that's the same version I noted above. Is 4.6.3 the default
> > compiler under a particular release of Ubuntu, or did you use their
> > gcc-4.6 package?
>
> I'll check later with one of my VMs. The copy of U 12.04 I happened
> to have handy has that version installed.
Ah, if you didn't explicitly run "gcc-4.6", then it was probably the
default version in 12.04 (as it was for a while in Debian testing, but
they never actually made a release with it, so everybody is now on 4.7
by default).
> By the way, I find this piece of code less than pleasant:
>
> * It uses "struct ref dummy = { NULL }, *tail = &dummy", and then
> accumulates things by appending to "&tail" and then returns
> dummy.next. Why doesn't it do
>
> struct ref *retval = NULL, **tail = &retval;
>
> and pass tail around to append things, like everybody else? Is
> this another instance of "People do not understand linked list"
> problem? Perhaps fixing that may unconfuse the compiler?
Ugh, that is horrible. At first I thought it was even wrong, as we pass
&tail and not &dummy.next to read_loose_refs. But two wrongs _do_ make a
right, because read_loose_refs, rather than do:
*tail = new;
tail = &new->next;
does:
(*tail)->next = new;
*tail = new;
> Later, the tail of the same list is passed to insert_packed_refs(),
> which does in-place merging of this list and the contents of the
> packed_refs file. These two data sources have to be sorted the
> same way for this merge to work correctly, but there is no
> validating the order of the entries it reads from the packed-refs
> file. At least, it should barf when the file is not sorted. It
> could be lenient and accept a mal-sorted input, but I do not think
> that is advisable.
Actually, it is the head of the loose list (though it is hard to
realize, because it is called tail!).
> I'll apply the attached on 'maint' for now, as rsync is not worth
> spending too many cycles on worrying about; I need to go to the
> bathroom to wash my eyes after staring this code for 20 minutes X-<.
Yeah, it's quite ugly. I really wonder if it is time to drop rsync
support. I'd be really surprised if anybody is actively using it.
I wonder, though, what made you look at this. It did not come up in my
list of -Wuninitialized warnings. Did it get triggered by one of the
other gcc versions?
> diff --git a/transport.c b/transport.c
> index 87b8f14..e6f9346 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -106,7 +106,8 @@ static void insert_packed_refs(const char *packed_refs, struct ref **list)
> return;
>
> for (;;) {
> - int cmp, len;
> + int cmp = 0; /* assigned before used */
> + int len;
>
> if (!fgets(buffer, sizeof(buffer), f)) {
> fclose(f);
I think that's fine.
-Peff
next prev parent reply other threads:[~2013-03-25 21:06 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-21 11:03 [PATCH 0/4] drop some "int x = x" hacks to silence gcc warnings Jeff King
2013-03-21 11:05 ` [PATCH 1/4] wt-status: fix possible use of uninitialized variable Jeff King
2013-03-21 19:49 ` Jonathan Nieder
2013-03-21 19:55 ` Junio C Hamano
2013-03-21 19:58 ` Jonathan Nieder
2013-03-22 16:15 ` Jeff King
2013-03-21 11:08 ` [PATCH 2/4] fast-import: use pointer-to-pointer to keep list tail Jeff King
2013-03-21 20:43 ` Jonathan Nieder
2013-03-21 11:10 ` [PATCH 3/4] drop some obsolete "x = x" compiler warning hacks Jeff King
2013-03-21 15:16 ` Erik Faye-Lund
2013-03-21 20:47 ` Jonathan Nieder
2013-03-24 7:17 ` Torsten Bögershausen
2013-03-21 11:13 ` [PATCH 4/4] transport: drop "int cmp = cmp" hack Jeff King
2013-03-21 20:59 ` Jonathan Nieder
2013-03-24 4:00 ` Junio C Hamano
2013-03-24 9:32 ` Jeff King
2013-03-24 14:54 ` Torsten Bögershausen
2013-03-25 19:50 ` Junio C Hamano
2013-03-25 21:06 ` Jeff King [this message]
2013-03-25 21:55 ` Junio C Hamano
2013-03-21 11:45 ` [PATCH 0/4] drop some "int x = x" hacks to silence gcc warnings Johannes Sixt
2013-03-21 11:55 ` Jeff King
2013-03-21 14:58 ` Junio C Hamano
2013-03-21 15:19 ` Junio C Hamano
2013-03-21 15:44 ` Jeff King
2013-03-21 15:44 ` [PATCH 5/4] fast-import: clarify "inline" logic in file_change_m Jeff King
2013-03-21 15:45 ` [PATCH 6/4] run-command: always set failed_errno in start_command Jeff King
2013-03-21 21:02 ` [PATCH 0/4] drop some "int x = x" hacks to silence gcc warnings Jonathan Nieder
2013-03-22 16:18 ` Jeff King
2013-03-22 16:19 ` [PATCH 7/4] submodule: clarify logic in show_submodule_summary Jeff King
2013-03-22 21:10 ` Junio C Hamano
2013-03-22 16:21 ` [PATCH 8/4] match-trees: drop "x = x" initializations Jeff King
2013-03-22 21:26 ` Junio C Hamano
2013-03-22 21:33 ` Junio C Hamano
2013-03-22 21:36 ` Jeff King
2013-03-23 18:57 ` René Scharfe
2013-03-24 4:55 ` Junio C Hamano
2013-03-24 10:01 ` Jeff King
2013-03-24 22:46 ` René Scharfe
2013-03-25 16:10 ` Junio C Hamano
2013-03-21 13:44 ` [PATCH 0/4] drop some "int x = x" hacks to silence gcc warnings Joachim Schmitz
2013-03-21 13:56 ` Joachim Schmitz
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=20130325210625.GA16386@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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).