[ub] [c++std-ext-14555] Sized integer types and char bits

Gabriel Dos Reis gdr at microsoft.com
Fri Oct 18 22:22:30 CEST 2013


| -----Original Message-----
| From: ub-bounces at open-std.org [mailto:ub-bounces at open-std.org] On Behalf Of
| Matt Austern
| Sent: Friday, October 18, 2013 12:55 PM
| To: WG21 UB study group
| Cc: c++std-ext at accu.org
| 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 exchange.microsoft.com
| <mailto:stl at exchange.microsoft.com> > 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



More information about the ub mailing list