On Fri, May 11, 2018 at 6:49 AM, Junio C Hamano <gits...@pobox.com> wrote: > Junio C Hamano <gits...@pobox.com> writes: > >> René Scharfe <l....@web.de> writes: >> >>>> But it somehow feels backwards in spirit to me, as the reason why we >>>> use "void *" there in the decoration field is because we expect that >>>> we'd have a pointer to some struture most of the time, and we have >>>> to occasionally store a small integer there. >>> >>> Yes, fast-export seems to be the only place that stores an integer as >>> a decoration. >> >> With the decoration subsystem that might be the case, but I think >> we have other codepaths where "void * .util" field in the structure >> is used to store (void *)1, expecting that a normal allocation will >> never yield a pointer that is indistinguishable from that value. > > I was looking at a different topic and noticed that bisect.c uses > commit->util (which is of type "void *") to always store an int (it > never stores a pointer and there is no mixing). This one is equally > unportable as fast-export after your fix. >
In both cases we should be able to use commit-slab instead of commit->util. We could go even further and kill "util" pointer but that's more work. -- Duy
