Subject: Re: [ub] [c++std-ext-14555] Sized integer types and char bits
From: Gabriel Dos Reis (gdr_at_[hidden])
Date: 2013-10-20 12:36:39
| -----Original Message-----
| From: ub-bounces_at_[hidden] [mailto:ub-bounces_at_[hidden]] On Behalf Of
| Xavier Leroy
| Sent: Sunday, October 20, 2013 3:05 AM
| To: ub_at_[hidden]
| 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.
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.
SG12 list run by herb.sutter at gmail.com