Re: [PATCH 01/11] diff: use hashmap_entry_init on moved_entry.ent
- From
Derrick Stolee <stolee@gmail.com>
- Date
- Aug 27, 2019, 13:31 UTC
- Message-ID
- <6414b671-db5b-4422-664d-ffbb8ee1a39a@gmail.com>
- In-Reply-To
- <20190826024332.3403-2-e@80x24.org>
On 8/25/2019 10:43 PM, Eric Wong wrote:
Show 24 quoted lines
> Otherwise, the hashmap_entry.next field appears to remain > uninitialized, which can lead to problems when > add_lines_to_move_detection calls hashmap_add. > > I found this through manual inspection when converting > hashmap_add callers to take "struct hashmap_entry *". > > Signed-off-by: Eric Wong <e@80x24.org> > --- > diff.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/diff.c b/diff.c > index efe42b341a..02491ee684 100644 > --- a/diff.c > +++ b/diff.c > @@ -964,8 +964,9 @@ static struct moved_entry *prepare_entry(struct diff_options *o, > struct moved_entry *ret = xmalloc(sizeof(*ret)); > struct emitted_diff_symbol *l = &o->emitted_symbols->buf[line_no]; > unsigned flags = o->color_moved_ws_handling & XDF_WHITESPACE_FLAGS; > + unsigned int hash = xdiff_hash_string(l->line, l->len, flags); > > - ret->ent.hash = xdiff_hash_string(l->line, l->len, flags); > + hashmap_entry_init(&ret->ent, hash);
I've typically seen these hashmap_entry_init() calls include the hash function in-line instead of saving to a variable. But, this looks fine and is obviously correct.
Thanks, -Stolee