Phillip Wood wrote:
> Hi Eric
>
> On 27/08/2019 10:49, Eric Wong wrote:
> > Johannes Schindelin wrote:
> > > Hi Eric,
> > >
> > > On Mon, 26 Aug 2019, Eric Wong wrote:
> > >
> > > > By renaming the "hash" field to "_hash", it's easy to spot
> > > > improper initialization of hashmap_entry stru
Hi Junio,
On Tue, 27 Aug 2019, Junio C Hamano wrote:
> My plan is to have ew/hashmap topic for a few days while ejecting
> the js/add-i topic which semantically conflicts with the changed way
> hashmaps ought to be used temporarily, and when I have enough time
> and concentration, try to see if I
Hi Eric
On 27/08/2019 10:49, Eric Wong wrote:
Johannes Schindelin wrote:
Hi Eric,
On Mon, 26 Aug 2019, Eric Wong wrote:
By renaming the "hash" field to "_hash", it's easy to spot
improper initialization of hashmap_entry structs which
can leave "hashmap_entry.next" uninitialized.
Would you
Eric Wong writes:
> I renamed it to intentionally break my build.
This cuts both ways. If you work without any throw-away merges, it
is GOOD to make sure any new use other people added will be spotted
by the compiler by breaking the build. It will force you to resolve
all such breakages until
Johannes Schindelin wrote:
> Hi Eric,
>
> On Mon, 26 Aug 2019, Eric Wong wrote:
>
> > By renaming the "hash" field to "_hash", it's easy to spot
> > improper initialization of hashmap_entry structs which
> > can leave "hashmap_entry.next" uninitialized.
>
> Would you mind elaborating a bit? Thi
Hi Eric,
On Mon, 26 Aug 2019, Eric Wong wrote:
> By renaming the "hash" field to "_hash", it's easy to spot
> improper initialization of hashmap_entry structs which
> can leave "hashmap_entry.next" uninitialized.
Would you mind elaborating a bit? This explanation does not enlighten
me, sadly, al
By renaming the "hash" field to "_hash", it's easy to spot
improper initialization of hashmap_entry structs which
can leave "hashmap_entry.next" uninitialized.
Signed-off-by: Eric Wong
---
builtin/fast-export.c | 5 +++--
hashmap.c | 9 +
hashmap.h
7 matches
Mail list logo
