| -----Original Message-----
| From: ub-bounces_at_[hidden] [mailto:ub-bounces_at_[hidden]] On Behalf Of
| Lawrence Crowl
| Sent: Wednesday, October 23, 2013 11:36 PM
| To: WG21 UB study group
| Cc: c++std-ext_at_[hidden]; Xavier Leroy
| Subject: Re: [ub] [c++std-ext-14555] Sized integer types and char bits
|
| On 10/20/13, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
| > 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.
|
| While I am one of the folks advocating undefined behavior for integer
| overflow, I do not think that implies that we do not care about the
| representation of sign.

Indeed; and I was not trying to imply that people on the "undefined" side
do not care about programmers and errors. Quite the contrary. I am
working on a document that attempts to explain this further.

| In particular, knowing that (a) there is no
| trap value and (b) that there is a 1-1 mapping from pit patterns to
| integral numbers affects how programmers interpret data.
|
| Having said that, my expectation is that programmers that care about
| (a) and (b) also care about the size of the integer. In that case,
| int32_t et.al. require a two's complement representation. The
| programmers that care should use those typedefs.

Correct. Of concern is that the fact that intN_t integer types are
"optional" (in the sense of conditionally-supported), and some people
worry about the effect of writing portable codes. I can see how
that can be a problem on most common "desktop" architectures
since interfaces published in terms of typedefs (to builtin types)
don't play ball very well with overloading.

| Net result, no change to the standard.

Well, I would like to see _something_ done in this area -- exactly, what?
I don't know yet :-)

For instance, what we lose if we go from undefined behavior to
unspecified? E.g. the behavior on erroneous construct isn't unrestricted
yet allow for tools to instrument and/or report?

-- Gaby