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

Gabriel Dos Reis gdr at microsoft.com
Sun Oct 20 19:36:39 CEST 2013


| -----Original Message-----
| From: ub-bounces at open-std.org [mailto:ub-bounces at open-std.org] On Behalf Of
| Xavier Leroy
| Sent: Sunday, October 20, 2013 3:05 AM
| To: ub at open-std.org
| Subject: Re: [ub] [c++std-ext-14555] Sized integer types and char bits
| 
| Gabriel Dos Reis writes:
| 
| > From my view, this underscores the importance for us to keep thinking
| > about the issues within a(n abstract) parameterized model, as opposed to
| > just the immediate hardware we are familiar with.  What do we gain by
| > instantiating the entire abstract machine with CHAR_BITS == 8?  I can't
| > tell.  Would we alienate computational devices?  Yes.  Do we care?
| > I think we should.  This is just one instance; but I have a sense that
| > we actually have a pattern here.
| 
| I agree with you concerning CHAR_BITS.  But I can't help thinking that
| other aspects of integer types could be fully defined without
| excluding any known computational device, with the benefit of
| simplifying the standards and providing programmers with firmer
| grounds to build software on.  For example:
| 
| - Two's complement representation for signed integer types.
|   (Have you seen any one's-complement or sign-magnitude architecture
|   these last 40 years?  I didn't think so.)

You are quite correct that I have not myself written code
for non-simulated hardware I have personal knowledge of being 
sign-magnitude or 1's complement.
However:
   a. Existence of such machines and their being continually sold
       have been reported by various people;
   b. It is not clear that the support for one's complement or sign-magnitude
       adds a substantial complication, or that a substantial simplification
       of the standards specification is to be gained from introducing that
       requirement.  For example, I don't think support for these binary
       representation would stop us from modifying the specification of
       signed integer arithmetic overflow -- my take-away from the Chicago
       meeting was that defining that be wrapping will be a very terrible idea
       would meet opposition.

| - The existence of intptr_t and uintptr_t types.
|   (Just the existence; no guarantees that pointers have unique
|   bit-pattern representations.)

I agree with you on this one.  I would like to see the standards 
require intptr_t and uintptr_t.


-- Gaby



More information about the ub mailing list