Date: Fri, 18 Oct 2013 20:22:30 +0000
| -----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.
-- Gaby
| 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.
-- Gaby
Received on 2013-10-18 22:22:54