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.
