On Fri, Oct 25, 2013 at 5:57 PM, Lawrence Crowl <Lawrence_at_[hidden]> wrote:

> On 10/25/13, Richard Smith <richardsmith_at_[hidden]> wrote:
> > On Oct 25, 2013, Gabriel Dos Reis <gdr_at_[hidden]>wrote:
> > > Matt Austern <austern_at_[hidden]> writes:
> > > > On Oct 25, 2013, Jeffrey Yasskin <jyasskin_at_[hidden]> wrote:
> > > > > Richard explicitly asked whether any such C++ users exist or
> > > > > are likely to exist in the future, and nobody's come up with
> > > > > any examples. So we appear to have a choice between helping
> > > > > some theoretical people or helping some actual people. (We
> > > > > help the actual people by telling them what to expect in the
> > > > > standard, while now they have to test and hope they find the
> > > > > right subset of undefined or implementation-defined behavior
> > > > > that's actually guaranteed to work.)
> > > >
> > > > It's actually a little worse than that. Testing can reveal
> > > > what your implementation does today, with your particular
> > > > input, with one set of compiler flags. No amount of testing
> > > > can reveal what guarantees your implementation makes.
> > >
> > > There are two separate issues here:
> > >
> > > (1) whether we want C++ to continue to support non-two's
> > > complement binary representation
> > > (2) what we want to say about overflowing shift arithmetic
> > >
> > > Requirint two's complement does not necessarily solve (2). And
> > > solving (2) does not necessarily imply "no" to (1).
> >
> > Agreed. It would definitely be interesting to complete Jeffrey's
> > list of the things we could define if we standardized 2s
> > complement, and then investigate how many of these we are
> > comfortable defining without specifying 2s complement. So far, we
> > have:
> >
> > 1) overflowing unsigned->signed conversions
> > 2) right-shifts on negative operands
> > 3) bitwise operators
> >
> > Are there others?
>
> While we are on this topic, we should list that defining a
> two's complement representation will exclude using 1000... as
> a trap value. I think that is the right decision once you have
> bitwise operators, because -1^INT_MAX yields the bit pattern.
>
> > (1) and (2) are currently implementation-defined;
>
> (1) is almost always the inverse of signed->unsigned conversion.
> However, I am not excited about either. I want a run-time
> diagnosis when I convert a negative number to unsigned or when
> I overflow a signed number when converting from unsigned. This
> diagnosis could happen from a new conversion operator, e.g.
> checked_cast<unsigned int>(-3).
>
> > (3) seems underspecified in the current standard.
>
> I have yet to use a machine in which s>>n was not implemented
> as floor(s/pow(2,n)), but then I've been using two's complement
> machines.
>
> > [I think for consistency we should at least make (3) say that
> > bitwise operators on positive operands act as "expected" (that
> > is, they give the result that a 2s complement, 1s complement
> > or sign-magnitude machine would), and we should make these
> > operations on other machines implementation-defined.
>
> I think we need a definition more specific than "expected". :)


The purpose of my "that is..." parenthetical was to informally define what
I meant by "expected" =)


> > More generally, we should at least say that each integral type
> > must be one of 1s complement, 2s complement or sign-magnitude.
> > C currently requires this (C99/C11 6.2.6.2/2), but C++ does not
> > (3.9.1/7's list of representations is not normative and not
> > restrictive). 7.2/8 implies that we don't support other
> > representations, but there's no normative justification for this
> > assumption.]
> >
> > If we require that either (1) or (3) acts as-if 2s complement,
> > that actually rules out 1s complement and sign-magnitude
> > representations, because these expressions compute a value that
> > does not exist in the other representations (-2147483648 for a
> > 32-bit integer):
> >
> > int(unsigned(INT_MAX) + 1) // for (1)
> > int(-1 ^ INT_MAX) // for (3)
> >
> > We could define that (2) acts as-if 2s complement (divide by 2^N
> > and round down). I think that's the least valuable operation to
> > define of the three, though.
>
> --
> Lawrence Crowl
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>