Re: [PATCH] fast-export: avoid NULL pointer arithmetic

From: Junio C Hamano <gitster@pobox.com>
Date: May 11, 2018, 02:16 UTC
Message-ID: <xmqqbmdnhr8b.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <654fac2a-8dca-7bee-2bab-a3986aa7e52d@web.de>

René Scharfe <l.s.r@web.de> writes:

Show 7 quoted lines

>> 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?