From: Junio C Hamano <gitster@pobox.com>
To: "SZEDER Gábor" <szeder.dev@gmail.com>
Cc: David Turner <novalis@novalis.org>,
Johannes Schindelin <johannes.schindelin@gmx.de>,
git@vger.kernel.org
Subject: Re: [PATCH 5/5] path.c: don't call the match function without value in trie_find()
Date: Wed, 23 Oct 2019 13:01:00 +0900 [thread overview]
Message-ID: <xmqqa79si003.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20191021205703.GB4348@szeder.dev> ("SZEDER =?utf-8?Q?G=C3=A1?= =?utf-8?Q?bor=22's?= message of "Mon, 21 Oct 2019 22:57:03 +0200")
SZEDER Gábor <szeder.dev@gmail.com> writes:
>> - b9317d55a3 added two new keys to the trie: 'logs/refs/rewritten'
>> and 'logs/refs/worktree', next to the already existing
>> 'logs/refs/bisect'. This resulted in a trie node with the path
>> 'logs/refs', which didn't exist before, and which doesn't have a
>
> Oops, I missed the trailing slash, that must be 'logs/refs/'!
>
>> value attached. A query for 'logs/refs/' finds this node and then
>> hits that one callsite of the match function which doesn't check
>> for the value's existence, and thus invokes the match function
>> with NULL as value.
Given that the trie is maintained by hand in common_list[], I wonder
if we can mechanically catch errors like the one b9317d55a3 added,
by perhaps having a self-test function that a t/helper/ program
calls to perform consistency check after the "git" gets built.
Thanks.
next prev parent reply other threads:[~2019-10-23 4:01 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-16 7:07 [PATCH 0/2] Handle git_path() with lock files correctly in worktrees Johannes Schindelin via GitGitGadget
2019-10-16 7:07 ` [PATCH 1/2] t1400: wrap setup code in test case Johannes Schindelin via GitGitGadget
2019-10-16 7:07 ` [PATCH 2/2] git_path(): handle `.lock` files correctly Johannes Schindelin via GitGitGadget
2019-10-16 11:04 ` SZEDER Gábor
2019-10-17 7:15 ` Junio C Hamano
2019-10-17 22:05 ` Johannes Schindelin
2019-10-18 11:06 ` SZEDER Gábor
2019-10-18 11:35 ` SZEDER Gábor
2019-10-21 16:00 ` [PATCH 0/5] path.c: a couple of common dir/trie fixes SZEDER Gábor
2019-10-21 16:00 ` [PATCH 1/5] Documentation: mention more worktree-specific exceptions SZEDER Gábor
2019-10-21 16:00 ` [PATCH 2/5] path.c: clarify trie_find()'s in-code comment SZEDER Gábor
2019-10-21 16:00 ` [PATCH 3/5] path.c: mark 'logs/HEAD' in 'common_list' as file SZEDER Gábor
2019-10-21 16:00 ` [PATCH 4/5] path.c: clarify two field names in 'struct common_dir' SZEDER Gábor
2019-10-21 16:00 ` [PATCH 5/5] path.c: don't call the match function without value in trie_find() SZEDER Gábor
2019-10-21 17:39 ` David Turner
2019-10-21 20:57 ` SZEDER Gábor
2019-10-23 4:01 ` Junio C Hamano [this message]
2019-10-23 16:20 ` SZEDER Gábor
2019-10-24 3:29 ` Junio C Hamano
2019-10-28 10:57 ` Johannes Schindelin
2019-10-28 12:00 ` SZEDER Gábor
2019-10-28 21:30 ` Johannes Schindelin
2019-10-18 11:42 ` [PATCH 0/2] path.c: minor common_list fixes SZEDER Gábor
2019-10-18 11:42 ` [PATCH 1/2] path.c: fix field name in 'struct common_dir' SZEDER Gábor
2019-10-18 11:42 ` [PATCH 2/2] path.c: mark 'logs/HEAD' in 'common_list' as file SZEDER Gábor
2019-10-21 19:35 ` [PATCH 0/2] path.c: minor common_list fixes Johannes Schindelin
2019-10-17 22:07 ` [PATCH v2 0/2] Handle git_path() with lock files correctly in worktrees Johannes Schindelin via GitGitGadget
2019-10-17 22:07 ` [PATCH v2 1/2] t1400: wrap setup code in test case Johannes Schindelin via GitGitGadget
2019-10-17 22:07 ` [PATCH v2 2/2] git_path(): handle `.lock` files correctly Johannes Schindelin via GitGitGadget
2019-10-18 1:23 ` Junio C Hamano
2019-10-18 12:35 ` SZEDER Gábor
2019-10-21 20:26 ` Johannes Schindelin
2019-10-23 2:12 ` Junio C Hamano
2019-10-21 21:54 ` [PATCH v3 0/2] Handle git_path() with lock files correctly in worktrees Johannes Schindelin via GitGitGadget
2019-10-21 21:54 ` [PATCH v3 1/2] t1400: wrap setup code in test case Johannes Schindelin via GitGitGadget
2019-10-21 21:54 ` [PATCH v3 2/2] git_path(): handle `.lock` files correctly Johannes Schindelin via GitGitGadget
2019-10-22 16:01 ` SZEDER Gábor
2019-10-23 3:38 ` Junio C Hamano
2019-10-28 12:01 ` Johannes Schindelin
2019-10-28 12:32 ` SZEDER Gábor
2019-10-28 17:30 ` Junio C Hamano
2019-10-28 12:57 ` [PATCH v4 0/2] Handle git_path() with lock files correctly in worktrees Johannes Schindelin via GitGitGadget
2019-10-28 12:57 ` [PATCH v4 1/2] t1400: wrap setup code in test case Johannes Schindelin via GitGitGadget
2019-10-28 12:57 ` [PATCH v4 2/2] git_path(): handle `.lock` files correctly Johannes Schindelin via GitGitGadget
2019-10-29 3:39 ` [PATCH v4 0/2] Handle git_path() with lock files correctly in worktrees Junio C Hamano
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=xmqqa79si003.fsf@gitster-ct.c.googlers.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=johannes.schindelin@gmx.de \
--cc=novalis@novalis.org \
--cc=szeder.dev@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.