Re: [PATCH] Properly align memory allocations and temporary buffers

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 6, 2022, 22:27 UTC
Message-ID: <xmqqh7agbiuq.fsf@gitster.g>
In-Reply-To: <YddjJ+uIQM34Gedo@nand.local>

Taylor Blau <me@ttaylorr.com> writes:

Show 14 quoted lines

> (+cc René as another possible reviewer)
>
> On Wed, Jan 05, 2022 at 01:23:24PM +0000, Jessica Clarke wrote:
>> Currently git_qsort_s allocates a buffer on the stack that has no
>> alignment, and mem_pool_alloc assumes uintmax_t's size is adequate
>> alignment for any type.
>>
>> On CHERI, and thus Arm's Morello prototype, pointers are implemented as
>> hardware capabilities which, as well as having a normal integer address,
>> have additional bounds, permissions and other metadata in a second word,
>> so on a 64-bit architecture they are 128-bit quantities, including their
>> alignment requirements. Despite being 128-bit, their integer component
>> is still only a 64-bit field, so uintmax_t remains 64-bit, and therefore
>> uintmax_t does not sufficiently align an allocation.

Alignment aside, if uintmax_t is 64-bit but your pointer needs 128-bit to store, saving a pointer value in uintmax_t variable would not work correctly, I presume, as casting the 64-bit integral type back into pointer would not be sufficient to recover the lost information that used to be in the second word.

So, does the architecture have 128-bit uintptr_t and that is a safe type both from the point of view of alignment and from the point of view of not losing information?

If that type is larger than uintmax_t, something smells wrong, though. max is not max anymore at that point.

IIRC, uintptr_t is optional in C99, so a simpler solution to use the larger type between uintptr_t and uintmax_t as a replacement for how we use uintmax_t would not quite work out of the box X-<.