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