1 << 31 poll is not a decision in the sense that the committee decided to
make the change. The polled option is contradictory with the option polled
immediately after.
The second option has more consensus in the context of the group in the
room, but it simply means that both options may be further explored.

-- HT

On Fri, Mar 16, 2018 at 3:06 PM, Myria <myriachan_at_[hidden]> wrote:

> I really don't like this decision on 1 << 31 at all. I've already
> written code that is in a production library that uses 1 << 31 in a
> constexpr context, which would be ill-formed.
>
> On Fri, Mar 16, 2018 at 11:20 AM, Arthur O'Dwyer
> <arthur.j.odwyer_at_[hidden]> wrote:
> > (Dropped some marginally relevant lists I get mod-queued on anyway)
> >
> >> The notes should help clarify RIchard's rationale for proposing this.
> >
> > http://wiki.edg.com/bin/view/Wg21jacksonville2018/Sg6P0907R0 has some
> > discussion from Richard (Smith?) about (1<<32) needing to remain
> IDB-at-best
> > on x86 platforms (Ctrl+F "crypto"). Total agreement on that front.
> > I don't see any notes on that page which are relevant to (1<<31) —
> there's
> > just the straw poll results with zero prior discussion notated.
> >
> >> Shifting out of range (1 << 31) as currently defined (if shift has
> defined
> >> value when interpreted as unsigned, you get the value as signed, you can
> >> dhigt into but not past the sign, shifting past sign bit is UB), 1<<31
> was
> >> defined and still is (as of Howard's paper), 2<<31 was UB and still is,
> WG14
> >> is currently considering whether to adopt Howard's paper which made
> this.
> >> Should we take it back to undefined to do 1<<31?
> >> SS F N A SA
> >> 2 7 5 1 1
> >
> >
> > Am I looking at the wrong page, perhaps?
> >
> > Thanks,
> > Arthur
> >
> > P.S. — Alternatively, since 0x80000000 is allowed to be a trap
> > representation in P0907r1 but 0xC0000000 is not, perhaps the intent of
> this
> > straw poll was that 1<<31 should be UB but 3<<30 should be well-defined.
> > That would be extra weird, though, so I hope that's not what happened.
> >
> >
> > On Fri, Mar 16, 2018 at 11:06 AM, JF Bastien <cxx_at_[hidden]> wrote:
> >>
> >> On Fri, Mar 16, 2018 at 2:04 PM, Arthur O'Dwyer
> >> <arthur.j.odwyer_at_[hidden]> wrote:
> >>>
> >>> P0907r1 proposes this addition relative to the WD:
> >>>
> >>> > If overflow caused by an operation which would require representing
> an
> >>> > integer which cannot be represented by the type, the behavior is
> undefined.
> >>>
> >>> However, it simultaneously proposes these deletions relative to the WD:
> >>>
> >>> > [Note: Operators can be regrouped according to the usual mathematical
> >>> > rules only where the operators really are associative or commutative
> ...
> >>> and
> >>> > an operation that would have undefined behavior as specified in
> Clause
> >>> > 4 through 19 of this document [Note: including, for example, signed
> integer
> >>> > overflow, certain pointer arithmetic, division by zero, or certain
> shift
> >>> > operations —end note]
> >>>
> >>> The removals are all non-normative, but they seem to be aimed at
> >>> eliminating references to "signed overflow is UB", even though signed
> >>> overflow is still UB. Was there a sense in the room that we wanted to
> >>> downplay the importance of teaching signed UB in C++, but not actually
> >>> eliminate the UB itself? Or what's the point of re-wording these
> existing
> >>> notes?
> >>
> >>
> >> There was extensive discussion of this note, what to add / remove, etc,
> >> and no direction as to where to go. I'll ask EWG today.
> >>
> >>>
> >>> Also, separately and less importantly, I'd love to hear someone's
> >>> rationale for making (1<<31) UB in C++2a when it's IDB in C++17. The
> straw
> >>> poll result in P0907r1 sounds unambiguous, but I don't understand what
> >>> rationale could exist for taking this construct from IDB into UB. Is
> the
> >>> assumption that people haven't yet had a chance to write any programs
> whose
> >>> correctness depends on the value of (1<<31), so if we change it back
> to UB
> >>> fast enough, nobody will notice?
> >>
> >>
> >> The notes should help clarify RIchard's rationale for proposing this.
> >>
> >>>
> >>> –Arthur
> >>>
> >>>
> >>>
> >>> On Fri, Mar 16, 2018 at 8:56 AM, JF Bastien <cxx_at_[hidden]> wrote:
> >>>>
> >>>> Hello EWG,
> >>>>
> >>>> SG6 and SG12 discussed wg21.link/P0907r0 Signed Integers are Two’s
> >>>> Complement and provided extensive feedback.
> >>>>
> >>>> I've attached an updated paper listing polls and addressing most
> >>>> feedback (except some wording fiddle) to the EWG wiki for this
> afternoon's
> >>>> discussion:
> >>>>
> >>>>
> >>>> http://wiki.edg.com/pub/Wg21jacksonville2018/
> EvolutionWorkingGroup/D0907r1.html
> >>>>
> >>>>
> >>>> Thanks,
> >>>>
> >>>> JF
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> ub mailing list
> >>>> ub_at_[hidden]
> >>>> http://www.open-std.org/mailman/listinfo/ub
> >>>>
> >>>
> >>
> >
> >
> > _______________________________________________
> > ub mailing list
> > ub_at_[hidden]
> > http://www.open-std.org/mailman/listinfo/ub
> >
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>