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

From: Jessica Clarke <jrtc27@jrtc27.com>
Date: Jan 7, 2022, 00:39 UTC
Message-ID: <4D8B32AE-8316-4907-98F6-097901EC3DC0@jrtc27.com>
In-Reply-To: <YdeJ8Ub2Q0/c9kO2@camp.crustytoothpaste.net>

On 7 Jan 2022, at 00:31, brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 10 quoted lines

> 
> On 2022-01-07 at 00:10:21, Junio C Hamano wrote:
>> Jessica Clarke <jrtc27@jrtc27.com> writes:
>> 
>>> This is also true of uint128_t, it doesn’t fit in a uintmax_t either.
> 
> I don't have this type from either GCC or Clang on my Debian amd64/sid
> system.  I know those compilers support 128-bit values because Rust uses
> them, but they are not exposed in standard C and therefore those
> compilers appear to be compliant when run in standards mode.

Ah, I should have said (un)(signed) __int128, there is no typedef for them even in GNU C.

__int128 exists as an integer type even with -std=c99, not just -std=gnu99. -pedantic will warn that __int128 does not exist in ISO C, but __int128__ still exists and works with no warnings even then. So it very much exists in standards mode.

Show 20 quoted lines

>> uintmax_t is supposed to be an unsigned integer type capable of
>> representing any value of any unsigned integer type, so if you have
>> 128-bit unsigned integer, your uintmax_t should be at last that
>> wide, or your uintmax_t is not uintmax_t as far as C standard is
>> concerned, no?
>> 
>> uintptr_t is an unsigned integer type that any valid pointer to void
>> can be converted to this type, then converted back to pointer to
>> void, and the result will compare equal to the original pointer.  So
>> the value of uintptr_t cannot be represented by uintmax_t, there is
>> something wrong.
> 
> Yes, this is the case.  The C standard mandates this behavior.
> 
> Now, as far as I'm aware, the standard does not mandate that that
> uintmax_t have the strictest alignment requirements of any integral
> type.  It could be that other types have stricter requirements, for
> example, on some systems.  But it is required that conversion from void *
> to uintptr_t to uintmax_t to uintptr_t to void * preserve the
> functionality of the pointer.

To quote what I said to Junio in a futher reply:

Show 20 quoted lines

> If you want to get really language-lawyer-y about it, you can actually
> argue that this is a compliant implementation of the C standard.
> Integer types are permitted to have padding bits, and some combinations
> of padding bits are allowed to be trap representations. Technically, in
> our representation, the metadata bits are padding bits, because they do
> not contribute to the precision like value bits. It is therefore the
> case that the *value* of a uintptr_t still fits into a uintmax_t, but
> the latter has no padding bits, and casting the latter to the former
> yields a trap representation when further cast back to a pointer. This
> may not the intent of the spec, and not how anyone thinks of it because
> CHERI is the first implementation that pushes the boundary here, but
> it’s technically legal under that interpretation. You may disagree with
> the interpretation, and I don’t like to use it most of the time because
> it’s complicated and involves yet more ill-defined parts of the spec
> (e.g. it says arithmetic operations on valid values (they mean objects,
> I assume, as the value only includes value bits, but the input could be
> a trap representation on some implementations) never generate a trap
> representation other than as part of an exceptional condition such as
> an overflow, but nowhere defines what counts as an arithmetic
> operation).

So, no, C does not actually require what you say. It requires that void
* -> uintptr_t -> void * give you a valid pointer. It requires that
uintptr_t -> uintmax_t preserves the *value* of the uintptr_t, which we
do, because the value is formed from only the value bits which
contribute to the precision, which is 64 bits in this case, and
uintmax_t is still 64-bit. It requires that uintmax_t -> uintptr_t,
since uintptr_t’s precision is the same as uintmax_t’s, be always
valid, which is is. But it does not require that that uintptr_t has the
same representation as the original uintptr_t, which it does not for
us. And therefore it does not require that casting that uintptr_t back
to a void * yields a valid pointer. So if you want to really dig into
the details of the standard, we are technically compliant, even if some
might argue it’s not in the spirit of the standard.

Jess