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

John Spicer jhs at edg.com
Fri Oct 18 22:32:21 CEST 2013


On Oct 18, 2013, at 4:22 PM, Gabriel Dos Reis <gdr at microsoft.com> wrote:

> | -----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.
> 

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.



More information about the ub mailing list