(Added JF Bastien to this thread, because I don't know whether they
are on this mailing list.)

Since the filing deadline for Jacksonville has already passed, how
would filing a response paper work? I don't know the procedures in
this regard.

JF, would you want to write a version of your paper that was more
conservative (leaving signed overflow and shift by >= bit count
undefined) as a paired alternative proposal?

Melissa

On Thu, Feb 15, 2018 at 4:16 PM, Arthur O'Dwyer
<arthur.j.odwyer_at_[hidden]> wrote:
> On Thu, Feb 15, 2018 at 3:51 PM, Hubert Tong
> <hubert.reinterpretcast_at_[hidden]> wrote:
>>
>> On Thu, Feb 15, 2018 at 6:44 PM, David Vandevoorde <daveed_at_[hidden]> wrote:
>>>
>>> > On Feb 15, 2018, at 5:14 PM, Myria <myriachan_at_[hidden]> wrote:
>>> >
>>> > I'm personally on the side of defining signed overflow as wrapping,
>>> > but compiler people do have a point that it would inhibit
>>> > optimizations in certain cases involving signed integers.
>>>
>>> My understanding is that it kills a significant optimization opportunity
>>> (that is currently taken advantage of by compilers).
>>
>> I also believe that it makes it harder for tooling to flag unintentional
>> signed overflow.
>
>
> Yes.
>
> I am considering writing a response to JF's P0907 in which I would propose
> "just the good bits" — namely, remove sign-magnitude and ones'-complement
> from the standard, and perhaps give defined behavior to (-1 << 1) and (-1 >>
> 1), but conservatively retain the undefined behavior of (INT_MAX + 1) and (1
> << 100). I think such a conservative proposal might stand a chance these
> days; it feels analogous to the removal of trigraphs.
> Defining (INT_MAX+1 == INT_MIN), as proposed by P0907? No, that will never
> happen in a million years.
>
> However, I personally will not be at JAX, and if someone beats me to writing
> this paper, I will not be upset. :)
>
> –Arthur
>
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>