| -----Original Message-----
| From: ub-bounces_at_[hidden] [mailto:ub-bounces_at_[hidden]] On Behalf Of
| John Spicer
| Sent: Friday, October 18, 2013 1:32 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 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.

Good question! :-)

-- Gaby