Date: Fri, 18 Oct 2013 20:15:57 -0700
On 10/18/13, Stephan T. Lavavej <stl_at_[hidden]> wrote:
> [Gabriel Dos Reis, c++std-ext-14555]
>> My understanding of 'optional' is that the types are conditionally
>> supported, and a macro in <stdint.h> indicates whether the corresponding
>> type is supported.
>
> They are a special form of conditionally supported. C99 7.18.1.1
> "Exact-width integer types" /3: "These types are optional. However, if an
> implementation provides integer types with widths of 8, 16, 32, or 64 bits,
> no padding bits, and (for the signed types) that have a two's complement
> representation, it shall define the corresponding typedef names."
And there is the crucial difference, intN_t requires two's complement
representation, whereas the plain int types do not. There were machines
being sold in the 90's that were not two's complement, but I've lost track
since then. I am okay with requiring two's complement, for two reasons.
First, programmers are assuming it anyway, and since modern programmers
will almost never see anything different, they are right. Second, we had
to define the result of all atomic operations, and they use two's complement.
> I would like to see CHAR_BIT == 8 and two's complement required. I do not
> want to see specific type requirements for intN_t (in fact, char is
> impossible because it can be either signedish or unsignedish).
> [Gabriel Dos Reis, c++std-ext-14555]
>> My understanding of 'optional' is that the types are conditionally
>> supported, and a macro in <stdint.h> indicates whether the corresponding
>> type is supported.
>
> They are a special form of conditionally supported. C99 7.18.1.1
> "Exact-width integer types" /3: "These types are optional. However, if an
> implementation provides integer types with widths of 8, 16, 32, or 64 bits,
> no padding bits, and (for the signed types) that have a two's complement
> representation, it shall define the corresponding typedef names."
And there is the crucial difference, intN_t requires two's complement
representation, whereas the plain int types do not. There were machines
being sold in the 90's that were not two's complement, but I've lost track
since then. I am okay with requiring two's complement, for two reasons.
First, programmers are assuming it anyway, and since modern programmers
will almost never see anything different, they are right. Second, we had
to define the result of all atomic operations, and they use two's complement.
> I would like to see CHAR_BIT == 8 and two's complement required. I do not
> want to see specific type requirements for intN_t (in fact, char is
> impossible because it can be either signedish or unsignedish).
-- Lawrence Crowl
Received on 2013-10-19 05:16:00