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. > Using struct decorate in fast-export has the benefit of not > requiring separate allocations for individual entries. Switching to > struct hashmap would require individual allocations. Adding a > custom clone of decorate with a uint32_t payload would be an option. As long as we know uint32_t is no wider than uintptr_t, your patch should be safe, shouldn't it?
