On Oct 18, 2013, at 4:22 PM, Gabriel Dos Reis <gdr_at_[hidden]> wrote:

> | -----Original Message-----
> | From: ub-bounces_at_[hidden] [mailto:ub-bounces_at_[hidden]] On Behalf Of
> | Matt Austern
> | Sent: Friday, October 18, 2013 12:55 PM
> | To: WG21 UB study group
> | Cc: c++std-ext_at_[hidden]
> | Subject: Re: [ub] [c++std-ext-14555] Sized integer types and char bits
> |
> | On Fri, Oct 18, 2013 at 12:05 PM, Stephan T. Lavavej <stl_at_[hidden]
> | <mailto: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."
> |
> | 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).
> |
> |
> | And as far as I can tell, int8_t is forbidden to be char even on a system where char
> | can represent negative numbers. The standard says that int8_t must be a "signed
> | integer type". Even though char is an integer type that is signed on some
> | implementations, my reading of the standard is that it is not a signed integer type.
> | That term refers to a specific list of types and char does not appear on that list.
> |
> | --Matt
>
> Indeed, I would expect an implementation that provides int8_t to typedef it to
> 'signed char', if and when that datatype meets the requirement.
>
> Concerning CHAR_BIT, I don't have any dog in the fight, but I would caution
> us from doing anything that leaves room between C and C++ for C to fill.
> "C++ as a better C" should still hold as we are roaming through the 21st century.
> I do not think we have enough compelling reasons to alienate systems where
> CHAR_BIT isn't 8. And in fact, in practice it isn't much of a problem. Those
> who care only for CHAR_BIT == 8 systems will continue to support only those.
>

What does requiring CHAR_BIT == 8 buy us? Sorry if I missed that detail in the large volume of messages in this thread.

Thanks,

John.