[Omitting bits of Lawrence's email that I don't have anything to add to]

On Sun, Oct 27, 2013 at 6:32 PM, Lawrence Crowl <Lawrence_at_[hidden]> wrote:
> On Oct 27, 2013 3:46 PM, "Ion Gaztaņaga" <igaztanaga_at_[hidden]> wrote:
>> I think requiring 2's complement in the long term would be a
>> good idea, even in C, as no new architecture is using other
>> representation and this simplifies teaching and programming in
>> C/C++.
>
> Why do you think intN_t is not sufficient? The interpretation is
> that int means "representation is not relevant, add traps if you
> want" while (e.g.) int32_t means "I care about representation".

Take the DSP with CHAR_BIT==24: int16_t doesn't exist, but
int_least16_t does, and is 2's-complement and has no padding bits. Is
there currently any way to express a demand for 2's-complement but not
exact size on machines with large CHAR_BIT values?

> On 10/27/13, Jeffrey Yasskin <jyasskin_at_[hidden]> wrote:
>> I think I agree with everything in Ion's email, especially that the
>> ability to detect padding bits is useful, and that banning
>> CHAR_BIT>8 is probably a bad idea.
>>
>> One wrinkle in the goal to standardize 2's complement is the
>> ability to reinterpret the bytes of a negative integer as an array
>> of chars:
>
> unsigned chars?

Sure.

>> that seems harder to emulate, and possibly less needed to
>> allow programs to have portable behavior. If we have functions to
>> serialize and deserialize as 2's-complement byte arrays, we may not
>> need the ability to memcpy as them. 2's-complement behavior in
>> conversions and bitwise operations may be enough.
>
> Unless we are going to make the radical step of making the built-in
> integer types non-trivial, we get memcpy for free.

memcpy is guaranteed to transfer values through byte arrays, but the
values stored in the unsigned chars in the byte array aren't
specified. Specifying a 2's-complement integer representation would
seem to constrain the values in the unsigned chars making up the
integer's object representation (even if order isn't guaranteed,
popcount() would be), which is more than just specifying the results
of shifts, bitwise operations, and conversions. I'm suggesting we
consider the middle ground of avoiding implying a particular object
representation.