Topic: More conservative version of P0907 "Signed
Author: JF Bastien <jfbastien@apple.com>
Date: Fri, 23 Feb 2018 14:11:51 -0800
Raw View
--Boundary_(ID_MZ2pPvhCsRoA2CLuNCqMtA)
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Hi Arthur,
I=E2=80=99ll be in JAX and will definitely champion my own approach, but wi=
ll make sure any other approaches are discussed thoroughly. I=E2=80=99ll th=
en ask for direction polls from EWG, and will follow the proposed direction=
in an updated paper.
I=E2=80=99d therefore appreciate it if you instead had rationales for why y=
ou=E2=80=99d take a different approach. I offered my rationale for going th=
e direction I suggest, and the right thing to change people=E2=80=99s minds=
is to offer compelling arguments to go in another direction. Ideally you=
=E2=80=99d have data to back up any performance / bug finding / odd archite=
cture claims. Do you think you have time to get this together before JAX? T=
hat=E2=80=99s definitely something I=E2=80=99d present along my paper, thou=
gh I might disagree.
In the end I simply want two=E2=80=99s complement, and I see a few ways tha=
t this play out with everyone liking the outcome. I just ask that oppositio=
n comes with rationales, not =E2=80=9CI like my way better=E2=80=9D. :-)
JF
> On Feb 23, 2018, at 14:05, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wro=
te:
>=20
> The pre-JAX mailing contains this discussion-provoking paper by JF Bastie=
n:
> P0907R0 "Signed Integers are Two's Complement" <http://www.open-std.org/j=
tc1/sc22/wg21/docs/papers/2018/p0907r0.html>
>=20
> My understanding is that JF wants to use this "modest proposal" (for wrap=
ping arithmetic on `int`, among other things) as a way to incite discussion=
among the Committee.
>=20
> I have created an as-yet-unofficial "conservative fork" of the proposal, =
which removes the parts that I think are airballs, while leaving in much of=
what I consider the good stuff =E2=80=94 notably, making signed-to-unsigne=
d and unsigned-to-signed conversions well-defined in terms of two's complem=
ent representations, and defining what happens when you bit-shift into or o=
ut of the sign bit.
> https://quuxplusone.github.io/draft/twosc-conservative.html <https://quux=
plusone.github.io/draft/twosc-conservative.html>
>=20
> I hope that if the Committee asks JF to come back with a more conservativ=
e proposal, the existence of my "conservative fork" will save time, possibl=
y even allow further discussion later in the week at JAX.
>=20
> I personally will not be at JAX, though. JF, will you be? Could I count =
on you to... not to "champion" my unsubmitted paper, of course, but just to=
be aware of it in case something like it is asked for by the Committee? I=
mean, the worst-case, which I would like to avoid, is that JF's paper is r=
ejected as too crazy and then the entire subject is tabled until Rapperswil=
.. I would like to see some concrete progress in this department at JAX if h=
umanly possible.
>=20
> =E2=80=93Arthur
>=20
> P.S. =E2=80=94 Also, if anyone on std-proposals has objections to the spe=
cific diffs in my conservative proposal, I would like to know about it. I d=
eliberately tried to remove any whiff of controversy from the diff. (This =
is distinct from objecting to my presumptuousness or objecting to wasting t=
he Committee's time. ;))
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/53F0ECAD-6569-42FA-9675-1FB73DFAC6EA%40apple.com=
..
--Boundary_(ID_MZ2pPvhCsRoA2CLuNCqMtA)
Content-type: text/html; charset="UTF-8"
Content-transfer-encoding: quoted-printable
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; line-break: after-white-space;" class=3D"">Hi Arthur,<div class=3D"">=
<br class=3D""></div><div class=3D"">I=E2=80=99ll be in JAX and will defini=
tely champion my own approach, but will make sure any other approaches are =
discussed thoroughly. I=E2=80=99ll then ask for direction polls from EWG, a=
nd will follow the proposed direction in an updated paper.</div><div class=
=3D""><br class=3D""></div><div class=3D"">I=E2=80=99d therefore appreciate=
it if you instead had rationales for why you=E2=80=99d take a different ap=
proach. I offered my rationale for going the direction I suggest, and the r=
ight thing to change people=E2=80=99s minds is to offer compelling argument=
s to go in another direction. Ideally you=E2=80=99d have data to back up an=
y performance / bug finding / odd architecture claims. Do you think you hav=
e time to get this together before JAX? That=E2=80=99s definitely something=
I=E2=80=99d present along my paper, though I might disagree.</div><div cla=
ss=3D""><br class=3D""></div><div class=3D"">In the end I simply want two=
=E2=80=99s complement, and I see a few ways that this play out with everyon=
e liking the outcome. I just ask that opposition comes with rationales, not=
=E2=80=9CI like my way better=E2=80=9D. :-)</div><div class=3D""><br class=
=3D""></div><div class=3D"">JF<br class=3D""><div class=3D""><div><br class=
=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Feb 23, 2018,=
at 14:05, Arthur O'Dwyer <<a href=3D"mailto:arthur.j.odwyer@gmail.com" =
class=3D"">arthur.j.odwyer@gmail.com</a>> wrote:</div><br class=3D"Apple=
-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D""><div clas=
s=3D"">The pre-JAX mailing contains this discussion-provoking paper by JF B=
astien:</div><div class=3D""><a href=3D"http://www.open-std.org/jtc1/sc22/w=
g21/docs/papers/2018/p0907r0.html" class=3D"">P0907R0 "Signed Integers are =
Two's Complement"</a></div><div class=3D""><br class=3D""></div><div class=
=3D"">My understanding is that JF wants to use this "modest proposal" (for =
wrapping arithmetic on `int`, among other things) as a way to incite discus=
sion among the Committee.</div><br class=3D""><div class=3D"">I have create=
d an as-yet-unofficial "conservative fork" of the proposal, which removes t=
he parts that I think are airballs, while leaving in much of what I conside=
r the good stuff =E2=80=94 notably, making signed-to-unsigned and unsigned-=
to-signed conversions well-defined in terms of two's complement representat=
ions, and defining what happens when you bit-shift into or out of the sign =
bit.</div><div class=3D""><a href=3D"https://quuxplusone.github.io/draft/tw=
osc-conservative.html" class=3D"">https://quuxplusone.github.io/draft/twosc=
-conservative.html</a><br class=3D""></div><div class=3D""><br class=3D""><=
/div><div class=3D"">I hope that if the Committee asks JF to come back with=
a more conservative proposal, the existence of my "conservative fork" will=
save time, possibly even allow further discussion later in the week at JAX=
..<br class=3D""></div><div class=3D""><br class=3D""></div><div class=3D"">=
I personally will not be at JAX, though. JF, will you be? Could I cou=
nt on you to... not to "champion" my unsubmitted paper, of course, but just=
to be aware of it in case something like it is asked for by the Committee?=
I mean, the worst-case, which I would like to avoid, is that JF's pa=
per is rejected as too crazy and then the entire subject is tabled until Ra=
pperswil. I would like to see some concrete progress in this department at =
JAX if humanly possible.</div><div class=3D""><br class=3D""></div><div cla=
ss=3D"">=E2=80=93Arthur</div><div class=3D""><br class=3D""></div><div clas=
s=3D"">P.S. =E2=80=94 Also, if anyone on std-proposals has objections to th=
e specific diffs in my conservative proposal, I would like to know about it=
.. I deliberately tried to remove any whiff of controversy from the diff. &n=
bsp;(This is distinct from objecting to my presumptuousness or objecting to=
wasting the Committee's time. ;))</div></div>
</div></blockquote></div><br class=3D""></div></div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/53F0ECAD-6569-42FA-9675-1FB73DFAC6EA%=
40apple.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/53F0ECAD-6569-42FA-9675-1FB73DFAC6EA%=
40apple.com</a>.<br />
--Boundary_(ID_MZ2pPvhCsRoA2CLuNCqMtA)--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Fri, 23 Feb 2018 14:47:20 -0800
Raw View
--001a114011e273b4eb0565e8f1e9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Fri, Feb 23, 2018 at 2:11 PM, JF Bastien <jfbastien@apple.com> wrote:
> Hi Arthur,
>
> I=E2=80=99ll be in JAX and will definitely champion my own approach, but =
will make
> sure any other approaches are discussed thoroughly. I=E2=80=99ll then ask=
for
> direction polls from EWG, and will follow the proposed direction in an
> updated paper.
>
And if you manage to write the updated paper overnight and have it back on
the table the next day at JAX, then my paper *will* be utterly superfluous.
:)
I am, however, worried that the writing of a new paper might slip more than
a day, which would end up with you coming back in the pre-Rapperswil
mailing with another two's-complement paper after the perception that your
first two's-complement paper was "rejected" in Jacksonville, which would
set a perceived negative precedent in people's minds.
> I=E2=80=99d therefore appreciate it if you instead had rationales for why=
you=E2=80=99d
> take a different approach. I offered my rationale for going the direction=
I
> suggest, and the right thing to change people=E2=80=99s minds is to offer
> compelling arguments to go in another direction. Ideally you=E2=80=99d ha=
ve data to
> back up any performance / bug finding / odd architecture claims. Do you
> think you have time to get this together before JAX? That=E2=80=99s defin=
itely
> something I=E2=80=99d present along my paper, though I might disagree.
>
I agree that rationales are good things, and I don't want to go too "tu
quoque" here, but... *does* your paper include any rationale? The closest
thing I see is in the "Introduction", where my version strikes out these
two bullets from your version:
-
Associativity and commutativity of integers is needlessly obtuse.
-
Na=C3=AFve overflow checks, which are often security-critical, often get
eliminated by compilers. This leads to exploitable code when the intent =
was
clearly not to and the code, while na=C3=AFve, was correctly performing =
security
checks for two=E2=80=99s complement integers. Correct overflow checks ar=
e difficult
to write and equally difficult to read, exponentially so in generic code=
..
These are true, but then the current undefined behavior on signed overflow
has some unmentioned good effects, too:
- Unintentional unsigned wraparound (for example, in the argument to
`malloc`) has been a known source of bugs for a long time. See for example
[Regehr2012] <https://www.cs.utah.edu/~regehr/papers/overflow12.pdf>, whose
final sentence is, "Our results also imply that tools for detecting integer
numerical errors need to *distinguish intentional from unintentional uses
of wraparound operations* =E2=80=94 a challenging task =E2=80=94 in order t=
o minimize false
alarms. [emphasis added]" The current undefinedness of signed overflow
permits implementations, such as UBSan, to detect all signed wraparound
behavior as unintentional by definition, and diagnose it accordingly.
- The impossibility of signed wraparound allows optimization of tight inner
loops such as
for (int i =3D a; i !=3D b; ++i)
Here the compiler is allowed to assume that `a <=3D b`, because if `b < a`
the loop would eventually overflow and invoke undefined behavior. This is
intuitively the same behavior that we have with C++ iterators: the compiler
is allowed to assume that the existence of a loop over the range `a` to `b`
implies that `b` is actually reachable from `a` according to
forward-increment semantics, even though in practice many implementations'
std::list::iterator internally performs the equivalent of "wrap on
overflow." (See the graphical diagram of "sentinel-node containers" in P077=
3
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0773r0.html#B> if
needed.)
John McFarlane did a lightning talk about integer UB and codegen within the
past year but I don't know if the slides are somewhere. I can ask him.
I mean, it's not like there's any shortage of educational material on UB in
C and C++ and its *good and* bad effects.
What there *is* a shortage of IMHO is material on *ones'-complement* in C
and C++. That's why I kept large swaths of your paper intact in my fork. :)
In the end I simply want two=E2=80=99s complement, and I see a few ways tha=
t this
> play out with everyone liking the outcome. I just ask that opposition com=
es
> with rationales, not =E2=80=9CI like my way better=E2=80=9D. :-)
>
Yes; just remember that the rationale for making *no change at all* is
invariably really strong.
And getting the camel's nose into the tent in 2018 does not preclude
getting the rest of the camel at some point! I just want to make as sure
as possible that we can get the nose in. Because even the nose will be
useful. (The "nose" includes arithmetic right-shift, for example. And
well-defined casts from int16_t to int8_t. These are very useful features
to get into C++ even if the rest of the camel remains outside forever!)
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0%2Bkq5hFWG6UqZyLFOEsPNunLM4zVrn0ym6s05Cf6=
QGJxw%40mail.gmail.com.
--001a114011e273b4eb0565e8f1e9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Feb 23, 2018 at 2:11 PM, JF Bastien <span dir=3D"l=
tr"><<a href=3D"mailto:jfbastien@apple.com" target=3D"_blank">jfbastien@=
apple.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D=
"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(=
204,204,204);padding-left:1ex"><div style=3D"word-wrap:break-word;line-brea=
k:after-white-space">Hi Arthur,<div><br></div><div>I=E2=80=99ll be in JAX a=
nd will definitely champion my own approach, but will make sure any other a=
pproaches are discussed thoroughly. I=E2=80=99ll then ask for direction pol=
ls from EWG, and will follow the proposed direction in an updated paper.</d=
iv></div></blockquote><div><br></div><div>And if you manage to write the up=
dated paper overnight and have it back on the table the next day at JAX, th=
en my paper <i>will</i> be utterly superfluous. :)</div><div><br></div><div=
>I am, however, worried that the writing of a new paper might slip more tha=
n a day, which would end up with you coming back in the pre-Rapperswil mail=
ing with another two's-complement paper after the perception that your =
first two's-complement paper was "rejected" in Jacksonville, =
which would set a perceived negative precedent in people's minds.</div>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:break-word;line-b=
reak:after-white-space"><div>I=E2=80=99d therefore appreciate it if you ins=
tead had rationales for why you=E2=80=99d take a different approach. I offe=
red my rationale for going the direction I suggest, and the right thing to =
change people=E2=80=99s minds is to offer compelling arguments to go in ano=
ther direction. Ideally you=E2=80=99d have data to back up any performance =
/ bug finding / odd architecture claims. Do you think you have time to get =
this together before JAX? That=E2=80=99s definitely something I=E2=80=99d p=
resent along my paper, though I might disagree.</div></div></blockquote><di=
v><br></div><div>I agree that rationales are good things, and I don't w=
ant to go too "tu quoque" here, but... <i>does</i> your paper inc=
lude any rationale?=C2=A0 The closest thing I see is in the "Introduct=
ion", where my version strikes out these two bullets from your version=
:</div><div><ul style=3D"margin-left:0px;padding-left:2em;color:rgb(0,0,0);=
font-family:sans-serif"><li style=3D"margin:0.25em 0px 0.5em;padding:0px"><=
p style=3D"margin:0px">Associativity and commutativity of integers is needl=
essly obtuse.</p></li><li style=3D"margin:0.25em 0px 0.5em;padding:0px"><p =
style=3D"margin:0px">Na=C3=AFve overflow checks, which are often security-c=
ritical, often get eliminated by compilers. This leads to exploitable code =
when the intent was clearly not to and the code, while na=C3=AFve, was corr=
ectly performing security checks for two=E2=80=99s complement integers. Cor=
rect overflow checks are difficult to write and equally difficult to read, =
exponentially so in generic code.</p></li></ul></div><div>These are true, b=
ut then the current undefined behavior on signed overflow has some unmentio=
ned good effects, too:</div><div><br></div><div>- Unintentional unsigned wr=
aparound (for example, in the argument to `malloc`) has been a known source=
of bugs for a long time. See for example <a href=3D"https://www.cs.utah.ed=
u/~regehr/papers/overflow12.pdf">[Regehr2012]</a>, whose final sentence is,=
"Our results also imply that tools for detecting integer numerical er=
rors need to <b><i>distinguish intentional from unintentional uses of wrapa=
round operations</i></b> =E2=80=94 a challenging task =E2=80=94 in order to=
minimize false alarms. [emphasis added]" =C2=A0The current undefinedn=
ess of signed overflow permits implementations, such as UBSan, to detect al=
l signed wraparound behavior as unintentional by definition, and diagnose i=
t accordingly.<br></div><div><br></div><div>- The impossibility of signed w=
raparound allows optimization of tight inner loops such as</div><div>=C2=A0=
=C2=A0 for (int i =3D a; i !=3D b; ++i)</div><div>Here the compiler is all=
owed to assume that `a <=3D b`, because if `b < a` the loop would eve=
ntually overflow and invoke undefined behavior. This is intuitively the sam=
e behavior that we have with C++ iterators: the compiler is allowed to assu=
me that the existence of a loop over the range `a` to `b` implies that `b` =
is actually reachable from `a` according to forward-increment semantics, ev=
en though in practice many implementations' std::list::iterator interna=
lly performs the equivalent of "wrap on overflow." (See the graph=
ical diagram of "sentinel-node containers" in <a href=3D"http://w=
ww.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0773r0.html#B">P0773</a> i=
f needed.)</div><div>John McFarlane did a lightning talk about integer UB a=
nd codegen within the past year but I don't know if the slides are some=
where. I can ask him.</div><div><br></div><div>I mean, it's not like th=
ere's any shortage of educational material on UB in C and C++ and its <=
b><i>good and</i></b> bad effects.</div><div>What there <i>is</i> a shortag=
e of IMHO is material on <i><b>ones'-complement</b></i> in C and C++. T=
hat's why I kept large swaths of your paper intact in my fork. :)</div>=
<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border=
-left-color:rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:brea=
k-word;line-break:after-white-space"><div></div><div>In the end I simply wa=
nt two=E2=80=99s complement, and I see a few ways that this play out with e=
veryone liking the outcome. I just ask that opposition comes with rationale=
s, not =E2=80=9CI like my way better=E2=80=9D. :-)</div></div></blockquote>=
<div><br></div><div>Yes; just remember that the rationale for making <i>no =
change at all</i> is invariably really strong.</div><div>And getting the ca=
mel's nose into the tent in 2018 does not preclude getting the rest of =
the camel at some point!=C2=A0 I just want to make as sure as possible that=
we can get the nose in. Because even the nose=C2=A0will be useful. (The &q=
uot;nose" includes arithmetic right-shift, for example. And well-defin=
ed casts from int16_t to int8_t. These are very useful features to get into=
C++ even if the rest of the camel remains outside forever!)</div><div><br>=
</div><div>=E2=80=93Arthur</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2Bkq5hFWG6UqZyLFOEsPNunLM4zVr=
n0ym6s05Cf6QGJxw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2Bkq5hF=
WG6UqZyLFOEsPNunLM4zVrn0ym6s05Cf6QGJxw%40mail.gmail.com</a>.<br />
--001a114011e273b4eb0565e8f1e9--
.
Author: JF Bastien <jfbastien@apple.com>
Date: Fri, 23 Feb 2018 15:07:18 -0800
Raw View
--Boundary_(ID_8Vp2OHJCdn20nr+Vntq8CA)
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
> On Feb 23, 2018, at 14:47, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wro=
te:
>=20
> On Fri, Feb 23, 2018 at 2:11 PM, JF Bastien <jfbastien@apple.com <mailto:=
jfbastien@apple.com>> wrote:
> Hi Arthur,
>=20
> I=E2=80=99ll be in JAX and will definitely champion my own approach, but =
will make sure any other approaches are discussed thoroughly. I=E2=80=99ll =
then ask for direction polls from EWG, and will follow the proposed directi=
on in an updated paper.
>=20
> And if you manage to write the updated paper overnight and have it back o=
n the table the next day at JAX, then my paper will be utterly superfluous.=
:)
>=20
> I am, however, worried that the writing of a new paper might slip more th=
an a day, which would end up with you coming back in the pre-Rapperswil mai=
ling with another two's-complement paper after the perception that your fir=
st two's-complement paper was "rejected" in Jacksonville, which would set a=
perceived negative precedent in people's minds.
I=E2=80=99ve frequently presented updated papers after obtaining feedback: =
evenings are for paper writing.
> I=E2=80=99d therefore appreciate it if you instead had rationales for why=
you=E2=80=99d take a different approach. I offered my rationale for going =
the direction I suggest, and the right thing to change people=E2=80=99s min=
ds is to offer compelling arguments to go in another direction. Ideally you=
=E2=80=99d have data to back up any performance / bug finding / odd archite=
cture claims. Do you think you have time to get this together before JAX? T=
hat=E2=80=99s definitely something I=E2=80=99d present along my paper, thou=
gh I might disagree.
>=20
> I agree that rationales are good things, and I don't want to go too "tu q=
uoque" here, but... does your paper include any rationale? The closest thi=
ng I see is in the "Introduction", where my version strikes out these two b=
ullets from your version:
> Associativity and commutativity of integers is needlessly obtuse.
> Na=C3=AFve overflow checks, which are often security-critical, often get =
eliminated by compilers. This leads to exploitable code when the intent was=
clearly not to and the code, while na=C3=AFve, was correctly performing se=
curity checks for two=E2=80=99s complement integers. Correct overflow check=
s are difficult to write and equally difficult to read, exponentially so in=
generic code.
I can indeed improve the rationale. The security aspect is a huge upside fo=
r me, having fixed so much =E2=80=9Cwrong=E2=80=9D code of that form. One I=
should add is one of the two pillars of C++ from p0939r0 "A direct map to =
hardware (initially from C)=E2=80=9D. It doesn=E2=80=99t come out of the pa=
per as much as I want, even though it=E2=80=99s what initially motivated me=
writing it.
> These are true, but then the current undefined behavior on signed overflo=
w has some unmentioned good effects, too:
>=20
> - Unintentional unsigned wraparound (for example, in the argument to `mal=
loc`) has been a known source of bugs for a long time. See for example [Reg=
ehr2012] <https://www.cs.utah.edu/~regehr/papers/overflow12.pdf>, whose fin=
al sentence is, "Our results also imply that tools for detecting integer nu=
merical errors need to distinguish intentional from unintentional uses of w=
raparound operations =E2=80=94 a challenging task =E2=80=94 in order to min=
imize false alarms. [emphasis added]" The current undefinedness of signed =
overflow permits implementations, such as UBSan, to detect all signed wrapa=
round behavior as unintentional by definition, and diagnose it accordingly.
unsigned wraparound isn=E2=80=99t UB, and I claim that signed overflow is U=
B because of the 3 representation, not to catch bugs, otherwise unsigned ov=
erflow would also have been UB.
FWIW UBSan supports unsigned overflow detection:
-fsanitize=3Dunsigned-integer-overflow: Unsigned integer overflows. Note th=
at unlike signed integer overflow, unsigned integer is not undefined behavi=
or. However, while it has well-defined semantics, it is often unintentional=
, so UBSan offers to catch it.
> - The impossibility of signed wraparound allows optimization of tight inn=
er loops such as
> for (int i =3D a; i !=3D b; ++i)
> Here the compiler is allowed to assume that `a <=3D b`, because if `b < a=
` the loop would eventually overflow and invoke undefined behavior.
I claim that this is also an emergent feature, not by design, caused by the=
3 signed integer representations. I also claim that much of this performan=
ce can be regained with a better optimizer (the compiler I work on certainl=
y optimizes loops substantially without assuming UB on overflow). Further, =
the Internet shows that this optimization isn=E2=80=99t something developer=
s knowingly opt into, and when they hit it they are surprised by the bugs i=
t generates.
> This is intuitively the same behavior that we have with C++ iterators: th=
e compiler is allowed to assume that the existence of a loop over the range=
`a` to `b` implies that `b` is actually reachable from `a` according to fo=
rward-increment semantics, even though in practice many implementations' st=
d::list::iterator internally performs the equivalent of "wrap on overflow."=
(See the graphical diagram of "sentinel-node containers" in P0773 <http://=
www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0773r0.html#B> if needed.=
)
> John McFarlane did a lightning talk about integer UB and codegen within t=
he past year but I don't know if the slides are somewhere. I can ask him.
The intuition is reversed, though: C came before C++ and iterators. Iterato=
rs are closer to pointers than integers, and I=E2=80=99m not removing point=
er overflow UB. Put another way: pointers are supposed to be disjoint sets =
of objects=E2=80=94even in a Harvard-style architecture=E2=80=94and travers=
ing from one to another is as nonsensical as overflowing the pointer, where=
as numbers are in a 2-dimensional line. Whether you=E2=80=99re a flat-line =
believer or you believe the line is circular is really what we=E2=80=99re d=
iscussing. Where you fall in that belief system decides whether going off t=
he end of the number line takes to to Undefined Land, or back to the other =
side of the line. For floating-point I definitely believe in the flat-line =
hypothesis, where going off the end takes us to infinite-land. For signed i=
ntegers I believe the number line is circular, just as it is for unsigned i=
ntegers, no traps, no saturation, no UB.
> I mean, it's not like there's any shortage of educational material on UB =
in C and C++ and its good and bad effects.
Sure, do you believe there are particular references that should be read wi=
th my proposal?
> What there is a shortage of IMHO is material on ones'-complement in C and=
C++. That's why I kept large swaths of your paper intact in my fork. :)
Might the lack of such documentation be caused by a lack of ones=E2=80=99 c=
omplement hardware using modern C++?
> In the end I simply want two=E2=80=99s complement, and I see a few ways t=
hat this play out with everyone liking the outcome. I just ask that opposit=
ion comes with rationales, not =E2=80=9CI like my way better=E2=80=9D. :-)
>=20
> Yes; just remember that the rationale for making no change at all is inva=
riably really strong.
> And getting the camel's nose into the tent in 2018 does not preclude gett=
ing the rest of the camel at some point! I just want to make as sure as po=
ssible that we can get the nose in. Because even the nose will be useful. (=
The "nose" includes arithmetic right-shift, for example. And well-defined c=
asts from int16_t to int8_t. These are very useful features to get into C++=
even if the rest of the camel remains outside forever!)
>=20
> =E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/8467483E-0F95-43B3-B877-FD790A3597A1%40apple.com=
..
--Boundary_(ID_8Vp2OHJCdn20nr+Vntq8CA)
Content-type: text/html; charset="UTF-8"
Content-transfer-encoding: quoted-printable
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; line-break: after-white-space;" class=3D""><br class=3D""><div><br cl=
ass=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Feb 23, 20=
18, at 14:47, Arthur O'Dwyer <<a href=3D"mailto:arthur.j.odwyer@gmail.co=
m" class=3D"">arthur.j.odwyer@gmail.com</a>> wrote:</div><br class=3D"Ap=
ple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">On Fri=
, Feb 23, 2018 at 2:11 PM, JF Bastien <span dir=3D"ltr" class=3D""><<a h=
ref=3D"mailto:jfbastien@apple.com" target=3D"_blank" class=3D"">jfbastien@a=
pple.com</a>></span> wrote:<br class=3D""><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-=
color:rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:break-word=
;line-break:after-white-space" class=3D"">Hi Arthur,<div class=3D""><br cla=
ss=3D""></div><div class=3D"">I=E2=80=99ll be in JAX and will definitely ch=
ampion my own approach, but will make sure any other approaches are discuss=
ed thoroughly. I=E2=80=99ll then ask for direction polls from EWG, and will=
follow the proposed direction in an updated paper.</div></div></blockquote=
><div class=3D""><br class=3D""></div><div class=3D"">And if you manage to =
write the updated paper overnight and have it back on the table the next da=
y at JAX, then my paper <i class=3D"">will</i> be utterly superfluous. :)</=
div><div class=3D""><br class=3D""></div><div class=3D"">I am, however, wor=
ried that the writing of a new paper might slip more than a day, which woul=
d end up with you coming back in the pre-Rapperswil mailing with another tw=
o's-complement paper after the perception that your first two's-complement =
paper was "rejected" in Jacksonville, which would set a perceived negative =
precedent in people's minds.</div></div></div></div></div></blockquote><div=
><br class=3D""></div><div>I=E2=80=99ve frequently presented updated papers=
after obtaining feedback: evenings are for paper writing.</div><div><br cl=
ass=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D""><div cla=
ss=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:break-word;line-b=
reak:after-white-space" class=3D""><div class=3D"">I=E2=80=99d therefore ap=
preciate it if you instead had rationales for why you=E2=80=99d take a diff=
erent approach. I offered my rationale for going the direction I suggest, a=
nd the right thing to change people=E2=80=99s minds is to offer compelling =
arguments to go in another direction. Ideally you=E2=80=99d have data to ba=
ck up any performance / bug finding / odd architecture claims. Do you think=
you have time to get this together before JAX? That=E2=80=99s definitely s=
omething I=E2=80=99d present along my paper, though I might disagree.</div>=
</div></blockquote><div class=3D""><br class=3D""></div><div class=3D"">I a=
gree that rationales are good things, and I don't want to go too "tu quoque=
" here, but... <i class=3D"">does</i> your paper include any rationale?&nbs=
p; The closest thing I see is in the "Introduction", where my version strik=
es out these two bullets from your version:</div><div class=3D""><ul style=
=3D"margin-left: 0px; padding-left: 2em; font-family: sans-serif;" class=3D=
""><li style=3D"margin:0.25em 0px 0.5em;padding:0px" class=3D""><div style=
=3D"margin: 0px;" class=3D"">Associativity and commutativity of integers is=
needlessly obtuse.</div></li><li style=3D"margin:0.25em 0px 0.5em;padding:=
0px" class=3D""><div style=3D"margin: 0px;" class=3D"">Na=C3=AFve overflow =
checks, which are often security-critical, often get eliminated by compiler=
s. This leads to exploitable code when the intent was clearly not to and th=
e code, while na=C3=AFve, was correctly performing security checks for two=
=E2=80=99s complement integers. Correct overflow checks are difficult to wr=
ite and equally difficult to read, exponentially so in generic code.</div><=
/li></ul></div></div></div></div></div></blockquote><div><br class=3D""></d=
iv><div>I can indeed improve the rationale. The security aspect is a huge u=
pside for me, having fixed so much =E2=80=9Cwrong=E2=80=9D code of that for=
m. One I should add is one of the two pillars of C++ from p0939r0 "A direct=
map to hardware (initially from C)=E2=80=9D. It doesn=E2=80=99t come out o=
f the paper as much as I want, even though it=E2=80=99s what initially moti=
vated me writing it.</div><br class=3D""><blockquote type=3D"cite" class=3D=
""><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><div class=3D"">These are true, but then the curr=
ent undefined behavior on signed overflow has some unmentioned good effects=
, too:</div><div class=3D""><br class=3D""></div><div class=3D"">- Unintent=
ional unsigned wraparound (for example, in the argument to `malloc`) has be=
en a known source of bugs for a long time. See for example <a href=3D"https=
://www.cs.utah.edu/~regehr/papers/overflow12.pdf" class=3D"">[Regehr2012]</=
a>, whose final sentence is, "Our results also imply that tools for detecti=
ng integer numerical errors need to <b class=3D""><i class=3D"">distinguish=
intentional from unintentional uses of wraparound operations</i></b> =E2=
=80=94 a challenging task =E2=80=94 in order to minimize false alarms. [emp=
hasis added]" The current undefinedness of signed overflow permits im=
plementations, such as UBSan, to detect all signed wraparound behavior as u=
nintentional by definition, and diagnose it accordingly.</div></div></div><=
/div></div></blockquote><div><br class=3D""></div><div>unsigned wraparound =
isn=E2=80=99t UB, and I claim that signed overflow is UB because of the 3 r=
epresentation, not to catch bugs, otherwise unsigned overflow would also ha=
ve been UB.</div><div><br class=3D""></div><div>FWIW UBSan supports unsigne=
d overflow detection:</div></div><blockquote style=3D"margin: 0 0 0 40px; b=
order: none; padding: 0px;" class=3D""><div><div><div class=3D"">-fsanitize=
=3Dunsigned-integer-overflow: Unsigned integer overflows. Note that unlike =
signed integer overflow, unsigned integer is not undefined behavior. Howeve=
r, while it has well-defined semantics, it is often unintentional, so =
UBSan offers to catch it.</div></div></div></blockquote><div><br class=3D""=
><blockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" clas=
s=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"=
">- The impossibility of signed wraparound allows optimization of tight inn=
er loops such as</div><div class=3D""> for (int i =3D a; i !=
=3D b; ++i)</div><div class=3D"">Here the compiler is allowed to assume tha=
t `a <=3D b`, because if `b < a` the loop would eventually overflow a=
nd invoke undefined behavior.</div></div></div></div></div></blockquote><di=
v><br class=3D""></div><div>I claim that this is also an emergent feature, =
not by design, caused by the 3 signed integer representations. I also claim=
that much of this performance can be regained with a better optimizer (the=
compiler I work on certainly optimizes loops substantially without assumin=
g UB on overflow). Further, the Internet shows that this optimization isn=
=E2=80=99t something developers knowingly opt into, and when they hit it th=
ey are surprised by the bugs it generates.</div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"">This is int=
uitively the same behavior that we have with C++ iterators: the compiler is=
allowed to assume that the existence of a loop over the range `a` to `b` i=
mplies that `b` is actually reachable from `a` according to forward-increme=
nt semantics, even though in practice many implementations' std::list::iter=
ator internally performs the equivalent of "wrap on overflow." (See the gra=
phical diagram of "sentinel-node containers" in <a href=3D"http://www.open-=
std.org/jtc1/sc22/wg21/docs/papers/2017/p0773r0.html#B" class=3D"">P0773</a=
> if needed.)</div><div class=3D"">John McFarlane did a lightning talk abou=
t integer UB and codegen within the past year but I don't know if the slide=
s are somewhere. I can ask him.</div></div></div></div></div></blockquote><=
div><br class=3D""></div><div>The intuition is reversed, though: C came bef=
ore C++ and iterators. Iterators are closer to pointers than integers, and =
I=E2=80=99m not removing pointer overflow UB. Put another way: pointers are=
supposed to be disjoint sets of objects=E2=80=94even in a Harvard-style ar=
chitecture=E2=80=94and traversing from one to another is as nonsensical as =
overflowing the pointer, whereas numbers are in a 2-dimensional line. Wheth=
er you=E2=80=99re a flat-line believer or you believe the line is circular =
is really what we=E2=80=99re discussing. Where you fall in that belief syst=
em decides whether going off the end of the number line takes to to Undefin=
ed Land, or back to the other side of the line. For floating-point I defini=
tely believe in the flat-line hypothesis, where going off the end takes us =
to infinite-land. For signed integers I believe the number line is circular=
, just as it is for unsigned integers, no traps, no saturation, no UB.</div=
><br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div d=
ir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><div class=3D"">I mean, it's not like there's any shortage of educational =
material on UB in C and C++ and its <b class=3D""><i class=3D"">good and</i=
></b> bad effects.</div></div></div></div></div></blockquote><div><br class=
=3D""></div><div>Sure, do you believe there are particular references that =
should be read with my proposal?</div><br class=3D""><blockquote type=3D"ci=
te" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><div class=3D"">What there <i class=
=3D"">is</i> a shortage of IMHO is material on <i class=3D""><b class=3D"">=
ones'-complement</b></i> in C and C++. That's why I kept large swaths of yo=
ur paper intact in my fork. :)</div></div></div></div></div></blockquote><d=
iv><br class=3D""></div><div>Might the lack of such documentation be caused=
by a lack of ones=E2=80=99 complement hardware using modern C++?</div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D=
"ltr" class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);paddi=
ng-left:1ex"><div style=3D"word-wrap:break-word;line-break:after-white-spac=
e" class=3D""><div class=3D""></div><div class=3D"">In the end I simply wan=
t two=E2=80=99s complement, and I see a few ways that this play out with ev=
eryone liking the outcome. I just ask that opposition comes with rationales=
, not =E2=80=9CI like my way better=E2=80=9D. :-)</div></div></blockquote><=
div class=3D""><br class=3D""></div><div class=3D"">Yes; just remember that=
the rationale for making <i class=3D"">no change at all</i> is invariably =
really strong.</div><div class=3D"">And getting the camel's nose into the t=
ent in 2018 does not preclude getting the rest of the camel at some point!&=
nbsp; I just want to make as sure as possible that we can get the nose in. =
Because even the nose will be useful. (The "nose" includes arithmetic =
right-shift, for example. And well-defined casts from int16_t to int8_t. Th=
ese are very useful features to get into C++ even if the rest of the camel =
remains outside forever!)</div><div class=3D""><br class=3D""></div><div cl=
ass=3D"">=E2=80=93Arthur</div></div></div></div>
</div></blockquote></div><br class=3D""></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8467483E-0F95-43B3-B877-FD790A3597A1%=
40apple.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8467483E-0F95-43B3-B877-FD790A3597A1%=
40apple.com</a>.<br />
--Boundary_(ID_8Vp2OHJCdn20nr+Vntq8CA)--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Fri, 23 Feb 2018 16:34:02 -0800
Raw View
--001a114edde41183d20565ea6f7d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Fri, Feb 23, 2018 at 3:07 PM, JF Bastien <jfbastien@apple.com> wrote:
> On Feb 23, 2018, at 14:47, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
> wrote:
>
> On Fri, Feb 23, 2018 at 2:11 PM, JF Bastien <jfbastien@apple.com> wrote:
>
>> Hi Arthur,
>>
>> I=E2=80=99ll be in JAX and will definitely champion my own approach, but=
will
>> make sure any other approaches are discussed thoroughly. I=E2=80=99ll th=
en ask for
>> direction polls from EWG, and will follow the proposed direction in an
>> updated paper.
>>
>
> And if you manage to write the updated paper overnight and have it back o=
n
> the table the next day at JAX, then my paper *will* be utterly
> superfluous. :)
>
> I am, however, worried that the writing of a new paper might slip more
> than a day, which would end up with you coming back in the pre-Rapperswil
> mailing with another two's-complement paper after the perception that you=
r
> first two's-complement paper was "rejected" in Jacksonville, which would
> set a perceived negative precedent in people's minds.
>
> I=E2=80=99ve frequently presented updated papers after obtaining feedback=
:
> evenings are for paper writing.
>
And if you manage to write the updated paper overnight and have it back on
the table the next day at JAX, then my paper will be utterly superfluous. :=
)
These are true, but then the current undefined behavior on signed overflow
> has some unmentioned good effects, too:
>
> - Unintentional unsigned wraparound (for example, in the argument to
> `malloc`) has been a known source of bugs for a long time. See for exampl=
e
> [Regehr2012] <https://www.cs.utah.edu/~regehr/papers/overflow12.pdf>,
> whose final sentence is, "Our results also imply that tools for detecting
> integer numerical errors need to *distinguish intentional from
> unintentional uses of wraparound operations* =E2=80=94 a challenging task=
=E2=80=94 in
> order to minimize false alarms. [emphasis added]" The current
> undefinedness of signed overflow permits implementations, such as UBSan, =
to
> detect all signed wraparound behavior as unintentional by definition, and
> diagnose it accordingly.
>
>
> unsigned wraparound isn=E2=80=99t UB, and I claim that signed overflow is=
UB
> because of the 3 representation, not to catch bugs, otherwise unsigned
> overflow would also have been UB. [...] I claim that this is also an
> emergent feature, not by design, caused by the 3 signed integer
> representations.
>
I think you are right in the historical sense. These days the emergent
"catch bugs" rationale has survived, though, even as the exotic hardwares
have died out.
FWIW UBSan supports unsigned overflow detection:
>
> -fsanitize=3Dunsigned-integer-overflow: Unsigned integer overflows. Note
> that unlike signed integer overflow, unsigned integer is not undefined
> behavior. However, while it has well-defined semantics, it is often
> unintentional, so UBSan offers to catch it.
>
>
This is very cool; I was unaware of this.
Your paper would benefit from mentioning this. But the obvious comeback is:
where's the numbers on how many false positives UBSan generates in this
mode? That number cannot possibly be zero.
> - The impossibility of signed wraparound allows optimization of tight
> inner loops such as
> for (int i =3D a; i !=3D b; ++i)
> Here the compiler is allowed to assume that `a <=3D b`, because if `b < a=
`
> the loop would eventually overflow and invoke undefined behavior.
>
> I claim that this is also an emergent feature, not by design, caused by
> the 3 signed integer representations. I also claim that much of this
> performance can be regained with a better optimizer (the compiler I work =
on
> certainly optimizes loops substantially without assuming UB on overflow).
> Further, the Internet shows that this optimization isn=E2=80=99t somethin=
g
> developers knowingly opt into, and when they hit it they are surprised by
> the bugs it generates.
>
Users never opt into bugs by definition. But users notice performance
regressions (in the *compiler*) almost as quickly as they notice
correctness regressions (in *their own code*).
This is intuitively the same behavior that we have with C++ iterators: the
> compiler is allowed to assume that the existence of a loop over the range
> `a` to `b` implies that `b` is actually reachable from `a` according to
> forward-increment semantics, even though in practice many implementations=
'
> std::list::iterator internally performs the equivalent of "wrap on
> overflow." (See the graphical diagram of "sentinel-node containers" in
> P0773
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0773r0.html#B>
> if needed.)
> John McFarlane did a lightning talk about integer UB and codegen within
> the past year but I don't know if the slides are somewhere. I can ask him=
..
>
> The intuition is reversed, though: C came before C++ and iterators.
>
Again, historically accurate but this is not modern C++'s problem. We don't
teach C before C++. (And if we did, we might soon have to explain that
integer overflow is undefined in C but not in C++? Add "C source-level
compatibility" to the list of rationales for preserving C's undefined
overflow behavior in C++.)
I mean, it's not like there's any shortage of educational material on UB in
> C and C++ and its *good and* bad effects.
>
>
> Sure, do you believe there are particular references that should be read
> with my proposal?
>
Off the top of my head, I recall John McFarlane's lightning talk on
codegen, Michael Spencer's "My Little Optimizer: Undefined Behavior Is
Magic" talk, and pretty much anything involving John Regehr. I found the
link to Regehr2012 as one of the top Google hits for "unintentional
unsigned overflow".
> What there *is* a shortage of IMHO is material on *ones'-complement* in C
> and C++. That's why I kept large swaths of your paper intact in my fork. =
:)
>
> Might the lack of such documentation be caused by a lack of ones=E2=80=99
> complement hardware using modern C++?
>
Yes, that's what I intended to imply here. :)
Nobody teaches about the interaction of ones'-complement or sign-magnitude
with code-generators anymore because these don't happen in practice.
People do teach about the interaction of undefined integer overflow with
code-generators because this *does* happen in practice.
Removing ones'-complement from C++ will be as painless (or painful) as
removing trigraphs was.
Removing integer overflow from C++ will be as painful (or painless) as
removing type-based alias analysis would be.
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0L%2BBDk3TMYX6znEe0RMbEPZfYGzEWDLjOXLB60Ey=
R5R6g%40mail.gmail.com.
--001a114edde41183d20565ea6f7d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Feb 23, 2018 at 3:07 PM, JF Bastien <span dir=3D"l=
tr"><<a href=3D"mailto:jfbastien@apple.com" target=3D"_blank">jfbastien@=
apple.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D=
"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(=
204,204,204);padding-left:1ex"><div style=3D"word-wrap:break-word;line-brea=
k:after-white-space">On Feb 23, 2018, at 14:47, Arthur O'Dwyer <<a h=
ref=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@=
gmail.com</a>> wrote:<div><span class=3D"gmail-"><blockquote type=3D"cit=
e"><div><div dir=3D"ltr">On Fri, Feb 23, 2018 at 2:11 PM, JF Bastien <span =
dir=3D"ltr"><<a href=3D"mailto:jfbastien@apple.com" target=3D"_blank">jf=
bastien@apple.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-co=
lor:rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:break-word;l=
ine-break:after-white-space">Hi Arthur,<div><br></div><div>I=E2=80=99ll be =
in JAX and will definitely champion my own approach, but will make sure any=
other approaches are discussed thoroughly. I=E2=80=99ll then ask for direc=
tion polls from EWG, and will follow the proposed direction in an updated p=
aper.</div></div></blockquote><div><br></div><div>And if you manage to writ=
e the updated paper overnight and have it back on the table the next day at=
JAX, then my paper <i>will</i> be utterly superfluous. :)</div><div><br></=
div><div>I am, however, worried that the writing of a new paper might slip =
more than a day, which would end up with you coming back in the pre-Rappers=
wil mailing with another two's-complement paper after the perception th=
at your first two's-complement paper was "rejected" in Jackso=
nville, which would set a perceived negative precedent in people's mind=
s.</div></div></div></div></div></blockquote><div>I=E2=80=99ve frequently p=
resented updated papers after obtaining feedback: evenings are for paper wr=
iting.<br></div></span></div></div></blockquote><br>And if you manage to wr=
ite the updated paper overnight and have it back on the table the next day =
at JAX, then my paper will be utterly superfluous. :)<br><br><br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-lef=
t:1ex"><div style=3D"word-wrap:break-word;line-break:after-white-space"><di=
v><span class=3D"gmail-"><blockquote type=3D"cite"><div><div dir=3D"ltr"><d=
iv class=3D"gmail_extra"><div class=3D"gmail_quote"><div>These are true, bu=
t then the current undefined behavior on signed overflow has some unmention=
ed good effects, too:</div><div><br></div><div>- Unintentional unsigned wra=
paround (for example, in the argument to `malloc`) has been a known source =
of bugs for a long time. See for example <a href=3D"https://www.cs.utah.edu=
/~regehr/papers/overflow12.pdf" target=3D"_blank">[Regehr2012]</a>, whose f=
inal sentence is, "Our results also imply that tools for detecting int=
eger numerical errors need to <b><i>distinguish intentional from unintentio=
nal uses of wraparound operations</i></b> =E2=80=94 a challenging task =E2=
=80=94 in order to minimize false alarms. [emphasis added]" =C2=A0The =
current undefinedness of signed overflow permits implementations, such as U=
BSan, to detect all signed wraparound behavior as unintentional by definiti=
on, and diagnose it accordingly.</div></div></div></div></div></blockquote>=
<div><br></div></span><div>unsigned wraparound isn=E2=80=99t UB, and I clai=
m that signed overflow is UB because of the 3 representation, not to catch =
bugs, otherwise unsigned overflow would also have been UB. [...] I claim th=
at this is also an emergent feature, not by design, caused by the 3 signed =
integer representations.</div></div></div></blockquote><div>=C2=A0</div><di=
v>I think you are right in the historical sense. These days the emergent &q=
uot;catch bugs" rationale has survived, though, even as the exotic har=
dwares have died out.</div><div><br></div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<div style=3D"word-wrap:break-word;line-break:after-white-space"><div><div>=
</div><div>FWIW UBSan supports unsigned overflow detection:</div></div><blo=
ckquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px"><div><div=
><div>-fsanitize=3Dunsigned-integer-<wbr>overflow: Unsigned integer overflo=
ws. Note that unlike signed integer overflow, unsigned integer is not undef=
ined behavior. However, while it has well-defined=C2=A0semantics, it is oft=
en unintentional, so UBSan offers to catch it.</div></div></div></blockquot=
e></div></blockquote><div><br></div><div>This is very cool; I was unaware o=
f this.</div><div>Your paper would benefit from mentioning this. But the ob=
vious comeback is: where's the numbers on how many false positives UBSa=
n generates in this mode? That number cannot possibly be zero.</div><div><b=
r></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left=
-color:rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:break-wor=
d;line-break:after-white-space"><div><span class=3D"gmail-"><blockquote typ=
e=3D"cite"><div><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><div>- The impossibility of signed wraparound allows optimizati=
on of tight inner loops such as</div><div>=C2=A0 =C2=A0 for (int i =3D a; i=
!=3D b; ++i)</div><div>Here the compiler is allowed to assume that `a <=
=3D b`, because if `b < a` the loop would eventually overflow and invoke=
undefined behavior.</div></div></div></div></div></blockquote></span><div>=
I claim that this is also an emergent feature, not by design, caused by the=
3 signed integer representations. I also claim that much of this performan=
ce can be regained with a better optimizer (the compiler I work on certainl=
y optimizes loops substantially without assuming UB on overflow). Further, =
the Internet shows that this optimization isn=E2=80=99t something developer=
s knowingly opt into, and when they hit it they are surprised by the bugs i=
t generates.</div></div></div></blockquote><div><br></div><div>Users never =
opt into bugs by definition. But users notice performance regressions (in t=
he <i>compiler</i>) almost as quickly as they notice correctness regression=
s (in <i>their own code</i>).</div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div sty=
le=3D"word-wrap:break-word;line-break:after-white-space"><div><span class=
=3D"gmail-"><blockquote type=3D"cite"><div><div dir=3D"ltr"><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><div>This is intuitively the same be=
havior that we have with C++ iterators: the compiler is allowed to assume t=
hat the existence of a loop over the range `a` to `b` implies that `b` is a=
ctually reachable from `a` according to forward-increment semantics, even t=
hough in practice many implementations' std::list::iterator internally =
performs the equivalent of "wrap on overflow." (See the graphical=
diagram of "sentinel-node containers" in <a href=3D"http://www.o=
pen-std.org/jtc1/sc22/wg21/docs/papers/2017/p0773r0.html#B" target=3D"_blan=
k">P0773</a> if needed.)</div><div>John McFarlane did a lightning talk abou=
t integer UB and codegen within the past year but I don't know if the s=
lides are somewhere. I can ask him.</div></div></div></div></div></blockquo=
te></span><div>The intuition is reversed, though: C came before C++ and ite=
rators.</div></div></div></blockquote><div><br></div><div>Again, historical=
ly accurate but this is not modern C++'s problem. We don't teach C =
before C++. (And if we did, we might soon have to explain that integer over=
flow is undefined in C but not in C++? Add "C source-level compatibili=
ty" to the list of rationales for preserving C's undefined overflo=
w behavior in C++.)</div><div><br></div><div><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><di=
v style=3D"word-wrap:break-word;line-break:after-white-space"><div><span cl=
ass=3D"gmail-"><blockquote type=3D"cite"><div><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>I mean, it's not like =
there's any shortage of educational material on UB in C and C++ and its=
<b><i>good and</i></b> bad effects.</div></div></div></div></div></blockqu=
ote><div><br></div></span><div>Sure, do you believe there are particular re=
ferences that should be read with my proposal?</div></div></div></blockquot=
e><div><br></div><div>Off the top of my head, I recall John McFarlane's=
lightning talk on codegen, Michael Spencer's "My Little Optimizer=
: Undefined Behavior Is Magic" talk, and pretty much anything involvin=
g John Regehr. I found the link to Regehr2012 as one of the top Google hits=
for "unintentional unsigned overflow".</div><div><br></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(20=
4,204,204);padding-left:1ex"><div style=3D"word-wrap:break-word;line-break:=
after-white-space"><div><span class=3D"gmail-"><blockquote type=3D"cite"><d=
iv><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
div>What there <i>is</i> a shortage of IMHO is material on <i><b>ones'-=
complement</b></i> in C and C++. That's why I kept large swaths of your=
paper intact in my fork. :)</div></div></div></div></div></blockquote><div=
>Might the lack of such documentation be caused by a lack of ones=E2=80=99 =
complement hardware using modern C++?<br></div></span></div></div></blockqu=
ote><div><br></div><div>Yes, that's what I intended to imply here. :)</=
div><div>Nobody teaches about the interaction of ones'-complement or si=
gn-magnitude with code-generators anymore because these don't happen in=
practice.</div><div>People do teach about the interaction of undefined int=
eger overflow with code-generators because this <i>does</i> happen in pract=
ice.</div><div><br></div><div>Removing ones'-complement from C++ will b=
e as painless (or painful) as removing trigraphs was.</div><div>Removing in=
teger overflow from C++ will be as painful (or painless) as removing type-b=
ased alias analysis would be.</div><div><br></div><div>=E2=80=93Arthur</div=
></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0L%2BBDk3TMYX6znEe0RMbEPZfYGzEW=
DLjOXLB60EyR5R6g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0L%2BBDk3=
TMYX6znEe0RMbEPZfYGzEWDLjOXLB60EyR5R6g%40mail.gmail.com</a>.<br />
--001a114edde41183d20565ea6f7d--
.
Author: John McFarlane <john@mcfarlane.name>
Date: Sat, 24 Feb 2018 02:37:48 +0000
Raw View
--94eb2c19206e3d4e0a0565ec2a4d
Content-Type: text/plain; charset="UTF-8"
On Fri, Feb 23, 2018 at 4:34 PM Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:
> I mean, it's not like there's any shortage of educational material on UB
>> in C and C++ and its *good and* bad effects.
>>
>>
>> Sure, do you believe there are particular references that should be read
>> with my proposal?
>>
>
> Off the top of my head, I recall John McFarlane's lightning talk on
> codegen, Michael Spencer's "My Little Optimizer: Undefined Behavior Is
> Magic" talk, and pretty much anything involving John Regehr. I found the
> link to Regehr2012 as one of the top Google hits for "unintentional
> unsigned overflow".
>
>
The lightning talk material can be found here:
https://github.com/johnmcfarlane/presentations/tree/master/2017-09-27_CppCon2017
In particular, Krister Walfridsson's blog post regarding GCC optimization
of signed integers gives some great examples which certainly hadn't
occurred to me:
https://kristerw.blogspot.com/2016/02/how-undefined-signed-overflow-enables.html
John
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnQ1cZjQaAXcvWiQW4_63V2-wbXFrMYUMRb5R%3D-sPtjM2A%40mail.gmail.com.
--94eb2c19206e3d4e0a0565ec2a4d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Feb 23=
, 2018 at 4:34 PM Arthur O'Dwyer <<a href=3D"mailto:arthur.j.odwyer@=
gmail.com">arthur.j.odwyer@gmail.com</a>> wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(2=
04,204,204);padding-left:1ex"><div style=3D"word-wrap:break-word;line-break=
:after-white-space"><div><span class=3D"m_2392412714106240386gmail-"><block=
quote type=3D"cite"><div><div dir=3D"ltr"><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><div>I mean, it's not like there's any shortag=
e of educational material on UB in C and C++ and its <b><i>good and</i></b>=
bad effects.</div></div></div></div></div></blockquote><div><br></div></sp=
an><div>Sure, do you believe there are particular references that should be=
read with my proposal?</div></div></div></blockquote><div><br></div></div>=
</div></div><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail=
_quote"><div>Off the top of my head, I recall John McFarlane's lightnin=
g talk on codegen, Michael Spencer's "My Little Optimizer: Undefin=
ed Behavior Is Magic" talk, and pretty much anything involving John Re=
gehr. I found the link to Regehr2012 as one of the top Google hits for &quo=
t;unintentional unsigned overflow".</div></div></div></div><div dir=3D=
"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></div>=
</div></div></div></blockquote><div><br>The lightning talk material can be =
found here: <a href=3D"https://github.com/johnmcfarlane/presentations/tree/=
master/2017-09-27_CppCon2017">https://github.com/johnmcfarlane/presentation=
s/tree/master/2017-09-27_CppCon2017</a><br></div><div>In particular, Kriste=
r Walfridsson's blog post regarding GCC optimization of signed integers=
gives some great examples which certainly hadn't occurred to me:<br><a=
href=3D"https://kristerw.blogspot.com/2016/02/how-undefined-signed-overflo=
w-enables.html">https://kristerw.blogspot.com/2016/02/how-undefined-signed-=
overflow-enables.html</a><br></div></div><div class=3D"gmail_quote"><br></d=
iv><div class=3D"gmail_quote">John<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CABPJVnQ1cZjQaAXcvWiQW4_63V2-wbXFrMYU=
MRb5R%3D-sPtjM2A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnQ1cZjQaA=
XcvWiQW4_63V2-wbXFrMYUMRb5R%3D-sPtjM2A%40mail.gmail.com</a>.<br />
--94eb2c19206e3d4e0a0565ec2a4d--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Fri, 23 Feb 2018 22:51:12 -0800
Raw View
--f403043534ace6732a0565efb3ca
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On 23 Feb 2018 16:34, "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com> wrote:
On Fri, Feb 23, 2018 at 3:07 PM, JF Bastien <jfbastien@apple.com> wrote:
> On Feb 23, 2018, at 14:47, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
> wrote:
>
> On Fri, Feb 23, 2018 at 2:11 PM, JF Bastien <jfbastien@apple.com> wrote:
>
>> Hi Arthur,
>>
>> I=E2=80=99ll be in JAX and will definitely champion my own approach, but=
will
>> make sure any other approaches are discussed thoroughly. I=E2=80=99ll th=
en ask for
>> direction polls from EWG, and will follow the proposed direction in an
>> updated paper.
>>
>
> And if you manage to write the updated paper overnight and have it back o=
n
> the table the next day at JAX, then my paper *will* be utterly
> superfluous. :)
>
> I am, however, worried that the writing of a new paper might slip more
> than a day, which would end up with you coming back in the pre-Rapperswil
> mailing with another two's-complement paper after the perception that you=
r
> first two's-complement paper was "rejected" in Jacksonville, which would
> set a perceived negative precedent in people's minds.
>
> I=E2=80=99ve frequently presented updated papers after obtaining feedback=
:
> evenings are for paper writing.
>
And if you manage to write the updated paper overnight and have it back on
the table the next day at JAX, then my paper will be utterly superfluous. :=
)
These are true, but then the current undefined behavior on signed overflow
> has some unmentioned good effects, too:
>
> - Unintentional unsigned wraparound (for example, in the argument to
> `malloc`) has been a known source of bugs for a long time. See for exampl=
e
> [Regehr2012] <https://www.cs.utah.edu/~regehr/papers/overflow12.pdf>,
> whose final sentence is, "Our results also imply that tools for detecting
> integer numerical errors need to *distinguish intentional from
> unintentional uses of wraparound operations* =E2=80=94 a challenging task=
=E2=80=94 in
> order to minimize false alarms. [emphasis added]" The current
> undefinedness of signed overflow permits implementations, such as UBSan, =
to
> detect all signed wraparound behavior as unintentional by definition, and
> diagnose it accordingly.
>
>
> unsigned wraparound isn=E2=80=99t UB, and I claim that signed overflow is=
UB
> because of the 3 representation, not to catch bugs, otherwise unsigned
> overflow would also have been UB. [...] I claim that this is also an
> emergent feature, not by design, caused by the 3 signed integer
> representations.
>
I think you are right in the historical sense. These days the emergent
"catch bugs" rationale has survived, though, even as the exotic hardwares
have died out.
FWIW UBSan supports unsigned overflow detection:
>
> -fsanitize=3Dunsigned-integer-overflow: Unsigned integer overflows. Note
> that unlike signed integer overflow, unsigned integer is not undefined
> behavior. However, while it has well-defined semantics, it is often
> unintentional, so UBSan offers to catch it.
>
>
This is very cool; I was unaware of this.
Your paper would benefit from mentioning this. But the obvious comeback is:
where's the numbers on how many false positives UBSan generates in this
mode? That number cannot possibly be zero.
The false positive rate is empirically huge, and extremely painful because
there is no easy syntactic way to distinguish between true and false
positives.
- The impossibility of signed wraparound allows optimization of tight inner
> loops such as
> for (int i =3D a; i !=3D b; ++i)
> Here the compiler is allowed to assume that `a <=3D b`, because if `b < a=
`
> the loop would eventually overflow and invoke undefined behavior.
>
> I claim that this is also an emergent feature, not by design, caused by
> the 3 signed integer representations. I also claim that much of this
> performance can be regained with a better optimizer (the compiler I work =
on
> certainly optimizes loops substantially without assuming UB on overflow).
> Further, the Internet shows that this optimization isn=E2=80=99t somethin=
g
> developers knowingly opt into, and when they hit it they are surprised by
> the bugs it generates.
>
Users never opt into bugs by definition. But users notice performance
regressions (in the *compiler*) almost as quickly as they notice
correctness regressions (in *their own code*).
This is intuitively the same behavior that we have with C++ iterators: the
> compiler is allowed to assume that the existence of a loop over the range
> `a` to `b` implies that `b` is actually reachable from `a` according to
> forward-increment semantics, even though in practice many implementations=
'
> std::list::iterator internally performs the equivalent of "wrap on
> overflow." (See the graphical diagram of "sentinel-node containers" in
> P0773
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0773r0.html#B>
> if needed.)
> John McFarlane did a lightning talk about integer UB and codegen within
> the past year but I don't know if the slides are somewhere. I can ask him=
..
>
> The intuition is reversed, though: C came before C++ and iterators.
>
Again, historically accurate but this is not modern C++'s problem. We don't
teach C before C++. (And if we did, we might soon have to explain that
integer overflow is undefined in C but not in C++? Add "C source-level
compatibility" to the list of rationales for preserving C's undefined
overflow behavior in C++.)
I mean, it's not like there's any shortage of educational material on UB in
> C and C++ and its *good and* bad effects.
>
>
> Sure, do you believe there are particular references that should be read
> with my proposal?
>
Off the top of my head, I recall John McFarlane's lightning talk on
codegen, Michael Spencer's "My Little Optimizer: Undefined Behavior Is
Magic" talk, and pretty much anything involving John Regehr. I found the
link to Regehr2012 as one of the top Google hits for "unintentional
unsigned overflow".
> What there *is* a shortage of IMHO is material on *ones'-complement* in C
> and C++. That's why I kept large swaths of your paper intact in my fork. =
:)
>
> Might the lack of such documentation be caused by a lack of ones=E2=80=99
> complement hardware using modern C++?
>
Yes, that's what I intended to imply here. :)
Nobody teaches about the interaction of ones'-complement or sign-magnitude
with code-generators anymore because these don't happen in practice.
People do teach about the interaction of undefined integer overflow with
code-generators because this *does* happen in practice.
Removing ones'-complement from C++ will be as painless (or painful) as
removing trigraphs was.
Removing integer overflow from C++ will be as painful (or painless) as
removing type-based alias analysis would be.
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/
isocpp.org/d/msgid/std-proposals/CADvuK0L%2BBDk3TMYX6znEe0RMbEPZfYGzEWDL
jOXLB60EyR5R6g%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0L%2BBD=
k3TMYX6znEe0RMbEPZfYGzEWDLjOXLB60EyR5R6g%40mail.gmail.com?utm_medium=3Demai=
l&utm_source=3Dfooter>
..
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOfiQqmKqYn_r-9%3DaPpLsBrwnNO_VFh-tz_6CVMpGRhuO=
vAbsA%40mail.gmail.com.
--f403043534ace6732a0565efb3ca
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gma=
il_quote">On 23 Feb 2018 16:34, "Arthur O'Dwyer" <<a href=
=3D"mailto:arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com</a>> wro=
te:<br type=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"quoted-text">On Fri, Feb 23, 2018 at 3:07 PM, JF Bastien <span dir=
=3D"ltr"><<a href=3D"mailto:jfbastien@apple.com" target=3D"_blank">jfbas=
tien@apple.com</a>></span> wrote:<br></div><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><div class=3D"quoted-text"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div s=
tyle=3D"word-wrap:break-word;line-break:after-white-space">On Feb 23, 2018,=
at 14:47, Arthur O'Dwyer <<a href=3D"mailto:arthur.j.odwyer@gmail.c=
om" target=3D"_blank">arthur.j.odwyer@gmail.com</a>> wrote:<div><span cl=
ass=3D"m_-5722284926157665104gmail-"><blockquote type=3D"cite"><div><div di=
r=3D"ltr">On Fri, Feb 23, 2018 at 2:11 PM, JF Bastien <span dir=3D"ltr"><=
;<a href=3D"mailto:jfbastien@apple.com" target=3D"_blank">jfbastien@apple.c=
om</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_=
quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204=
,204);padding-left:1ex"><div style=3D"word-wrap:break-word;line-break:after=
-white-space">Hi Arthur,<div><br></div><div>I=E2=80=99ll be in JAX and will=
definitely champion my own approach, but will make sure any other approach=
es are discussed thoroughly. I=E2=80=99ll then ask for direction polls from=
EWG, and will follow the proposed direction in an updated paper.</div></di=
v></blockquote><div><br></div><div>And if you manage to write the updated p=
aper overnight and have it back on the table the next day at JAX, then my p=
aper <i>will</i> be utterly superfluous. :)</div><div><br></div><div>I am, =
however, worried that the writing of a new paper might slip more than a day=
, which would end up with you coming back in the pre-Rapperswil mailing wit=
h another two's-complement paper after the perception that your first t=
wo's-complement paper was "rejected" in Jacksonville, which w=
ould set a perceived negative precedent in people's minds.</div></div><=
/div></div></div></blockquote><div>I=E2=80=99ve frequently presented update=
d papers after obtaining feedback: evenings are for paper writing.<br></div=
></span></div></div></blockquote><br>And if you manage to write the updated=
paper overnight and have it back on the table the next day at JAX, then my=
paper will be utterly superfluous. :)<br><br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<div style=3D"word-wrap:break-word;line-break:after-white-space"><div><div =
class=3D"quoted-text"><span class=3D"m_-5722284926157665104gmail-"><blockqu=
ote type=3D"cite"><div><div dir=3D"ltr"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><div>These are true, but then the current undefined beha=
vior on signed overflow has some unmentioned good effects, too:</div><div><=
br></div><div>- Unintentional unsigned wraparound (for example, in the argu=
ment to `malloc`) has been a known source of bugs for a long time. See for =
example <a href=3D"https://www.cs.utah.edu/~regehr/papers/overflow12.pdf" t=
arget=3D"_blank">[Regehr2012]</a>, whose final sentence is, "Our resul=
ts also imply that tools for detecting integer numerical errors need to <b>=
<i>distinguish intentional from unintentional uses of wraparound operations=
</i></b> =E2=80=94 a challenging task =E2=80=94 in order to minimize false =
alarms. [emphasis added]" =C2=A0The current undefinedness of signed ov=
erflow permits implementations, such as UBSan, to detect all signed wraparo=
und behavior as unintentional by definition, and diagnose it accordingly.</=
div></div></div></div></div></blockquote><div><br></div></span></div><div>u=
nsigned wraparound isn=E2=80=99t UB, and I claim that signed overflow is UB=
because of the 3 representation, not to catch bugs, otherwise unsigned ove=
rflow would also have been UB. [...] I claim that this is also an emergent =
feature, not by design, caused by the 3 signed integer representations.</di=
v></div></div></blockquote><div>=C2=A0</div><div>I think you are right in t=
he historical sense. These days the emergent "catch bugs" rationa=
le has survived, though, even as the exotic hardwares have died out.</div><=
div class=3D"quoted-text"><div><br></div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
<div style=3D"word-wrap:break-word;line-break:after-white-space"><div><div>=
</div><div>FWIW UBSan supports unsigned overflow detection:</div></div><blo=
ckquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px"><div><div=
><div>-fsanitize=3Dunsigned-integer-ov<wbr>erflow: Unsigned integer overflo=
ws. Note that unlike signed integer overflow, unsigned integer is not undef=
ined behavior. However, while it has well-defined=C2=A0semantics, it is oft=
en unintentional, so UBSan offers to catch it.</div></div></div></blockquot=
e></div></blockquote><div><br></div></div><div>This is very cool; I was una=
ware of this.</div><div>Your paper would benefit from mentioning this. But =
the obvious comeback is: where's the numbers on how many false positive=
s UBSan generates in this mode? That number cannot possibly be zero.</div><=
/div></div></div></blockquote></div></div><div dir=3D"auto"><br></div><div =
dir=3D"auto">The false positive rate is empirically huge, and extremely pai=
nful because there is no easy syntactic way to distinguish between true and=
false positives.</div><div class=3D"gmail_extra" dir=3D"auto"><div class=
=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><div class=3D"quoted-text"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-lef=
t:1ex"><div style=3D"word-wrap:break-word;line-break:after-white-space"><di=
v><span class=3D"m_-5722284926157665104gmail-"><blockquote type=3D"cite"><d=
iv><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
div>- The impossibility of signed wraparound allows optimization of tight i=
nner loops such as</div><div>=C2=A0 =C2=A0 for (int i =3D a; i !=3D b; ++i)=
</div><div>Here the compiler is allowed to assume that `a <=3D b`, becau=
se if `b < a` the loop would eventually overflow and invoke undefined be=
havior.</div></div></div></div></div></blockquote></span><div>I claim that =
this is also an emergent feature, not by design, caused by the 3 signed int=
eger representations. I also claim that much of this performance can be reg=
ained with a better optimizer (the compiler I work on certainly optimizes l=
oops substantially without assuming UB on overflow). Further, the Internet =
shows that this optimization isn=E2=80=99t something developers knowingly o=
pt into, and when they hit it they are surprised by the bugs it generates.<=
/div></div></div></blockquote><div><br></div></div><div>Users never opt int=
o bugs by definition. But users notice performance regressions (in the <i>c=
ompiler</i>) almost as quickly as they notice correctness regressions (in <=
i>their own code</i>).</div><div class=3D"quoted-text"><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-=
width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);paddin=
g-left:1ex"><div style=3D"word-wrap:break-word;line-break:after-white-space=
"><div><span class=3D"m_-5722284926157665104gmail-"><blockquote type=3D"cit=
e"><div><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><div>This is intuitively the same behavior that we have with C++ iterat=
ors: the compiler is allowed to assume that the existence of a loop over th=
e range `a` to `b` implies that `b` is actually reachable from `a` accordin=
g to forward-increment semantics, even though in practice many implementati=
ons' std::list::iterator internally performs the equivalent of "wr=
ap on overflow." (See the graphical diagram of "sentinel-node con=
tainers" in <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2017/p0773r0.html#B" target=3D"_blank">P0773</a> if needed.)</div><div>=
John McFarlane did a lightning talk about integer UB and codegen within the=
past year but I don't know if the slides are somewhere. I can ask him.=
</div></div></div></div></div></blockquote></span><div>The intuition is rev=
ersed, though: C came before C++ and iterators.</div></div></div></blockquo=
te><div><br></div></div><div>Again, historically accurate but this is not m=
odern C++'s problem. We don't teach C before C++. (And if we did, w=
e might soon have to explain that integer overflow is undefined in C but no=
t in C++? Add "C source-level compatibility" to the list of ratio=
nales for preserving C's undefined overflow behavior in C++.)</div><div=
class=3D"quoted-text"><div><br></div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div =
style=3D"word-wrap:break-word;line-break:after-white-space"><div><span clas=
s=3D"m_-5722284926157665104gmail-"><blockquote type=3D"cite"><div><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>I mean,=
it's not like there's any shortage of educational material on UB i=
n C and C++ and its <b><i>good and</i></b> bad effects.</div></div></div></=
div></div></blockquote><div><br></div></span><div>Sure, do you believe ther=
e are particular references that should be read with my proposal?</div></di=
v></div></blockquote><div><br></div></div><div>Off the top of my head, I re=
call John McFarlane's lightning talk on codegen, Michael Spencer's =
"My Little Optimizer: Undefined Behavior Is Magic" talk, and pret=
ty much anything involving John Regehr. I found the link to Regehr2012 as o=
ne of the top Google hits for "unintentional unsigned overflow".<=
/div><div class=3D"quoted-text"><div><br></div><div>=C2=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:=
1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left=
:1ex"><div style=3D"word-wrap:break-word;line-break:after-white-space"><div=
><span class=3D"m_-5722284926157665104gmail-"><blockquote type=3D"cite"><di=
v><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><d=
iv>What there <i>is</i> a shortage of IMHO is material on <i><b>ones'-c=
omplement</b></i> in C and C++. That's why I kept large swaths of your =
paper intact in my fork. :)</div></div></div></div></div></blockquote><div>=
Might the lack of such documentation be caused by a lack of ones=E2=80=99 c=
omplement hardware using modern C++?<br></div></span></div></div></blockquo=
te><div><br></div></div><div>Yes, that's what I intended to imply here.=
:)</div><div>Nobody teaches about the interaction of ones'-complement =
or sign-magnitude with code-generators anymore because these don't happ=
en in practice.</div><div>People do teach about the interaction of undefine=
d integer overflow with code-generators because this <i>does</i> happen in =
practice.</div><div><br></div><div>Removing ones'-complement from C++ w=
ill be as painless (or painful) as removing trigraphs was.</div><div>Removi=
ng integer overflow from C++ will be as painful (or painless) as removing t=
ype-based alias analysis would be.</div><div><br></div><div>=E2=80=93Arthur=
</div></div></div></div><div class=3D"quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0L%2BBDk3TMYX6znEe0RMbEPZfYGzEW=
DLjOXLB60EyR5R6g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/st=
d-<wbr>proposals/CADvuK0L%<wbr>2BBDk3TMYX6znEe0RMbEPZfYGzEWDL<wbr>jOXLB60Ey=
R5R6g%40mail.gmail.<wbr>com</a>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqmKqYn_r-9%3DaPpLsBrwnNO_VFh-tz=
_6CVMpGRhuOvAbsA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqmKqYn_r-=
9%3DaPpLsBrwnNO_VFh-tz_6CVMpGRhuOvAbsA%40mail.gmail.com</a>.<br />
--f403043534ace6732a0565efb3ca--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Sat, 24 Feb 2018 11:05:38 +0100
Raw View
On Fri, Feb 23, 2018 at 10:51:12PM -0800, Richard Smith wrote:
> On 23 Feb 2018 16:34, "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com> wrote:
>
> On Fri, Feb 23, 2018 at 3:07 PM, JF Bastien <jfbastien@apple.com> wrote:
>
> > On Feb 23, 2018, at 14:47, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
> > wrote:
> >
> > On Fri, Feb 23, 2018 at 2:11 PM, JF Bastien <jfbastien@apple.com> wrote:
> >
>
> Yes, that's what I intended to imply here. :)
> Nobody teaches about the interaction of ones'-complement or sign-magnitude
> with code-generators anymore because these don't happen in practice.
> People do teach about the interaction of undefined integer overflow with
> code-generators because this *does* happen in practice.
>
> Removing ones'-complement from C++ will be as painless (or painful) as
> removing trigraphs was.
> Removing integer overflow from C++ will be as painful (or painless) as
> removing type-based alias analysis would be.
One thing I have been mulling over is if it would make sense to create
context-dependent keywords that allows the user to choose the behaviour
they want.
nonoverflowing unsigned int foo; // UB if overflow
wrapping int bar; // Wraps
I do not see these modifiers as beeing part of the types.
Under this scheme "unsigned int" would be equivalent to "wrapping unsigned
int" and "int" would be equivalent to "nonoverflowing int".
Obviously this bikeshed would need to be painted but that is for later.
Changing the equivalence of int might be reasonable but that is an unrelated
change just like killing one-complement.
/MF
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20180224100538.GA2770%40noemi.
.
Author: =?UTF-8?Q?Jonathan_M=c3=bcller?= <jonathanmueller.dev@gmail.com>
Date: Sat, 24 Feb 2018 17:08:36 +0100
Raw View
On 24.02.2018 11:05, Magnus Fromreide wrote:
> On Fri, Feb 23, 2018 at 10:51:12PM -0800, Richard Smith wrote:
>> On 23 Feb 2018 16:34, "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com> wrote:
>>
>> On Fri, Feb 23, 2018 at 3:07 PM, JF Bastien <jfbastien@apple.com> wrote:
>>
>>> On Feb 23, 2018, at 14:47, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
>>> wrote:
>>>
>>> On Fri, Feb 23, 2018 at 2:11 PM, JF Bastien <jfbastien@apple.com> wrote:
>>>
>>
>> Yes, that's what I intended to imply here. :)
>> Nobody teaches about the interaction of ones'-complement or sign-magnitude
>> with code-generators anymore because these don't happen in practice.
>> People do teach about the interaction of undefined integer overflow with
>> code-generators because this *does* happen in practice.
>>
>> Removing ones'-complement from C++ will be as painless (or painful) as
>> removing trigraphs was.
>> Removing integer overflow from C++ will be as painful (or painless) as
>> removing type-based alias analysis would be.
>
> One thing I have been mulling over is if it would make sense to create
> context-dependent keywords that allows the user to choose the behaviour
> they want.
>
> nonoverflowing unsigned int foo; // UB if overflow
> wrapping int bar; // Wraps
>
> I do not see these modifiers as beeing part of the types.
>
> Under this scheme "unsigned int" would be equivalent to "wrapping unsigned
> int" and "int" would be equivalent to "nonoverflowing int".
>
> Obviously this bikeshed would need to be painted but that is for later.
>
> Changing the equivalence of int might be reasonable but that is an unrelated
> change just like killing one-complement.
>
> /MF
>
Why make it keywords though?
It is easy to have a `std::nonoverflowing_unsigned` and
`std::wrapping_int` if we chose to go that route.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7336dd9a-50af-b7d9-7837-f304cb643c24%40gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 24 Feb 2018 08:47:06 -0800 (PST)
Raw View
------=_Part_7720_2023908164.1519490826121
Content-Type: multipart/alternative;
boundary="----=_Part_7721_167936028.1519490826121"
------=_Part_7721_167936028.1519490826121
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Saturday, February 24, 2018 at 11:08:43 AM UTC-5, Jonathan M=C3=BCller w=
rote:
>
> On 24.02.2018 11:05, Magnus Fromreide wrote:=20
> > On Fri, Feb 23, 2018 at 10:51:12PM -0800, Richard Smith wrote:=20
> >> On 23 Feb 2018 16:34, "Arthur O'Dwyer" <arthur....@gmail.com=20
> <javascript:>> wrote:=20
> >>=20
> >> On Fri, Feb 23, 2018 at 3:07 PM, JF Bastien <jfba...@apple.com=20
> <javascript:>> wrote:=20
> >>=20
> >>> On Feb 23, 2018, at 14:47, Arthur O'Dwyer <arthur....@gmail.com=20
> <javascript:>>=20
> >>> wrote:=20
> >>>=20
> >>> On Fri, Feb 23, 2018 at 2:11 PM, JF Bastien <jfba...@apple.com=20
> <javascript:>> wrote:=20
> >>>=20
> >>=20
> >> Yes, that's what I intended to imply here. :)=20
> >> Nobody teaches about the interaction of ones'-complement or=20
> sign-magnitude=20
> >> with code-generators anymore because these don't happen in practice.=
=20
> >> People do teach about the interaction of undefined integer overflow=20
> with=20
> >> code-generators because this *does* happen in practice.=20
> >>=20
> >> Removing ones'-complement from C++ will be as painless (or painful) as=
=20
> >> removing trigraphs was.=20
> >> Removing integer overflow from C++ will be as painful (or painless) as=
=20
> >> removing type-based alias analysis would be.=20
> >=20
> > One thing I have been mulling over is if it would make sense to create=
=20
> > context-dependent keywords that allows the user to choose the behaviour=
=20
> > they want.=20
> >=20
> > nonoverflowing unsigned int foo; // UB if overflow=20
> > wrapping int bar; // Wraps=20
> >=20
> > I do not see these modifiers as beeing part of the types.=20
> >=20
> > Under this scheme "unsigned int" would be equivalent to "wrapping=20
> unsigned=20
> > int" and "int" would be equivalent to "nonoverflowing int".=20
> >=20
> > Obviously this bikeshed would need to be painted but that is for later.=
=20
> >=20
> > Changing the equivalence of int might be reasonable but that is an=20
> unrelated=20
> > change just like killing one-complement.=20
> >=20
> > /MF=20
> >=20
>
> Why make it keywords though?
>
Because otherwise they'd have to be *types*. And the whole point of his=20
suggestion was that they're not different types. There is no such thing as=
=20
a `wrapped int` type; there's just an `int`, which the compiler will treat=
=20
as "wrapped".
Now granted, I don't think this un-typed will work. If you do this:
wrapped int a =3D ...;
wrapped int b =3D ...;
int c =3D ...;
auto x =3D a + b;
auto y =3D a + c;
Is `x` or `y` declared `wrapped`? If `x` is wrapped and `y` is not, why?=20
How many `wrapped` integers does it take to make an expression "wrapped"?=
=20
And if neither of them are wrapped, how do you do auto-deduction with=20
wrapping?
With a type-based approach, these questions answer themselves.=20
`wrapped_int` would be a type. Adding a `wrapped_int` to a `wrapped_int`=20
would produce another `wrapped_int`, which `auto` would naturally deduce.=
=20
There would be rules about adding `wrapped_` types to their unwrapped=20
equivalents, which would make the deduction of `y` obvious. You're not=20
adding a phantasmal property to expressions; you're just using the type=20
system.
I think the main advantage of the untyped approach is that it neatly ducks=
=20
conversion issues. That is, is the conversion from `wrapped_int` to `int`=
=20
like a user-defined conversion, or is it like converting a `short` to an=20
`int`? How does it behave with overload resolution and scoring? And so=20
forth.
The thing is, we don't really *want* to treat a wrapped integer as a=20
different type from `int`. What we *really* want is to treat an *expression=
*=20
as wrapped or unwrapped. It's just that using a type-based approach to this=
=20
makes it much more convenient (from a language perspective) to do this,=20
since tracking the type of expressions is something we already do.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/17d9f9ec-4d63-416c-a476-3955fd9a702e%40isocpp.or=
g.
------=_Part_7721_167936028.1519490826121
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, February 24, 2018 at 11:08:43 AM UTC-=
5, Jonathan M=C3=BCller wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
On 24.02.2018 11:05, Magnus Fromreide wrote:
<br>> On Fri, Feb 23, 2018 at 10:51:12PM -0800, Richard Smith wrote:
<br>>> On 23 Feb 2018 16:34, "Arthur O'Dwyer" <<a hr=
ef=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"nhcxwAqPAgAJ"=
rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return t=
rue;" onclick=3D"this.href=3D'javascript:';return true;">arthur....=
@gmail.com</a>> wrote:
<br>>>
<br>>> On Fri, Feb 23, 2018 at 3:07 PM, JF Bastien <<a href=3D"jav=
ascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"nhcxwAqPAgAJ" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D'javascript:';return true;" onc=
lick=3D"this.href=3D'javascript:';return true;">jfba...@apple.com</=
a>> wrote:
<br>>>
<br>>>> On Feb 23, 2018, at 14:47, Arthur O'Dwyer <<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"nhcxwAqPAgAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return tru=
e;" onclick=3D"this.href=3D'javascript:';return true;">arthur....@g=
mail.com</a>>
<br>>>> wrote:
<br>>>>
<br>>>> On Fri, Feb 23, 2018 at 2:11 PM, JF Bastien <<a href=3D=
"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"nhcxwAqPAgAJ" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;=
" onclick=3D"this.href=3D'javascript:';return true;">jfba...@apple.=
com</a>> wrote:
<br>>>>
<br>>>
<br>>> Yes, that's what I intended to imply here. :)
<br>>> Nobody teaches about the interaction of ones'-complement o=
r sign-magnitude
<br>>> with code-generators anymore because these don't happen in=
practice.
<br>>> People do teach about the interaction of undefined integer ove=
rflow with
<br>>> code-generators because this *does* happen in practice.
<br>>>
<br>>> Removing ones'-complement from C++ will be as painless (or=
painful) as
<br>>> removing trigraphs was.
<br>>> Removing integer overflow from C++ will be as painful (or pain=
less) as
<br>>> removing type-based alias analysis would be.
<br>>=20
<br>> One thing I have been mulling over is if it would make sense to cr=
eate
<br>> context-dependent keywords that allows the user to choose the beha=
viour
<br>> they want.
<br>>=20
<br>> nonoverflowing unsigned int foo; // UB if overflow
<br>> wrapping int bar; // Wraps
<br>>=20
<br>> I do not see these modifiers as beeing part of the types.
<br>>=20
<br>> Under this scheme "unsigned int" would be equivalent to =
"wrapping unsigned
<br>> int" and "int" would be equivalent to "nonover=
flowing int".
<br>>=20
<br>> Obviously this bikeshed would need to be painted but that is for l=
ater.
<br>>=20
<br>> Changing the equivalence of int might be reasonable but that is an=
unrelated
<br>> change just like killing one-complement.
<br>>=20
<br>> /MF
<br>>=20
<br>
<br>Why make it keywords though?<br></blockquote><div><br>Because otherwise=
they'd have to be <i>types</i>. And the whole point of his suggestion =
was that they're not different types. There is no such thing as a `wrap=
ped int` type; there's just an `int`, which the compiler will treat as =
"wrapped".<br><br>Now granted, I don't think this un-typed wi=
ll work. If you do this:<br><br><div style=3D"background-color: rgb(250, 25=
0, 250); border-color: rgb(187, 187, 187); border-style: solid; border-widt=
h: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=
=3D"styled-by-prettify">wrapped </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> a </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">...;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>wrapped =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> b </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">...;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> c </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">...;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> x </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> a </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">+</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> b</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> y <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> a </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> c</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>Is `x` or `y` dec=
lared `wrapped`? If `x` is wrapped and `y` is not, why? How many `wrapped` =
integers does it take to make an expression "wrapped"? And if nei=
ther of them are wrapped, how do you do auto-deduction with wrapping?<br><b=
r>With a type-based approach, these questions answer themselves. `wrapped_i=
nt` would be a type. Adding a `wrapped_int` to a `wrapped_int` would produc=
e another `wrapped_int`, which `auto` would naturally deduce. There would b=
e rules about adding `wrapped_` types to their unwrapped equivalents, which=
would make the deduction of `y` obvious. You're not adding a phantasma=
l property to expressions; you're just using the type system.<br><br>I =
think the main advantage of the untyped approach is that it neatly ducks co=
nversion issues. That is, is the conversion from `wrapped_int` to `int` lik=
e a user-defined conversion, or is it like converting a `short` to an `int`=
? How does it behave with overload resolution and scoring? And so forth.<br=
><br>The thing is, we don't really <i>want</i> to treat a wrapped integ=
er as a different type from `int`. What we <i>really</i> want is to treat a=
n <i>expression</i> as wrapped or unwrapped. It's just that using a typ=
e-based approach to this makes it much more convenient (from a language per=
spective) to do this, since tracking the type of expressions is something w=
e already do.</div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/17d9f9ec-4d63-416c-a476-3955fd9a702e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/17d9f9ec-4d63-416c-a476-3955fd9a702e=
%40isocpp.org</a>.<br />
------=_Part_7721_167936028.1519490826121--
------=_Part_7720_2023908164.1519490826121--
.
Author: Robert Ramey <ramey@rrsd.com>
Date: Sat, 24 Feb 2018 09:28:57 -0800
Raw View
On 2/24/18 8:47 AM, Nicol Bolas wrote:
> With a type-based approach, these questions answer themselves.
> `wrapped_int` would be a type. Adding a `wrapped_int` to a `wrapped_int`
> would produce another `wrapped_int`, which `auto` would naturally
> deduce. There would be rules about adding `wrapped_` types to their
> unwrapped equivalents, which would make the deduction of `y` obvious.
> You're not adding a phantasmal property to expressions; you're just
> using the type system.
To get an idea where this eventually leads to, consider the safe
numerics library. I've been working on this for some time, it's been
accepted by Boost by is still pending integration into Boost. More
information can be found at the boost library incubator.
Robert Ramey
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/p6s78r%244cm%241%40blaine.gmane.org.
.
Author: =?UTF-8?Q?Jonathan_M=c3=bcller?= <jonathanmueller.dev@gmail.com>
Date: Sat, 24 Feb 2018 19:32:00 +0100
Raw View
On 24.02.2018 17:47, Nicol Bolas wrote:
>=20
>=20
> On Saturday, February 24, 2018 at 11:08:43 AM UTC-5, Jonathan M=C3=BCller=
wrote:
>=20
> Why make it keywords though?
>=20
>=20
> Because otherwise they'd have to be /types/. And the whole point of his=
=20
> suggestion was that they're not different types. There is no such thing=
=20
> as a `wrapped int` type; there's just an `int`, which the compiler will=
=20
> treat as "wrapped".
>=20
But what's the downside of making them types?
I've heard of languages where you have `+` for addition with UB overflow=20
and something like `+%` for addition with modulo. But I don't think it=20
makes that much sense: either you want addition with UB for all addition=20
operations on an object, or modulo for all. The only exception - I can=20
think of - would be in the implementation of an `would_overflow(a, b)`,=20
but there you can cast.
> I think the main advantage of the untyped approach is that it neatly=20
> ducks conversion issues. That is, is the conversion from `wrapped_int`=20
> to `int` like a user-defined conversion, or is it like converting a=20
> `short` to an `int`? How does it behave with overload resolution and=20
> scoring? And so forth.
I don't think you'd need implicit conversion for those at all.
But I'm not a fan of implicit conversion anyway.
> The thing is, we don't really /want/ to treat a wrapped integer as a=20
> different type from `int`. What we /really/ want is to treat an=20
> /expression/ as wrapped or unwrapped.
I disagree, but don't have a strong opinion there.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/278b25ca-746e-abca-75b2-3a2b7112eb1a%40gmail.com=
..
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 24 Feb 2018 11:44:47 -0800 (PST)
Raw View
------=_Part_9362_270294237.1519501487649
Content-Type: multipart/alternative;
boundary="----=_Part_9363_597392119.1519501487650"
------=_Part_9363_597392119.1519501487650
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Saturday, February 24, 2018 at 1:32:08 PM UTC-5, Jonathan M=C3=BCller wr=
ote:
>
> On 24.02.2018 17:47, Nicol Bolas wrote:=20
> >=20
> >=20
> > On Saturday, February 24, 2018 at 11:08:43 AM UTC-5, Jonathan M=C3=BCll=
er=20
> wrote:=20
> >=20
> > Why make it keywords though?=20
> >=20
> >=20
> > Because otherwise they'd have to be /types/. And the whole point of his=
=20
> > suggestion was that they're not different types. There is no such thing=
=20
> > as a `wrapped int` type; there's just an `int`, which the compiler will=
=20
> > treat as "wrapped".=20
> >=20
>
> But what's the downside of making them types?
>
Wrapping behavior is not really a property of object; it's a property of=20
how you *use* the object. By putting it in the object type, you now create=
=20
oddities. For example, you can overload on `wrapped_int` vs. `int`, which=
=20
can create *very* strange behavior. Is that a useful thing?
I've heard of languages where you have `+` for addition with UB overflow=20
> and something like `+%` for addition with modulo. But I don't think it=20
> makes that much sense: either you want addition with UB for all addition=
=20
> operations on an object, or modulo for all. The only exception - I can=20
> think of - would be in the implementation of an `would_overflow(a, b)`,=
=20
> but there you can cast.=20
>
> > I think the main advantage of the untyped approach is that it neatly=20
> > ducks conversion issues. That is, is the conversion from `wrapped_int`=
=20
> > to `int` like a user-defined conversion, or is it like converting a=20
> > `short` to an `int`? How does it behave with overload resolution and=20
> > scoring? And so forth.=20
>
> I don't think you'd need implicit conversion for those at all.
>
Consider this:
wrapped_int i =3D ...;
auto j =3D i + 5;
If that doesn't get me proper wrapping behavior, or worse if it is a=20
compile error due to the lack of conversion, then something is wrong with=
=20
your `wrapped_int`.
=20
> But I'm not a fan of implicit conversion anyway.=20
>
> > The thing is, we don't really /want/ to treat a wrapped integer as a=20
> > different type from `int`. What we /really/ want is to treat an=20
> > /expression/ as wrapped or unwrapped.=20
>
> I disagree, but don't have a strong opinion there.=20
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/016893a1-f1a5-4db0-9852-68be9c822a5d%40isocpp.or=
g.
------=_Part_9363_597392119.1519501487650
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, February 24, 2018 at 1:32:08 PM UTC-5=
, Jonathan M=C3=BCller wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">O=
n 24.02.2018 17:47, Nicol Bolas wrote:
<br>>=20
<br>>=20
<br>> On Saturday, February 24, 2018 at 11:08:43 AM UTC-5, Jonathan M=C3=
=BCller wrote:
<br>>=20
<br>> =C2=A0 =C2=A0 Why make it keywords though?
<br>>=20
<br>>=20
<br>> Because otherwise they'd have to be /types/. And the whole poi=
nt of his=20
<br>> suggestion was that they're not different types. There is no s=
uch thing=20
<br>> as a `wrapped int` type; there's just an `int`, which the comp=
iler will=20
<br>> treat as "wrapped".
<br>>=20
<br>
<br>But what's the downside of making them types?<br></blockquote><div>=
<br>Wrapping behavior is not really a property of object; it's a proper=
ty of how you <i>use</i> the object. By putting it in the object type, you =
now create oddities. For example, you can overload on `wrapped_int` vs. `in=
t`, which can create <i>very</i> strange behavior. Is that a useful thing?<=
br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
I've heard of languages where you have `+` for addition with UB overflo=
w=20
<br>and something like `+%` for addition with modulo. But I don't think=
it=20
<br>makes that much sense: either you want addition with UB for all additio=
n=20
<br>operations on an object, or modulo for all. The only exception - I can=
=20
<br>think of - would be in the implementation of an `would_overflow(a, b)`,=
=20
<br>but there you can cast.
<br>
<br>> I think the main advantage of the untyped approach is that it neat=
ly=20
<br>> ducks conversion issues. That is, is the conversion from `wrapped_=
int`=20
<br>> to `int` like a user-defined conversion, or is it like converting =
a=20
<br>> `short` to an `int`? How does it behave with overload resolution a=
nd=20
<br>> scoring? And so forth.
<br>
<br>I don't think you'd need implicit conversion for those at all.<=
br></blockquote><div><br>Consider this:<br><br><div style=3D"background-col=
or: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: sol=
id; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><c=
ode class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">wrapped_int i </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">...;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> j </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> i </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">+</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">5</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span></div></code></div><br>If tha=
t doesn't get me proper wrapping behavior, or worse if it is a compile =
error due to the lack of conversion, then something is wrong with your `wra=
pped_int`.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">But =
I'm not a fan of implicit conversion anyway.
<br>
<br>> The thing is, we don't really /want/ to treat a wrapped intege=
r as a=20
<br>> different type from `int`. What we /really/ want is to treat an=20
<br>> /expression/ as wrapped or unwrapped.
<br>
<br>I disagree, but don't have a strong opinion there.
<br></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/016893a1-f1a5-4db0-9852-68be9c822a5d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/016893a1-f1a5-4db0-9852-68be9c822a5d=
%40isocpp.org</a>.<br />
------=_Part_9363_597392119.1519501487650--
------=_Part_9362_270294237.1519501487649--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sat, 24 Feb 2018 17:10:15 -0500
Raw View
--f4030435397ca94cf20565fc8aa6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Sat, Feb 24, 2018 at 2:44 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Saturday, February 24, 2018 at 1:32:08 PM UTC-5, Jonathan M=C3=BCller =
wrote:
>>
>> On 24.02.2018 17:47, Nicol Bolas wrote:
>> >
>> >
>> > On Saturday, February 24, 2018 at 11:08:43 AM UTC-5, Jonathan M=C3=BCl=
ler
>> wrote:
>> >
>> > Why make it keywords though?
>> >
>> >
>> > Because otherwise they'd have to be /types/. And the whole point of hi=
s
>> > suggestion was that they're not different types. There is no such thin=
g
>> > as a `wrapped int` type; there's just an `int`, which the compiler wil=
l
>> > treat as "wrapped".
>> >
>>
>> But what's the downside of making them types?
>>
>
> Wrapping behavior is not really a property of object; it's a property of
> how you *use* the object.
>
A type is an interpretation of bytes, plus allowable operations on those
bytes.
A wrapping int and a non-wrapping int have the same interpretations (the
number 17 is stored the same for both, I imagine), but they do different
operations (or do the same operations differently).
So they are different types.
Or make a single type with extra operations (+<, +%, etc)
> By putting it in the object type, you now create oddities. For example,
> you can overload on `wrapped_int` vs. `int`, which can create *very*
> strange behavior. Is that a useful thing?
>
> I've heard of languages where you have `+` for addition with UB overflow
>> and something like `+%` for addition with modulo. But I don't think it
>> makes that much sense: either you want addition with UB for all addition
>> operations on an object, or modulo for all. The only exception - I can
>> think of - would be in the implementation of an `would_overflow(a, b)`,
>> but there you can cast.
>>
>> > I think the main advantage of the untyped approach is that it neatly
>> > ducks conversion issues. That is, is the conversion from `wrapped_int`
>> > to `int` like a user-defined conversion, or is it like converting a
>> > `short` to an `int`? How does it behave with overload resolution and
>> > scoring? And so forth.
>>
>> I don't think you'd need implicit conversion for those at all.
>>
>
> Consider this:
>
> wrapped_int i =3D ...;
> auto j =3D i + 5;
>
> If that doesn't get me proper wrapping behavior, or worse if it is a
> compile error due to the lack of conversion, then something is wrong with
> your `wrapped_int`.
>
>
>> But I'm not a fan of implicit conversion anyway.
>>
>> > The thing is, we don't really /want/ to treat a wrapped integer as a
>> > different type from `int`. What we /really/ want is to treat an
>> > /expression/ as wrapped or unwrapped.
>>
>> I disagree, but don't have a strong opinion there.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/016893a1-f1a5-4db0-
> 9852-68be9c822a5d%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/016893a1-f1=
a5-4db0-9852-68be9c822a5d%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=20
Be seeing you,
Tony
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOHCbive7KpLK8c3f0z9%3DMr8YfZxM%3DiDCf6Yhdn2_e7=
%2B4V0ZtA%40mail.gmail.com.
--f4030435397ca94cf20565fc8aa6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Feb 24, 2018 at 2:44 PM, Nicol Bolas <span dir=3D"ltr"><<a h=
ref=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><spa=
n class=3D""><br><br>On Saturday, February 24, 2018 at 1:32:08 PM UTC-5, Jo=
nathan M=C3=BCller wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 24.02.2=
018 17:47, Nicol Bolas wrote:
<br>>=20
<br>>=20
<br>> On Saturday, February 24, 2018 at 11:08:43 AM UTC-5, Jonathan M=C3=
=BCller wrote:
<br>>=20
<br>> =C2=A0 =C2=A0 Why make it keywords though?
<br>>=20
<br>>=20
<br>> Because otherwise they'd have to be /types/. And the whole poi=
nt of his=20
<br>> suggestion was that they're not different types. There is no s=
uch thing=20
<br>> as a `wrapped int` type; there's just an `int`, which the comp=
iler will=20
<br>> treat as "wrapped".
<br>>=20
<br>
<br>But what's the downside of making them types?<br></blockquote></spa=
n><div><br>Wrapping behavior is not really a property of object; it's a=
property of how you <i>use</i> the object.</div></div></blockquote><div><b=
r></div><div><br>A type is an interpretation of bytes, plus allowable opera=
tions on those bytes.<br></div><div>A wrapping int and a non-wrapping int h=
ave the same interpretations (the number 17 is stored the same for both, I =
imagine), but they do different operations (or do the same operations diffe=
rently).<br></div><div>So they are different types.<br></div><div><br></div=
><div>Or make a single type with extra operations (+<, +%, etc)<br><br><=
br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
div>By putting it in the object type, you now create oddities. For example,=
you can overload on `wrapped_int` vs. `int`, which can create <i>very</i> =
strange behavior. Is that a useful thing?<br><br></div><span class=3D""><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
I've heard of languages where you have `+` for addition with UB overflo=
w=20
<br>and something like `+%` for addition with modulo. But I don't think=
it=20
<br>makes that much sense: either you want addition with UB for all additio=
n=20
<br>operations on an object, or modulo for all. The only exception - I can=
=20
<br>think of - would be in the implementation of an `would_overflow(a, b)`,=
=20
<br>but there you can cast.
<br>
<br>> I think the main advantage of the untyped approach is that it neat=
ly=20
<br>> ducks conversion issues. That is, is the conversion from `wrapped_=
int`=20
<br>> to `int` like a user-defined conversion, or is it like converting =
a=20
<br>> `short` to an `int`? How does it behave with overload resolution a=
nd=20
<br>> scoring? And so forth.
<br>
<br>I don't think you'd need implicit conversion for those at all.<=
br></blockquote></span><div><br>Consider this:<br><br><div style=3D"backgro=
und-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid=
;border-width:1px" class=3D"m_6738347095428034843prettyprint"><code class=
=3D"m_6738347095428034843prettyprint"><div class=3D"m_6738347095428034843su=
bprettyprint"><span style=3D"color:#000" class=3D"m_6738347095428034843styl=
ed-by-prettify">wrapped_int i </span><span style=3D"color:#660" class=3D"m_=
6738347095428034843styled-by-prettify">=3D</span><span style=3D"color:#000"=
class=3D"m_6738347095428034843styled-by-prettify"> </span><span style=3D"c=
olor:#660" class=3D"m_6738347095428034843styled-by-prettify">...;</span><sp=
an style=3D"color:#000" class=3D"m_6738347095428034843styled-by-prettify"><=
br></span><span style=3D"color:#008" class=3D"m_6738347095428034843styled-b=
y-prettify">auto</span><span style=3D"color:#000" class=3D"m_67383470954280=
34843styled-by-prettify"> j </span><span style=3D"color:#660" class=3D"m_67=
38347095428034843styled-by-prettify">=3D</span><span style=3D"color:#000" c=
lass=3D"m_6738347095428034843styled-by-prettify"> i </span><span style=3D"c=
olor:#660" class=3D"m_6738347095428034843styled-by-prettify">+</span><span =
style=3D"color:#000" class=3D"m_6738347095428034843styled-by-prettify"> </s=
pan><span style=3D"color:#066" class=3D"m_6738347095428034843styled-by-pret=
tify">5</span><span style=3D"color:#660" class=3D"m_6738347095428034843styl=
ed-by-prettify">;</span></div></code></div><br>If that doesn't get me p=
roper wrapping behavior, or worse if it is a compile error due to the lack =
of conversion, then something is wrong with your `wrapped_int`.<br>=C2=A0</=
div><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">But I'm no=
t a fan of implicit conversion anyway.
<br>
<br>> The thing is, we don't really /want/ to treat a wrapped intege=
r as a=20
<br>> different type from `int`. What we /really/ want is to treat an=20
<br>> /expression/ as wrapped or unwrapped.
<br>
<br>I disagree, but don't have a strong opinion there.
<br></blockquote></span></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/016893a1-f1a5-4db0-9852-68be9c822a5d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/0168=
93a1-f1a5-4db0-<wbr>9852-68be9c822a5d%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></div></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbive7KpLK8c3f0z9%3DMr8YfZxM%3DiD=
Cf6Yhdn2_e7%2B4V0ZtA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbive7K=
pLK8c3f0z9%3DMr8YfZxM%3DiDCf6Yhdn2_e7%2B4V0ZtA%40mail.gmail.com</a>.<br />
--f4030435397ca94cf20565fc8aa6--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 24 Feb 2018 15:04:16 -0800 (PST)
Raw View
------=_Part_9924_1243476410.1519513456508
Content-Type: multipart/alternative;
boundary="----=_Part_9925_195244270.1519513456509"
------=_Part_9925_195244270.1519513456509
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Saturday, February 24, 2018 at 5:10:18 PM UTC-5, Tony V E wrote:
>
> On Sat, Feb 24, 2018 at 2:44 PM, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> wrote:
>
>>
>>
>> On Saturday, February 24, 2018 at 1:32:08 PM UTC-5, Jonathan M=C3=BCller=
wrote:
>>>
>>> On 24.02.2018 17:47, Nicol Bolas wrote:=20
>>> >=20
>>> >=20
>>> > On Saturday, February 24, 2018 at 11:08:43 AM UTC-5, Jonathan M=C3=BC=
ller=20
>>> wrote:=20
>>> >=20
>>> > Why make it keywords though?=20
>>> >=20
>>> >=20
>>> > Because otherwise they'd have to be /types/. And the whole point of=
=20
>>> his=20
>>> > suggestion was that they're not different types. There is no such=20
>>> thing=20
>>> > as a `wrapped int` type; there's just an `int`, which the compiler=20
>>> will=20
>>> > treat as "wrapped".=20
>>> >=20
>>>
>>> But what's the downside of making them types?
>>>
>>
>> Wrapping behavior is not really a property of object; it's a property of=
=20
>> how you *use* the object.
>>
>
>
> A type is an interpretation of bytes, plus allowable operations on those=
=20
> bytes.
> A wrapping int and a non-wrapping int have the same interpretations (the=
=20
> number 17 is stored the same for both, I imagine), but they do different=
=20
> operations (or do the same operations differently).
>
But they don't even do things differently per-se. If `int` and=20
`wrapped_int` are both 2's complement, the only difference between them is=
=20
how the *compiler* interprets an overflow. In one case, overflow is=20
considered UB; in the other, it has well-defined behavior.
It's not a property of the operation itself; it's a property of the=20
resulting value of that operation. That's why I'm thinking that this is=20
best handled by specifying that you want the *expression* to wrap signed=20
overflow:
auto x =3D wrapped{a + b};
This would mean that any math operation on integers within that boundary=20
wraps overflow, according to the rules of 2's complement.
And you ought to be able to do this for statements. Lots of statements:
wrapped
{
auto math =3D a + b;
auto is =3D math - c;
auto being =3D a + math;
auto done =3D c + being + is;
}
I don't know if this is worthy of a keyword, but the general idea ought to=
=20
be that you designate the explicit operations you want to do this on, not=
=20
the types or objects. And if we want to create a `std::wrapped_int` that=20
wraps a regular `int` and forwards all expressions with `wrapped{}`, that's=
=20
fine.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/46b2d1b6-4516-4916-892e-4176e9bda452%40isocpp.or=
g.
------=_Part_9925_195244270.1519513456509
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, February 24, 2018 at 5:10:18 PM UTC-5, Tony V=
E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
><div class=3D"gmail_quote">On Sat, Feb 24, 2018 at 2:44 PM, Nicol Bolas <s=
pan dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"JWwFB8aiAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;return true;">jmck...@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><span><br><br>On Saturday, February 24, 2018=
at 1:32:08 PM UTC-5, Jonathan M=C3=BCller wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">On 24.02.2018 17:47, Nicol Bolas wrote:
<br>>=20
<br>>=20
<br>> On Saturday, February 24, 2018 at 11:08:43 AM UTC-5, Jonathan M=C3=
=BCller wrote:
<br>>=20
<br>> =C2=A0 =C2=A0 Why make it keywords though?
<br>>=20
<br>>=20
<br>> Because otherwise they'd have to be /types/. And the whole poi=
nt of his=20
<br>> suggestion was that they're not different types. There is no s=
uch thing=20
<br>> as a `wrapped int` type; there's just an `int`, which the comp=
iler will=20
<br>> treat as "wrapped".
<br>>=20
<br>
<br>But what's the downside of making them types?<br></blockquote></spa=
n><div><br>Wrapping behavior is not really a property of object; it's a=
property of how you <i>use</i> the object.</div></div></blockquote><div><b=
r></div><div><br>A type is an interpretation of bytes, plus allowable opera=
tions on those bytes.<br></div><div>A wrapping int and a non-wrapping int h=
ave the same interpretations (the number 17 is stored the same for both, I =
imagine), but they do different operations (or do the same operations diffe=
rently).<br></div></div></div></div></blockquote><div><br>But they don'=
t even do things differently per-se. If `int` and `wrapped_int` are both 2&=
#39;s complement, the only difference between them is how the <i>compiler</=
i> interprets an overflow. In one case, overflow is considered UB; in the o=
ther, it has well-defined behavior.<br><br>It's not a property of the o=
peration itself; it's a property of the resulting value of that operati=
on. That's why I'm thinking that this is best handled by specifying=
that you want the <i>expression</i> to wrap signed overflow:<br><br><div s=
tyle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 1=
87); border-style: solid; border-width: 1px; overflow-wrap: break-word;" cl=
ass=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> x </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> wrapped</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify">a </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> b</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">};</span></div></code></div><br>This would mean that any math operat=
ion on integers within that boundary wraps overflow, according to the rules=
of 2's complement.<br><br>And you ought to be able to do this for stat=
ements. Lots of statements:<br><br><div style=3D"background-color: rgb(250,=
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-w=
idth: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">wrapped<br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> math </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> a </span><span style=3D"color: #660;" class=3D"styled-by-prettify">+</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> b</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">is</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> math </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">-</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> c</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> being </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> a </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> math</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">done=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> c </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">+</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> being </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">is</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></d=
iv></code></div><br></div>I don't know if this is worthy of a keyword, =
but the general idea ought to be that you designate the explicit operations=
you want to do this on, not the types or objects. And if we want to create=
a `std::wrapped_int` that wraps a regular `int` and forwards all expressio=
ns with `wrapped{}`, that's fine.<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/46b2d1b6-4516-4916-892e-4176e9bda452%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/46b2d1b6-4516-4916-892e-4176e9bda452=
%40isocpp.org</a>.<br />
------=_Part_9925_195244270.1519513456509--
------=_Part_9924_1243476410.1519513456508--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Sat, 24 Feb 2018 15:06:05 -0800 (PST)
Raw View
------=_Part_9937_279886294.1519513565791
Content-Type: multipart/alternative;
boundary="----=_Part_9938_784115216.1519513565791"
------=_Part_9938_784115216.1519513565791
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Saturday, February 24, 2018 at 2:10:18 PM UTC-8, Tony V E wrote:
>
> On Sat, Feb 24, 2018 at 2:44 PM, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> wrote:
>>
>> On Saturday, February 24, 2018 at 1:32:08 PM UTC-5, Jonathan M=C3=BCller=
wrote:
>>>
>>>
>>> But what's the downside of making them types?
>>>
>>
>> Wrapping behavior is not really a property of object; it's a property of=
=20
>> how you *use* the object.
>>
>
> A type is an interpretation of bytes, plus allowable operations on those=
=20
> bytes.
> A wrapping int and a non-wrapping int have the same interpretations (the=
=20
> number 17 is stored the same for both, I imagine), but they do different=
=20
> operations (or do the same operations differently).
> So they are different types.
>
> Or make a single type with extra operations (+<, +%, etc)
>
Tony is absolutely correct.
Note that the extra operations (if any) do not *have* to be spelled +<, +%,=
=20
etc. In typical C and C++ codebases, they are spelled as functions:=20
wrapping_add, safe_add, whatever.
An excruciatingly detailed set of "safe math" functions is available in the=
=20
Csmith include files:
https://github.com/csmith-project/csmith/tree/master/runtime
although unfortunately in the repo they're expressed as a bunch of M4=20
macros that have to be macro-processed before use (i.e., I can't give a URL=
=20
directly to the functions because they don't exist in the Csmith repo as=20
such).
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/236d0854-7aea-402d-a04b-9a3cf6884cfb%40isocpp.or=
g.
------=_Part_9938_784115216.1519513565791
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, February 24, 2018 at 2:10:18 PM UTC-8, Tony V=
E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
><div class=3D"gmail_quote">On Sat, Feb 24, 2018 at 2:44 PM, Nicol Bolas <s=
pan dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"JWwFB8aiAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;return true;">jmck...@gmail.com</a>></span> wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><span>On Saturday, February 24, 2018 at 1:32:08 =
PM UTC-5, Jonathan M=C3=BCller wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
">
<br>But what's the downside of making them types?<br></blockquote></spa=
n><div><br>Wrapping behavior is not really a property of object; it's a=
property of how you <i>use</i> the object.</div></div></blockquote><div><b=
r>A type is an interpretation of bytes, plus allowable operations on those =
bytes.<br></div><div>A wrapping int and a non-wrapping int have the same in=
terpretations (the number 17 is stored the same for both, I imagine), but t=
hey do different operations (or do the same operations differently).<br></d=
iv><div>So they are different types.<br></div><div><br></div><div>Or make a=
single type with extra operations (+<, +%, etc)<br></div></div></div></=
div></blockquote><div><br></div><div>Tony is absolutely correct.</div><div>=
<br></div><div>Note that the extra operations (if any) do not <i>have</i> t=
o be spelled +<, +%, etc. In typical C and C++ codebases, they are spell=
ed as functions: wrapping_add, safe_add, whatever.</div><div><br></div><div=
>An excruciatingly detailed set of "safe math" functions is avail=
able in the Csmith include files:</div><div><a href=3D"https://github.com/c=
smith-project/csmith/tree/master/runtime">https://github.com/csmith-project=
/csmith/tree/master/runtime</a><br></div><div>although unfortunately in the=
repo they're expressed as a bunch of M4 macros that have to be macro-p=
rocessed before use (i.e., I can't give a URL directly to the functions=
because they don't exist in the Csmith repo as such).</div><div><br></=
div><div>=E2=80=93Arthur</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/236d0854-7aea-402d-a04b-9a3cf6884cfb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/236d0854-7aea-402d-a04b-9a3cf6884cfb=
%40isocpp.org</a>.<br />
------=_Part_9938_784115216.1519513565791--
------=_Part_9937_279886294.1519513565791--
.
Author: olafvdspek@gmail.com
Date: Mon, 26 Feb 2018 02:49:33 -0800 (PST)
Raw View
------=_Part_14105_1862291390.1519642173985
Content-Type: multipart/alternative;
boundary="----=_Part_14106_1269683021.1519642173985"
------=_Part_14106_1269683021.1519642173985
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Op vrijdag 23 februari 2018 23:11:55 UTC+1 schreef JF Bastien:
>
> In the end I simply want two=E2=80=99s complement, and I see a few ways t=
hat this=20
> play out with everyone liking the outcome. I just ask that opposition com=
es=20
> with rationales, not =E2=80=9CI like my way better=E2=80=9D. :-)
>
Do you just want two's complement or do you also want defined behavior for=
=20
overflows of int etc?
Based on the Intro that's not clear to me.=20
For overflow checks, wouldn't functions that'd return whether an overflow=
=20
happened while doing the calculation be simpler?
=20
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6c7ff8a3-2ec3-4856-9f35-92924d22d6f8%40isocpp.or=
g.
------=_Part_14106_1269683021.1519642173985
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Op vrijdag 23 februari 2018 23:11:55 UTC+1 schreef JF Bast=
ien:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:br=
eak-word;line-break:after-white-space"><div>In the end I simply want two=E2=
=80=99s complement, and I see a few ways that this play out with everyone l=
iking the outcome. I just ask that opposition comes with rationales, not =
=E2=80=9CI like my way better=E2=80=9D. :-)</div></div></blockquote><div><b=
r></div><div>Do you just want two's complement or do you also want defi=
ned behavior for overflows of int etc?</div><div>Based on the Intro that=
9;s not clear to me.=C2=A0</div><div><br></div><div>For overflow checks, wo=
uldn't functions that'd return whether an overflow happened while d=
oing the calculation be simpler?</div><div>=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6c7ff8a3-2ec3-4856-9f35-92924d22d6f8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6c7ff8a3-2ec3-4856-9f35-92924d22d6f8=
%40isocpp.org</a>.<br />
------=_Part_14106_1269683021.1519642173985--
------=_Part_14105_1862291390.1519642173985--
.
Author: JF Bastien <jfbastien@apple.com>
Date: Mon, 26 Feb 2018 09:14:13 -0800
Raw View
--Boundary_(ID_5obqU6DVvFx9y8Lhq7kFZg)
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
> On Feb 26, 2018, at 02:49, olafvdspek@gmail.com wrote:
>=20
> Op vrijdag 23 februari 2018 23:11:55 UTC+1 schreef JF Bastien:
> In the end I simply want two=E2=80=99s complement, and I see a few ways t=
hat this play out with everyone liking the outcome. I just ask that opposit=
ion comes with rationales, not =E2=80=9CI like my way better=E2=80=9D. :-)
>=20
> Do you just want two's complement or do you also want defined behavior fo=
r overflows of int etc?
> Based on the Intro that's not clear to me.
I think defined overflow behavior is an obvious fallout of two=E2=80=99s co=
mplement because that=E2=80=99s how hardware works and C++ describes itself=
as offering =E2=80=9Ca direct map to hardware". I think default overflow b=
ehavior should be wrap, and we should have library or operator support for =
UB / trap / saturation. Others disagree on what should be the terse syntax.=
I=E2=80=99m fine with another solution which allows developers to write co=
de that overflows correctly without relying on non-obvious code patterns (s=
uch as casting to unsigned and back).
> For overflow checks, wouldn't functions that'd return whether an overflow=
happened while doing the calculation be simpler?
We simply disagree on what the default behavior of + - * should be. One app=
roach will have less syntax and the others more, I=E2=80=99m sure the commi=
ttee will come to a decent consensus solution.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7DABAA6B-836C-4614-969B-7A16C4681977%40apple.com=
..
--Boundary_(ID_5obqU6DVvFx9y8Lhq7kFZg)
Content-type: text/html; charset="UTF-8"
Content-transfer-encoding: quoted-printable
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; line-break: after-white-space;" class=3D""><br class=3D""><div><block=
quote type=3D"cite" class=3D""><div class=3D"">On Feb 26, 2018, at 02:49, <=
a href=3D"mailto:olafvdspek@gmail.com" class=3D"">olafvdspek@gmail.com</a> =
wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div di=
r=3D"ltr" class=3D"">Op vrijdag 23 februari 2018 23:11:55 UTC+1 schreef JF =
Bastien:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wra=
p:break-word;line-break:after-white-space" class=3D""><div class=3D"">In th=
e end I simply want two=E2=80=99s complement, and I see a few ways that thi=
s play out with everyone liking the outcome. I just ask that opposition com=
es with rationales, not =E2=80=9CI like my way better=E2=80=9D. :-)</div></=
div></blockquote><div class=3D""><br class=3D""></div><div class=3D"">Do yo=
u just want two's complement or do you also want defined behavior for overf=
lows of int etc?</div><div class=3D"">Based on the Intro that's not clear t=
o me.</div></div></div></blockquote><div><br class=3D""></div><div>I think =
defined overflow behavior is an obvious fallout of two=E2=80=99s complement=
because that=E2=80=99s how hardware works and C++ describes itself as offe=
ring =E2=80=9Ca direct map to hardware". I think default overflow behavior =
should be wrap, and we should have library or operator support for UB / tra=
p / saturation. Others disagree on what should be the terse syntax. I=E2=80=
=99m fine with another solution which allows developers to write code that =
overflows correctly without relying on non-obvious code patterns (such as c=
asting to unsigned and back).</div><br class=3D""><blockquote type=3D"cite"=
class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">For overflow checks=
, wouldn't functions that'd return whether an overflow happened while doing=
the calculation be simpler?</div></div></blockquote><br class=3D""></div><=
div>We simply disagree on what the default behavior of + - * should be. One=
approach will have less syntax and the others more, I=E2=80=99m sure the c=
ommittee will come to a decent consensus solution.</div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7DABAA6B-836C-4614-969B-7A16C4681977%=
40apple.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7DABAA6B-836C-4614-969B-7A16C4681977%=
40apple.com</a>.<br />
--Boundary_(ID_5obqU6DVvFx9y8Lhq7kFZg)--
.
Author: JF Bastien <jfbastien@apple.com>
Date: Mon, 26 Feb 2018 09:16:32 -0800
Raw View
--Boundary_(ID_+HfA7ov1o4BJwwMbKAyrCg)
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
> On Feb 23, 2018, at 22:51, Richard Smith <richard@metafoo.co.uk> wrote:
>=20
> On 23 Feb 2018 16:34, "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com <mailto=
:arthur.j.odwyer@gmail.com>> wrote:
> On Fri, Feb 23, 2018 at 3:07 PM, JF Bastien <jfbastien@apple.com <mailto:=
jfbastien@apple.com>> wrote:
> On Feb 23, 2018, at 14:47, Arthur O'Dwyer <arthur.j.odwyer@gmail.com <mai=
lto:arthur.j.odwyer@gmail.com>> wrote:
>> On Fri, Feb 23, 2018 at 2:11 PM, JF Bastien <jfbastien@apple.com <mailto=
:jfbastien@apple.com>> wrote:
>> Hi Arthur,
>>=20
>> I=E2=80=99ll be in JAX and will definitely champion my own approach, but=
will make sure any other approaches are discussed thoroughly. I=E2=80=99ll=
then ask for direction polls from EWG, and will follow the proposed direct=
ion in an updated paper.
>>=20
>> And if you manage to write the updated paper overnight and have it back =
on the table the next day at JAX, then my paper will be utterly superfluous=
.. :)
>>=20
>> I am, however, worried that the writing of a new paper might slip more t=
han a day, which would end up with you coming back in the pre-Rapperswil ma=
iling with another two's-complement paper after the perception that your fi=
rst two's-complement paper was "rejected" in Jacksonville, which would set =
a perceived negative precedent in people's minds.
> I=E2=80=99ve frequently presented updated papers after obtaining feedback=
: evenings are for paper writing.
>=20
> And if you manage to write the updated paper overnight and have it back o=
n the table the next day at JAX, then my paper will be utterly superfluous.=
:)
>=20
>=20
>> These are true, but then the current undefined behavior on signed overfl=
ow has some unmentioned good effects, too:
>>=20
>> - Unintentional unsigned wraparound (for example, in the argument to `ma=
lloc`) has been a known source of bugs for a long time. See for example [Re=
gehr2012] <https://www.cs.utah.edu/~regehr/papers/overflow12.pdf>, whose fi=
nal sentence is, "Our results also imply that tools for detecting integer n=
umerical errors need to distinguish intentional from unintentional uses of =
wraparound operations =E2=80=94 a challenging task =E2=80=94 in order to mi=
nimize false alarms. [emphasis added]" The current undefinedness of signed=
overflow permits implementations, such as UBSan, to detect all signed wrap=
around behavior as unintentional by definition, and diagnose it accordingly=
..
>=20
> unsigned wraparound isn=E2=80=99t UB, and I claim that signed overflow is=
UB because of the 3 representation, not to catch bugs, otherwise unsigned =
overflow would also have been UB. [...] I claim that this is also an emerge=
nt feature, not by design, caused by the 3 signed integer representations.
> =20
> I think you are right in the historical sense. These days the emergent "c=
atch bugs" rationale has survived, though, even as the exotic hardwares hav=
e died out.
>=20
>=20
> FWIW UBSan supports unsigned overflow detection:
> -fsanitize=3Dunsigned-integer-overflow: Unsigned integer overflows. Note =
that unlike signed integer overflow, unsigned integer is not undefined beha=
vior. However, while it has well-defined semantics, it is often unintention=
al, so UBSan offers to catch it.
>=20
> This is very cool; I was unaware of this.
> Your paper would benefit from mentioning this. But the obvious comeback i=
s: where's the numbers on how many false positives UBSan generates in this =
mode? That number cannot possibly be zero.
>=20
> The false positive rate is empirically huge, and extremely painful becaus=
e there is no easy syntactic way to distinguish between true and false posi=
tives.
I=E2=80=99ve asked Chandler but I=E2=80=99ll ask you as well: data would be=
great in getting committee consensus. To me =E2=80=9Cfalse positive=E2=80=
=9D sounds an awful lot like =E2=80=9Cnot a bug=E2=80=9D in this context :-=
)
>> - The impossibility of signed wraparound allows optimization of tight in=
ner loops such as
>> for (int i =3D a; i !=3D b; ++i)
>> Here the compiler is allowed to assume that `a <=3D b`, because if `b < =
a` the loop would eventually overflow and invoke undefined behavior.
>=20
> I claim that this is also an emergent feature, not by design, caused by t=
he 3 signed integer representations. I also claim that much of this perform=
ance can be regained with a better optimizer (the compiler I work on certai=
nly optimizes loops substantially without assuming UB on overflow). Further=
, the Internet shows that this optimization isn=E2=80=99t something develop=
ers knowingly opt into, and when they hit it they are surprised by the bugs=
it generates.
>=20
> Users never opt into bugs by definition. But users notice performance reg=
ressions (in the compiler) almost as quickly as they notice correctness reg=
ressions (in their own code).
>=20
>> This is intuitively the same behavior that we have with C++ iterators: t=
he compiler is allowed to assume that the existence of a loop over the rang=
e `a` to `b` implies that `b` is actually reachable from `a` according to f=
orward-increment semantics, even though in practice many implementations' s=
td::list::iterator internally performs the equivalent of "wrap on overflow.=
" (See the graphical diagram of "sentinel-node containers" in P0773 <http:/=
/www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0773r0.html#B> if needed=
..)
>> John McFarlane did a lightning talk about integer UB and codegen within =
the past year but I don't know if the slides are somewhere. I can ask him.
>=20
> The intuition is reversed, though: C came before C++ and iterators.
>=20
> Again, historically accurate but this is not modern C++'s problem. We don=
't teach C before C++. (And if we did, we might soon have to explain that i=
nteger overflow is undefined in C but not in C++? Add "C source-level compa=
tibility" to the list of rationales for preserving C's undefined overflow b=
ehavior in C++.)
>=20
>=20
>> I mean, it's not like there's any shortage of educational material on UB=
in C and C++ and its good and bad effects.
>=20
> Sure, do you believe there are particular references that should be read =
with my proposal?
>=20
> Off the top of my head, I recall John McFarlane's lightning talk on codeg=
en, Michael Spencer's "My Little Optimizer: Undefined Behavior Is Magic" ta=
lk, and pretty much anything involving John Regehr. I found the link to Reg=
ehr2012 as one of the top Google hits for "unintentional unsigned overflow"=
..
>=20
> =20
>> What there is a shortage of IMHO is material on ones'-complement in C an=
d C++. That's why I kept large swaths of your paper intact in my fork. :)
> Might the lack of such documentation be caused by a lack of ones=E2=80=99=
complement hardware using modern C++?
>=20
> Yes, that's what I intended to imply here. :)
> Nobody teaches about the interaction of ones'-complement or sign-magnitud=
e with code-generators anymore because these don't happen in practice.
> People do teach about the interaction of undefined integer overflow with =
code-generators because this does happen in practice.
>=20
> Removing ones'-complement from C++ will be as painless (or painful) as re=
moving trigraphs was.
> Removing integer overflow from C++ will be as painful (or painless) as re=
moving type-based alias analysis would be.
>=20
> =E2=80=93Arthur
>=20
> --=20
> You received this message because you are subscribed to the Google Groups=
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubs=
cribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/CADvuK0L%2BBDk3TMYX6znEe0RMbEPZfYGzEWDLjOXLB60=
EyR5R6g%40mail.gmail.com <https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/CADvuK0L%2BBDk3TMYX6znEe0RMbEPZfYGzEWDLjOXLB60EyR5R6g%40mail.gm=
ail.com?utm_medium=3Demail&utm_source=3Dfooter>.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9A5AF8C9-8FEF-417E-9DB3-E5A8790B5892%40apple.com=
..
--Boundary_(ID_+HfA7ov1o4BJwwMbKAyrCg)
Content-type: text/html; charset="UTF-8"
Content-transfer-encoding: quoted-printable
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; line-break: after-white-space;" class=3D""><br class=3D""><div><block=
quote type=3D"cite" class=3D""><div class=3D"">On Feb 23, 2018, at 22:51, R=
ichard Smith <<a href=3D"mailto:richard@metafoo.co.uk" class=3D"">richar=
d@metafoo.co.uk</a>> wrote:</div><br class=3D"Apple-interchange-newline"=
><div class=3D""><div dir=3D"auto" style=3D"caret-color: rgb(0, 0, 0); font=
-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps:=
normal; font-weight: normal; letter-spacing: normal; text-align: start; te=
xt-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0p=
x; -webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><div =
class=3D"gmail_extra" dir=3D"auto"><div class=3D"gmail_quote">On 23 Feb 201=
8 16:34, "Arthur O'Dwyer" <<a href=3D"mailto:arthur.j.odwyer@gmail.com" =
class=3D"">arthur.j.odwyer@gmail.com</a>> wrote:<br type=3D"attribution"=
class=3D""><blockquote class=3D"quote" style=3D"margin: 0px 0px 0px 0.8ex;=
border-left-width: 1px; border-left-style: solid; border-left-color: rgb(2=
04, 204, 204); padding-left: 1ex;"><div dir=3D"ltr" class=3D""><div class=
=3D"quoted-text">On Fri, Feb 23, 2018 at 3:07 PM, JF Bastien<span class=3D"=
Apple-converted-space"> </span><span dir=3D"ltr" class=3D""><<a hre=
f=3D"mailto:jfbastien@apple.com" target=3D"_blank" class=3D"">jfbastien@app=
le.com</a>></span><span class=3D"Apple-converted-space"> </span>wro=
te:<br class=3D""></div><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><div class=3D"quoted-text"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; =
border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style=3D"wo=
rd-wrap: break-word; line-break: after-white-space;" class=3D"">On Feb 23, =
2018, at 14:47, Arthur O'Dwyer <<a href=3D"mailto:arthur.j.odwyer@gmail.=
com" target=3D"_blank" class=3D"">arthur.j.odwyer@gmail.com</a>> wrote:<=
div class=3D""><span class=3D"m_-5722284926157665104gmail-"><blockquote typ=
e=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D"">On Fri, F=
eb 23, 2018 at 2:11 PM, JF Bastien<span class=3D"Apple-converted-space">&nb=
sp;</span><span dir=3D"ltr" class=3D""><<a href=3D"mailto:jfbastien@appl=
e.com" target=3D"_blank" class=3D"">jfbastien@apple.com</a>></span><span=
class=3D"Apple-converted-space"> </span>wrote:<br class=3D""><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-lef=
t-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">=
<div style=3D"word-wrap: break-word; line-break: after-white-space;" class=
=3D"">Hi Arthur,<div class=3D""><br class=3D""></div><div class=3D"">I=E2=
=80=99ll be in JAX and will definitely champion my own approach, but will m=
ake sure any other approaches are discussed thoroughly. I=E2=80=99ll then a=
sk for direction polls from EWG, and will follow the proposed direction in =
an updated paper.</div></div></blockquote><div class=3D""><br class=3D""></=
div><div class=3D"">And if you manage to write the updated paper overnight =
and have it back on the table the next day at JAX, then my paper<span class=
=3D"Apple-converted-space"> </span><i class=3D"">will</i><span class=
=3D"Apple-converted-space"> </span>be utterly superfluous. :)</div><di=
v class=3D""><br class=3D""></div><div class=3D"">I am, however, worried th=
at the writing of a new paper might slip more than a day, which would end u=
p with you coming back in the pre-Rapperswil mailing with another two's-com=
plement paper after the perception that your first two's-complement paper w=
as "rejected" in Jacksonville, which would set a perceived negative precede=
nt in people's minds.</div></div></div></div></div></blockquote><div class=
=3D"">I=E2=80=99ve frequently presented updated papers after obtaining feed=
back: evenings are for paper writing.<br class=3D""></div></span></div></di=
v></blockquote><br class=3D"">And if you manage to write the updated paper =
overnight and have it back on the table the next day at JAX, then my paper =
will be utterly superfluous. :)<br class=3D""><br class=3D""><br class=3D""=
></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex=
; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(=
204, 204, 204); padding-left: 1ex;"><div style=3D"word-wrap: break-word; li=
ne-break: after-white-space;" class=3D""><div class=3D""><div class=3D"quot=
ed-text"><span class=3D"m_-5722284926157665104gmail-"><blockquote type=3D"c=
ite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><div class=3D"">These are true, but =
then the current undefined behavior on signed overflow has some unmentioned=
good effects, too:</div><div class=3D""><br class=3D""></div><div class=3D=
"">- Unintentional unsigned wraparound (for example, in the argument to `ma=
lloc`) has been a known source of bugs for a long time. See for example<spa=
n class=3D"Apple-converted-space"> </span><a href=3D"https://www.cs.ut=
ah.edu/~regehr/papers/overflow12.pdf" target=3D"_blank" class=3D"">[Regehr2=
012]</a>, whose final sentence is, "Our results also imply that tools for d=
etecting integer numerical errors need to<span class=3D"Apple-converted-spa=
ce"> </span><b class=3D""><i class=3D"">distinguish intentional from u=
nintentional uses of wraparound operations</i></b><span class=3D"Apple-conv=
erted-space"> </span>=E2=80=94 a challenging task =E2=80=94 in order t=
o minimize false alarms. [emphasis added]" The current undefinedness =
of signed overflow permits implementations, such as UBSan, to detect all si=
gned wraparound behavior as unintentional by definition, and diagnose it ac=
cordingly.</div></div></div></div></div></blockquote><div class=3D""><br cl=
ass=3D""></div></span></div><div class=3D"">unsigned wraparound isn=E2=80=
=99t UB, and I claim that signed overflow is UB because of the 3 representa=
tion, not to catch bugs, otherwise unsigned overflow would also have been U=
B. [...] I claim that this is also an emergent feature, not by design, caus=
ed by the 3 signed integer representations.</div></div></div></blockquote><=
div class=3D""> </div><div class=3D"">I think you are right in the his=
torical sense. These days the emergent "catch bugs" rationale has survived,=
though, even as the exotic hardwares have died out.</div><div class=3D"quo=
ted-text"><div class=3D""><br class=3D""></div><div class=3D""><br class=3D=
""></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8=
ex; border-left-width: 1px; border-left-style: solid; border-left-color: rg=
b(204, 204, 204); padding-left: 1ex;"><div style=3D"word-wrap: break-word; =
line-break: after-white-space;" class=3D""><div class=3D""><div class=3D"">=
</div><div class=3D"">FWIW UBSan supports unsigned overflow detection:</div=
></div><blockquote style=3D"margin: 0px 0px 0px 40px; border: none; padding=
: 0px;" class=3D""><div class=3D""><div class=3D""><div class=3D"">-fsaniti=
ze=3Dunsigned-integer-ov<wbr class=3D"">erflow: Unsigned integer overflows.=
Note that unlike signed integer overflow, unsigned integer is not undefine=
d behavior. However, while it has well-defined semantics, it is often =
unintentional, so UBSan offers to catch it.</div></div></div></blockquote><=
/div></blockquote><div class=3D""><br class=3D""></div></div><div class=3D"=
">This is very cool; I was unaware of this.</div><div class=3D"">Your paper=
would benefit from mentioning this. But the obvious comeback is: where's t=
he numbers on how many false positives UBSan generates in this mode? That n=
umber cannot possibly be zero.</div></div></div></div></blockquote></div></=
div><div dir=3D"auto" class=3D""><br class=3D""></div><div dir=3D"auto" cla=
ss=3D"">The false positive rate is empirically huge, and extremely painful =
because there is no easy syntactic way to distinguish between true and fals=
e positives.</div></div></div></blockquote><div><br class=3D""></div><div>I=
=E2=80=99ve asked Chandler but I=E2=80=99ll ask you as well: data would be =
great in getting committee consensus. To me =E2=80=9Cfalse positive=E2=80=
=9D sounds an awful lot like =E2=80=9Cnot a bug=E2=80=9D in this context :-=
)</div><div><br class=3D""></div><br class=3D""><blockquote type=3D"cite" c=
lass=3D""><div class=3D""><div dir=3D"auto" style=3D"caret-color: rgb(0, 0,=
0); font-family: Helvetica; font-size: 12px; font-style: normal; font-vari=
ant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; word-sp=
acing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=
=3D""><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gmail_quote"><b=
lockquote class=3D"quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-w=
idth: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204);=
padding-left: 1ex;"><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"=
><div class=3D"gmail_quote"><div class=3D"quoted-text"><blockquote class=3D=
"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; b=
order-left-style: solid; border-left-color: rgb(204, 204, 204); padding-lef=
t: 1ex;"><div style=3D"word-wrap: break-word; line-break: after-white-space=
;" class=3D""><div class=3D""><span class=3D"m_-5722284926157665104gmail-">=
<blockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=
=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D""=
>- The impossibility of signed wraparound allows optimization of tight inne=
r loops such as</div><div class=3D""> <span class=3D"Apple-conv=
erted-space"> </span>for (int i =3D a; i !=3D b; ++i)</div><div class=
=3D"">Here the compiler is allowed to assume that `a <=3D b`, because if=
`b < a` the loop would eventually overflow and invoke undefined behavio=
r.</div></div></div></div></div></blockquote></span><div class=3D"">I claim=
that this is also an emergent feature, not by design, caused by the 3 sign=
ed integer representations. I also claim that much of this performance can =
be regained with a better optimizer (the compiler I work on certainly optim=
izes loops substantially without assuming UB on overflow). Further, the Int=
ernet shows that this optimization isn=E2=80=99t something developers knowi=
ngly opt into, and when they hit it they are surprised by the bugs it gener=
ates.</div></div></div></blockquote><div class=3D""><br class=3D""></div></=
div><div class=3D"">Users never opt into bugs by definition. But users noti=
ce performance regressions (in the<span class=3D"Apple-converted-space">&nb=
sp;</span><i class=3D"">compiler</i>) almost as quickly as they notice corr=
ectness regressions (in<span class=3D"Apple-converted-space"> </span><=
i class=3D"">their own code</i>).</div><div class=3D"quoted-text"><div clas=
s=3D""><br class=3D""></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; bo=
rder-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style=3D"word=
-wrap: break-word; line-break: after-white-space;" class=3D""><div class=3D=
""><span class=3D"m_-5722284926157665104gmail-"><blockquote type=3D"cite" c=
lass=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><div class=3D"">This is intuitively the sa=
me behavior that we have with C++ iterators: the compiler is allowed to ass=
ume that the existence of a loop over the range `a` to `b` implies that `b`=
is actually reachable from `a` according to forward-increment semantics, e=
ven though in practice many implementations' std::list::iterator internally=
performs the equivalent of "wrap on overflow." (See the graphical diagram =
of "sentinel-node containers" in<span class=3D"Apple-converted-space"> =
;</span><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/=
p0773r0.html#B" target=3D"_blank" class=3D"">P0773</a><span class=3D"Apple-=
converted-space"> </span>if needed.)</div><div class=3D"">John McFarla=
ne did a lightning talk about integer UB and codegen within the past year b=
ut I don't know if the slides are somewhere. I can ask him.</div></div></di=
v></div></div></blockquote></span><div class=3D"">The intuition is reversed=
, though: C came before C++ and iterators.</div></div></div></blockquote><d=
iv class=3D""><br class=3D""></div></div><div class=3D"">Again, historicall=
y accurate but this is not modern C++'s problem. We don't teach C before C+=
+. (And if we did, we might soon have to explain that integer overflow is u=
ndefined in C but not in C++? Add "C source-level compatibility" to the lis=
t of rationales for preserving C's undefined overflow behavior in C++.)</di=
v><div class=3D"quoted-text"><div class=3D""><br class=3D""></div><div clas=
s=3D""><br class=3D""></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; bo=
rder-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style=3D"word=
-wrap: break-word; line-break: after-white-space;" class=3D""><div class=3D=
""><span class=3D"m_-5722284926157665104gmail-"><blockquote type=3D"cite" c=
lass=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><div class=3D"">I mean, it's not like ther=
e's any shortage of educational material on UB in C and C++ and its<span cl=
ass=3D"Apple-converted-space"> </span><b class=3D""><i class=3D"">good=
and</i></b><span class=3D"Apple-converted-space"> </span>bad effects.=
</div></div></div></div></div></blockquote><div class=3D""><br class=3D""><=
/div></span><div class=3D"">Sure, do you believe there are particular refer=
ences that should be read with my proposal?</div></div></div></blockquote><=
div class=3D""><br class=3D""></div></div><div class=3D"">Off the top of my=
head, I recall John McFarlane's lightning talk on codegen, Michael Spencer=
's "My Little Optimizer: Undefined Behavior Is Magic" talk, and pretty much=
anything involving John Regehr. I found the link to Regehr2012 as one of t=
he top Google hits for "unintentional unsigned overflow".</div><div class=
=3D"quoted-text"><div class=3D""><br class=3D""></div><div class=3D""> =
;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex=
; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(=
204, 204, 204); padding-left: 1ex;"><div style=3D"word-wrap: break-word; li=
ne-break: after-white-space;" class=3D""><div class=3D""><span class=3D"m_-=
5722284926157665104gmail-"><blockquote type=3D"cite" class=3D""><div class=
=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><div class=3D"">What there<span class=3D"Apple-converted-space=
"> </span><i class=3D"">is</i><span class=3D"Apple-converted-space">&n=
bsp;</span>a shortage of IMHO is material on<span class=3D"Apple-converted-=
space"> </span><i class=3D""><b class=3D"">ones'-complement</b></i><sp=
an class=3D"Apple-converted-space"> </span>in C and C++. That's why I =
kept large swaths of your paper intact in my fork. :)</div></div></div></di=
v></div></blockquote><div class=3D"">Might the lack of such documentation b=
e caused by a lack of ones=E2=80=99 complement hardware using modern C++?<b=
r class=3D""></div></span></div></div></blockquote><div class=3D""><br clas=
s=3D""></div></div><div class=3D"">Yes, that's what I intended to imply her=
e. :)</div><div class=3D"">Nobody teaches about the interaction of ones'-co=
mplement or sign-magnitude with code-generators anymore because these don't=
happen in practice.</div><div class=3D"">People do teach about the interac=
tion of undefined integer overflow with code-generators because this<span c=
lass=3D"Apple-converted-space"> </span><i class=3D"">does</i><span cla=
ss=3D"Apple-converted-space"> </span>happen in practice.</div><div cla=
ss=3D""><br class=3D""></div><div class=3D"">Removing ones'-complement from=
C++ will be as painless (or painful) as removing trigraphs was.</div><div =
class=3D"">Removing integer overflow from C++ will be as painful (or painle=
ss) as removing type-based alias analysis would be.</div><div class=3D""><b=
r class=3D""></div><div class=3D"">=E2=80=93Arthur</div></div></div></div><=
div class=3D"quoted-text"><div class=3D""><br class=3D"webkit-block-placeho=
lder"></div>--<span class=3D"Apple-converted-space"> </span><br class=
=3D"">You received this message because you are subscribed to the Google Gr=
oups "ISO C++ Standard - Future Proposals" group.<br class=3D"">To unsubscr=
ibe from this group and stop receiving emails from it, send an email to<spa=
n class=3D"Apple-converted-space"> </span><a href=3D"mailto:std-propos=
als+unsubscribe@isocpp.org" target=3D"_blank" class=3D"">std-proposals+unsu=
bscribe@<wbr class=3D"">isocpp.org</a>.<br class=3D"">To post to this group=
, send email to<span class=3D"Apple-converted-space"> </span><a href=
=3D"mailto:std-proposals@isocpp.org" target=3D"_blank" class=3D"">std-propo=
sals@isocpp.org</a>.<br class=3D""></div>To view this discussion on the web=
visit<span class=3D"Apple-converted-space"> </span><a href=3D"https:/=
/groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0L%2BBDk3TMYX6z=
nEe0RMbEPZfYGzEWDLjOXLB60EyR5R6g%40mail.gmail.com?utm_medium=3Demail&ut=
m_source=3Dfooter" target=3D"_blank" class=3D"">https://groups.google.com/a=
/<wbr class=3D"">isocpp.org/d/msgid/std-<wbr class=3D"">proposals/CADvuK0L%=
<wbr class=3D"">2BBDk3TMYX6znEe0RMbEPZfYGzEWDL<wbr class=3D"">jOXLB60EyR5R6=
g%40mail.gmail.<wbr class=3D"">com</a>.</blockquote></div></div></div></div=
></blockquote></div><br class=3D""></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9A5AF8C9-8FEF-417E-9DB3-E5A8790B5892%=
40apple.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9A5AF8C9-8FEF-417E-9DB3-E5A8790B5892%=
40apple.com</a>.<br />
--Boundary_(ID_+HfA7ov1o4BJwwMbKAyrCg)--
.
Author: JF Bastien <jfbastien@apple.com>
Date: Mon, 26 Feb 2018 09:37:36 -0800
Raw View
--Boundary_(ID_k7MA/lZX1QBqCAqufsqm7g)
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
> On Feb 23, 2018, at 16:34, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wro=
te:
>=20
> On Fri, Feb 23, 2018 at 3:07 PM, JF Bastien <jfbastien@apple.com <mailto:=
jfbastien@apple.com>> wrote:
> On Feb 23, 2018, at 14:47, Arthur O'Dwyer <arthur.j.odwyer@gmail.com <mai=
lto:arthur.j.odwyer@gmail.com>> wrote:
>> On Fri, Feb 23, 2018 at 2:11 PM, JF Bastien <jfbastien@apple.com <mailto=
:jfbastien@apple.com>> wrote:
>> Hi Arthur,
>>=20
>> I=E2=80=99ll be in JAX and will definitely champion my own approach, but=
will make sure any other approaches are discussed thoroughly. I=E2=80=99ll=
then ask for direction polls from EWG, and will follow the proposed direct=
ion in an updated paper.
>>=20
>> And if you manage to write the updated paper overnight and have it back =
on the table the next day at JAX, then my paper will be utterly superfluous=
.. :)
>>=20
>> I am, however, worried that the writing of a new paper might slip more t=
han a day, which would end up with you coming back in the pre-Rapperswil ma=
iling with another two's-complement paper after the perception that your fi=
rst two's-complement paper was "rejected" in Jacksonville, which would set =
a perceived negative precedent in people's minds.
> I=E2=80=99ve frequently presented updated papers after obtaining feedback=
: evenings are for paper writing.
>=20
> And if you manage to write the updated paper overnight and have it back o=
n the table the next day at JAX, then my paper will be utterly superfluous.=
:)
Write your paper if you want, I just don=E2=80=99t see a point to it. Editi=
ng the paper is trivial, your paper just doesn=E2=80=99t help at all.
>> These are true, but then the current undefined behavior on signed overfl=
ow has some unmentioned good effects, too:
>>=20
>> - Unintentional unsigned wraparound (for example, in the argument to `ma=
lloc`) has been a known source of bugs for a long time. See for example [Re=
gehr2012] <https://www.cs.utah.edu/~regehr/papers/overflow12.pdf>, whose fi=
nal sentence is, "Our results also imply that tools for detecting integer n=
umerical errors need to distinguish intentional from unintentional uses of =
wraparound operations =E2=80=94 a challenging task =E2=80=94 in order to mi=
nimize false alarms. [emphasis added]" The current undefinedness of signed=
overflow permits implementations, such as UBSan, to detect all signed wrap=
around behavior as unintentional by definition, and diagnose it accordingly=
..
>=20
> unsigned wraparound isn=E2=80=99t UB, and I claim that signed overflow is=
UB because of the 3 representation, not to catch bugs, otherwise unsigned =
overflow would also have been UB. [...] I claim that this is also an emerge=
nt feature, not by design, caused by the 3 signed integer representations.
> =20
> I think you are right in the historical sense. These days the emergent "c=
atch bugs" rationale has survived, though, even as the exotic hardwares hav=
e died out.
Sure, I just think it=E2=80=99s unprincipled in where it=E2=80=99s applied =
because it=E2=80=99s only applied through historical accidents. That=E2=80=
=99s highly non-intuitive: "where can I catch bugs? Where there used to be =
hardware variance!=E2=80=9D How do we expect newcomers to learn C++? We can=
=E2=80=99t just say =E2=80=9CC++ offers a direct map to hardware=E2=80=9D, =
and =E2=80=9CC++ leaves no room for a language between itself and hardware=
=E2=80=9D, because in many cases it=E2=80=99s just not true. Two=E2=80=99s =
complement hardware just wraps signed integers.
I=E2=80=99d much rather have a principled approach, say a library integer w=
hich can wrap / trap / saturate / UB. There=E2=80=99s a proposal for satura=
tion, and I think the committee will take my paper and offer guidance on wh=
at a principled approach will be.
> FWIW UBSan supports unsigned overflow detection:
> -fsanitize=3Dunsigned-integer-overflow: Unsigned integer overflows. Note =
that unlike signed integer overflow, unsigned integer is not undefined beha=
vior. However, while it has well-defined semantics, it is often unintention=
al, so UBSan offers to catch it.
>=20
> This is very cool; I was unaware of this.
> Your paper would benefit from mentioning this. But the obvious comeback i=
s: where's the numbers on how many false positives UBSan generates in this =
mode? That number cannot possibly be zero.
>=20
> =20
>> - The impossibility of signed wraparound allows optimization of tight in=
ner loops such as
>> for (int i =3D a; i !=3D b; ++i)
>> Here the compiler is allowed to assume that `a <=3D b`, because if `b < =
a` the loop would eventually overflow and invoke undefined behavior.
>=20
> I claim that this is also an emergent feature, not by design, caused by t=
he 3 signed integer representations. I also claim that much of this perform=
ance can be regained with a better optimizer (the compiler I work on certai=
nly optimizes loops substantially without assuming UB on overflow). Further=
, the Internet shows that this optimization isn=E2=80=99t something develop=
ers knowingly opt into, and when they hit it they are surprised by the bugs=
it generates.
>=20
> Users never opt into bugs by definition. But users notice performance reg=
ressions (in the compiler) almost as quickly as they notice correctness reg=
ressions (in their own code).
File a bug if it=E2=80=99s slow. I sure do (or I go and fix the slowness).
>> This is intuitively the same behavior that we have with C++ iterators: t=
he compiler is allowed to assume that the existence of a loop over the rang=
e `a` to `b` implies that `b` is actually reachable from `a` according to f=
orward-increment semantics, even though in practice many implementations' s=
td::list::iterator internally performs the equivalent of "wrap on overflow.=
" (See the graphical diagram of "sentinel-node containers" in P0773 <http:/=
/www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0773r0.html#B> if needed=
..)
>> John McFarlane did a lightning talk about integer UB and codegen within =
the past year but I don't know if the slides are somewhere. I can ask him.
>=20
> The intuition is reversed, though: C came before C++ and iterators.
>=20
> Again, historically accurate but this is not modern C++'s problem. We don=
't teach C before C++. (And if we did, we might soon have to explain that i=
nteger overflow is undefined in C but not in C++? Add "C source-level compa=
tibility" to the list of rationales for preserving C's undefined overflow b=
ehavior in C++.)
C won=E2=80=99t be source-level incompatible because if you mix C and C++ t=
hen you=E2=80=99re using hardware which has two=E2=80=99s complement. I=E2=
=80=99m also in separate talks to bring this up with WG14.
>> I mean, it's not like there's any shortage of educational material on UB=
in C and C++ and its good and bad effects.
>=20
> Sure, do you believe there are particular references that should be read =
with my proposal?
>=20
> Off the top of my head, I recall John McFarlane's lightning talk on codeg=
en, Michael Spencer's "My Little Optimizer: Undefined Behavior Is Magic" ta=
lk, and pretty much anything involving John Regehr. I found the link to Reg=
ehr2012 as one of the top Google hits for "unintentional unsigned overflow=
=E2=80=9D.
All good references. I happen to have worked with Michael on the blog post =
that predates his talk (reference <https://youtu.be/g7entxbQOCc?t=3D38m11s>=
), and helped review his talk. Michael and John both provided input to my p=
aper before I published it (not to imply that they agree with all of the pa=
per!). I=E2=80=99d like you to trust that I=E2=80=99ve done my homework bef=
ore sending off the proposal. I purposefully kept the paper short-ish and o=
nly refer to standardese so that we can focus on what only allowing two=E2=
=80=99s complement means, and what I think we should do. I expect the commi=
ttee to be well versed in C++, and I also expect very different opinions on=
overflow behavior. I just don=E2=80=99t know where exactly consensus will =
fall, we=E2=80=99ll see.
>> What there is a shortage of IMHO is material on ones'-complement in C an=
d C++. That's why I kept large swaths of your paper intact in my fork. :)
> Might the lack of such documentation be caused by a lack of ones=E2=80=99=
complement hardware using modern C++?
>=20
> Yes, that's what I intended to imply here. :)
> Nobody teaches about the interaction of ones'-complement or sign-magnitud=
e with code-generators anymore because these don't happen in practice.
> People do teach about the interaction of undefined integer overflow with =
code-generators because this does happen in practice.
I=E2=80=99d rather teach that hardware wraps on signed overflow, just like =
unsigned, and unsurprisingly C++ does the same because it offers a pretty d=
irect mapping to hardware.
> Removing ones'-complement from C++ will be as painless (or painful) as re=
moving trigraphs was.
> Removing integer overflow from C++ will be as painful (or painless) as re=
moving type-based alias analysis would be.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/EF365199-C04A-4E49-9C5B-378184B319B8%40apple.com=
..
--Boundary_(ID_k7MA/lZX1QBqCAqufsqm7g)
Content-type: text/html; charset="UTF-8"
Content-transfer-encoding: quoted-printable
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; line-break: after-white-space;" class=3D""><br class=3D""><div><br cl=
ass=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Feb 23, 20=
18, at 16:34, Arthur O'Dwyer <<a href=3D"mailto:arthur.j.odwyer@gmail.co=
m" class=3D"">arthur.j.odwyer@gmail.com</a>> wrote:</div><br class=3D"Ap=
ple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">On Fri=
, Feb 23, 2018 at 3:07 PM, JF Bastien <span dir=3D"ltr" class=3D""><<a h=
ref=3D"mailto:jfbastien@apple.com" target=3D"_blank" class=3D"">jfbastien@a=
pple.com</a>></span> wrote:<br class=3D""><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-=
color:rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:break-word=
;line-break:after-white-space" class=3D"">On Feb 23, 2018, at 14:47, Arthur=
O'Dwyer <<a href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank"=
class=3D"">arthur.j.odwyer@gmail.com</a>> wrote:<div class=3D""><span c=
lass=3D"gmail-"><blockquote type=3D"cite" class=3D""><div class=3D""><div d=
ir=3D"ltr" class=3D"">On Fri, Feb 23, 2018 at 2:11 PM, JF Bastien <span dir=
=3D"ltr" class=3D""><<a href=3D"mailto:jfbastien@apple.com" target=3D"_b=
lank" class=3D"">jfbastien@apple.com</a>></span> wrote:<br class=3D""><d=
iv class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div s=
tyle=3D"word-wrap:break-word;line-break:after-white-space" class=3D"">Hi Ar=
thur,<div class=3D""><br class=3D""></div><div class=3D"">I=E2=80=99ll be i=
n JAX and will definitely champion my own approach, but will make sure any =
other approaches are discussed thoroughly. I=E2=80=99ll then ask for direct=
ion polls from EWG, and will follow the proposed direction in an updated pa=
per.</div></div></blockquote><div class=3D""><br class=3D""></div><div clas=
s=3D"">And if you manage to write the updated paper overnight and have it b=
ack on the table the next day at JAX, then my paper <i class=3D"">will</i> =
be utterly superfluous. :)</div><div class=3D""><br class=3D""></div><div c=
lass=3D"">I am, however, worried that the writing of a new paper might slip=
more than a day, which would end up with you coming back in the pre-Rapper=
swil mailing with another two's-complement paper after the perception that =
your first two's-complement paper was "rejected" in Jacksonville, which wou=
ld set a perceived negative precedent in people's minds.</div></div></div><=
/div></div></blockquote><div class=3D"">I=E2=80=99ve frequently presented u=
pdated papers after obtaining feedback: evenings are for paper writing.<br =
class=3D""></div></span></div></div></blockquote><br class=3D"">And if you =
manage to write the updated paper overnight and have it back on the table t=
he next day at JAX, then my paper will be utterly superfluous. :)<br class=
=3D""></div></div></div></div></blockquote><div><br class=3D""></div><div>W=
rite your paper if you want, I just don=E2=80=99t see a point to it. Editin=
g the paper is trivial, your paper just doesn=E2=80=99t help at all.</div><=
div><br class=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D"=
"><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left=
-color:rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:break-wor=
d;line-break:after-white-space" class=3D""><div class=3D""><span class=3D"g=
mail-"><blockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr=
" class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div cla=
ss=3D"">These are true, but then the current undefined behavior on signed o=
verflow has some unmentioned good effects, too:</div><div class=3D""><br cl=
ass=3D""></div><div class=3D"">- Unintentional unsigned wraparound (for exa=
mple, in the argument to `malloc`) has been a known source of bugs for a lo=
ng time. See for example <a href=3D"https://www.cs.utah.edu/~regehr/papers/=
overflow12.pdf" target=3D"_blank" class=3D"">[Regehr2012]</a>, whose final =
sentence is, "Our results also imply that tools for detecting integer numer=
ical errors need to <b class=3D""><i class=3D"">distinguish intentional fro=
m unintentional uses of wraparound operations</i></b> =E2=80=94 a challengi=
ng task =E2=80=94 in order to minimize false alarms. [emphasis added]" &nbs=
p;The current undefinedness of signed overflow permits implementations, suc=
h as UBSan, to detect all signed wraparound behavior as unintentional by de=
finition, and diagnose it accordingly.</div></div></div></div></div></block=
quote><div class=3D""><br class=3D""></div></span><div class=3D"">unsigned =
wraparound isn=E2=80=99t UB, and I claim that signed overflow is UB because=
of the 3 representation, not to catch bugs, otherwise unsigned overflow wo=
uld also have been UB. [...] I claim that this is also an emergent feature,=
not by design, caused by the 3 signed integer representations.</div></div>=
</div></blockquote><div class=3D""> </div><div class=3D"">I think you =
are right in the historical sense. These days the emergent "catch bugs" rat=
ionale has survived, though, even as the exotic hardwares have died out.</d=
iv></div></div></div></div></blockquote><div><br class=3D""></div><div>Sure=
, I just think it=E2=80=99s unprincipled in where it=E2=80=99s applied beca=
use it=E2=80=99s only applied through historical accidents. That=E2=80=99s =
highly non-intuitive: "where can I catch bugs? Where there used to be hardw=
are variance!=E2=80=9D How do we expect newcomers to learn C++? We can=E2=
=80=99t just say =E2=80=9CC++ offers a direct map to hardware=E2=80=9D, and=
=E2=80=9CC++ leaves no room for a language between itself and hardware=E2=
=80=9D, because in many cases it=E2=80=99s just not true. Two=E2=80=99s com=
plement hardware just wraps signed integers.</div><div><br class=3D""></div=
><div>I=E2=80=99d much rather have a principled approach, say a library int=
eger which can wrap / trap / saturate / UB. There=E2=80=99s a proposal for =
saturation, and I think the committee will take my paper and offer guidance=
on what a principled approach will be.</div><div><br class=3D""></div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D=
"ltr" class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);paddi=
ng-left:1ex"><div style=3D"word-wrap:break-word;line-break:after-white-spac=
e" class=3D""><div class=3D""><div class=3D""></div><div class=3D"">FWIW UB=
San supports unsigned overflow detection:</div></div><blockquote style=3D"m=
argin:0px 0px 0px 40px;border:none;padding:0px" class=3D""><div class=3D"">=
<div class=3D""><div class=3D"">-fsanitize=3Dunsigned-integer-<wbr class=3D=
"">overflow: Unsigned integer overflows. Note that unlike signed integer ov=
erflow, unsigned integer is not undefined behavior. However, while it has w=
ell-defined semantics, it is often unintentional, so UBSan offers to c=
atch it.</div></div></div></blockquote></div></blockquote><div class=3D""><=
br class=3D""></div><div class=3D"">This is very cool; I was unaware of thi=
s.</div><div class=3D"">Your paper would benefit from mentioning this. But =
the obvious comeback is: where's the numbers on how many false positives UB=
San generates in this mode? That number cannot possibly be zero.</div><div =
class=3D""><br class=3D""></div><div class=3D""> </div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;=
border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex=
"><div style=3D"word-wrap:break-word;line-break:after-white-space" class=3D=
""><div class=3D""><span class=3D"gmail-"><blockquote type=3D"cite" class=
=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><div class=3D"">- The impossibility of signed =
wraparound allows optimization of tight inner loops such as</div><div class=
=3D""> for (int i =3D a; i !=3D b; ++i)</div><div class=3D"">H=
ere the compiler is allowed to assume that `a <=3D b`, because if `b <=
; a` the loop would eventually overflow and invoke undefined behavior.</div=
></div></div></div></div></blockquote></span><div class=3D"">I claim that t=
his is also an emergent feature, not by design, caused by the 3 signed inte=
ger representations. I also claim that much of this performance can be rega=
ined with a better optimizer (the compiler I work on certainly optimizes lo=
ops substantially without assuming UB on overflow). Further, the Internet s=
hows that this optimization isn=E2=80=99t something developers knowingly op=
t into, and when they hit it they are surprised by the bugs it generates.</=
div></div></div></blockquote><div class=3D""><br class=3D""></div><div clas=
s=3D"">Users never opt into bugs by definition. But users notice performanc=
e regressions (in the <i class=3D"">compiler</i>) almost as quickly as they=
notice correctness regressions (in <i class=3D"">their own code</i>).</div=
></div></div></div></div></blockquote><div><br class=3D""></div><div>File a=
bug if it=E2=80=99s slow. I sure do (or I go and fix the slowness).</div><=
div><br class=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D"=
"><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left=
-color:rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:break-wor=
d;line-break:after-white-space" class=3D""><div class=3D""><span class=3D"g=
mail-"><blockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr=
" class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div cla=
ss=3D"">This is intuitively the same behavior that we have with C++ iterato=
rs: the compiler is allowed to assume that the existence of a loop over the=
range `a` to `b` implies that `b` is actually reachable from `a` according=
to forward-increment semantics, even though in practice many implementatio=
ns' std::list::iterator internally performs the equivalent of "wrap on over=
flow." (See the graphical diagram of "sentinel-node containers" in <a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0773r0.html#B"=
target=3D"_blank" class=3D"">P0773</a> if needed.)</div><div class=3D"">Jo=
hn McFarlane did a lightning talk about integer UB and codegen within the p=
ast year but I don't know if the slides are somewhere. I can ask him.</div>=
</div></div></div></div></blockquote></span><div class=3D"">The intuition i=
s reversed, though: C came before C++ and iterators.</div></div></div></blo=
ckquote><div class=3D""><br class=3D""></div><div class=3D"">Again, histori=
cally accurate but this is not modern C++'s problem. We don't teach C befor=
e C++. (And if we did, we might soon have to explain that integer overflow =
is undefined in C but not in C++? Add "C source-level compatibility" to the=
list of rationales for preserving C's undefined overflow behavior in C++.)=
</div></div></div></div></div></blockquote><div><br class=3D""></div><div>C=
won=E2=80=99t be source-level incompatible because if you mix C and C++ th=
en you=E2=80=99re using hardware which has two=E2=80=99s complement. I=E2=
=80=99m also in separate talks to bring this up with WG14.</div><div><br cl=
ass=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D""><div dir=
=3D"ltr" class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa=
dding-left:1ex"><div style=3D"word-wrap:break-word;line-break:after-white-s=
pace" class=3D""><div class=3D""><span class=3D"gmail-"><blockquote type=3D=
"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><div class=3D"">I mean, it's not l=
ike there's any shortage of educational material on UB in C and C++ and its=
<b class=3D""><i class=3D"">good and</i></b> bad effects.</div></div></div=
></div></div></blockquote><div class=3D""><br class=3D""></div></span><div =
class=3D"">Sure, do you believe there are particular references that should=
be read with my proposal?</div></div></div></blockquote><div class=3D""><b=
r class=3D""></div><div class=3D"">Off the top of my head, I recall John Mc=
Farlane's lightning talk on codegen, Michael Spencer's "My Little Optimizer=
: Undefined Behavior Is Magic" talk, and pretty much anything involving Joh=
n Regehr. I found the link to Regehr2012 as one of the top Google hits for =
"unintentional unsigned overflow=E2=80=9D.</div></div></div></div></blockqu=
ote><div><br class=3D""></div><div>All good references. I happen to have wo=
rked with Michael on the blog post that predates his talk (<a href=3D"https=
://youtu.be/g7entxbQOCc?t=3D38m11s" class=3D"">reference</a>), and helped r=
eview his talk. Michael and John both provided input to my paper before I p=
ublished it (not to imply that they agree with all of the paper!). I=E2=80=
=99d like you to trust that I=E2=80=99ve done my homework before sending of=
f the proposal. I purposefully kept the paper short-ish and only refer to s=
tandardese so that we can focus on what only allowing two=E2=80=99s complem=
ent means, and what I think we should do. I expect the committee to be well=
versed in C++, and I also expect very different opinions on overflow behav=
ior. I just don=E2=80=99t know where exactly consensus will fall, we=E2=80=
=99ll see.</div><div><br class=3D""></div><br class=3D""><blockquote type=
=3D"cite" class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-l=
eft-color:rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:break-=
word;line-break:after-white-space" class=3D""><div class=3D""><span class=
=3D"gmail-"><blockquote type=3D"cite" class=3D""><div class=3D""><div dir=
=3D"ltr" class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
div class=3D"">What there <i class=3D"">is</i> a shortage of IMHO is materi=
al on <i class=3D""><b class=3D"">ones'-complement</b></i> in C and C++. Th=
at's why I kept large swaths of your paper intact in my fork. :)</div></div=
></div></div></div></blockquote><div class=3D"">Might the lack of such docu=
mentation be caused by a lack of ones=E2=80=99 complement hardware using mo=
dern C++?<br class=3D""></div></span></div></div></blockquote><div class=3D=
""><br class=3D""></div><div class=3D"">Yes, that's what I intended to impl=
y here. :)</div><div class=3D"">Nobody teaches about the interaction of one=
s'-complement or sign-magnitude with code-generators anymore because these =
don't happen in practice.</div><div class=3D"">People do teach about the in=
teraction of undefined integer overflow with code-generators because this <=
i class=3D"">does</i> happen in practice.</div></div></div></div></blockquo=
te><div><br class=3D""></div><div>I=E2=80=99d rather teach that hardware wr=
aps on signed overflow, just like unsigned, and unsurprisingly C++ does the=
same because it offers a pretty direct mapping to hardware.</div><div><br =
class=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D""><div d=
ir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><div class=3D"">Removing ones'-complement from C++ will be as painless (or=
painful) as removing trigraphs was.</div><div class=3D"">Removing integer =
overflow from C++ will be as painful (or painless) as removing type-based a=
lias analysis would be.</div></div></div></div></blockquote></div><br class=
=3D""><br class=3D""></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/EF365199-C04A-4E49-9C5B-378184B319B8%=
40apple.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/EF365199-C04A-4E49-9C5B-378184B319B8%=
40apple.com</a>.<br />
--Boundary_(ID_k7MA/lZX1QBqCAqufsqm7g)--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 26 Feb 2018 11:50:05 -0600
Raw View
--94eb2c19134e4d279c05662126c9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, Feb 26, 2018 at 11:16 AM, JF Bastien <jfbastien@apple.com> wrote:
>
> I=E2=80=99ve asked Chandler but I=E2=80=99ll ask you as well: data would =
be great in
> getting committee consensus. To me =E2=80=9Cfalse positive=E2=80=9D sound=
s an awful lot
> like =E2=80=9Cnot a bug=E2=80=9D in this context :-)
>
I don't understand this line of reasoning. If you consider *unsigned*
wrapping detection to be a good thing in the sanitizer (I assume that is
what you mean by "not a bug"), why on earth do you want *signed* overflow
to wrap? Do you expect sanitizers to detect this? If so, why make it
legitimate behavior?
Without wrapping, I don't see enough motivation to change the status quo,
especially since it needlessly introduces an incompatibility with C. And I
certainly don't see how this is in the "top 20" things for C++20.
IMO, if the sanitizers are giving false positives, they should remove the
misleading bit about no false positives as a goal in the documentation <
https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#issue-suppressi=
on
>.
--=20
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAGg_6%2BOp%3DC0FtNeJ4MY7NTKZBiYP76U-HCyp3%3DGYh=
Yf11HHtvQ%40mail.gmail.com.
--94eb2c19134e4d279c05662126c9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Feb 26, 2018 at 11:16 AM, JF Bastien <span dir=3D"=
ltr"><<a href=3D"mailto:jfbastien@apple.com" target=3D"_blank">jfbastien=
@apple.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:break-word;line-b=
reak:after-white-space"><br><div><div>I=E2=80=99ve asked Chandler but I=E2=
=80=99ll ask you as well: data would be great in getting committee consensu=
s. To me =E2=80=9Cfalse positive=E2=80=9D sounds an awful lot like =E2=80=
=9Cnot a bug=E2=80=9D in this context :-)</div></div></div></blockquote><di=
v><br></div><div>I don't understand this line of reasoning.=C2=A0 If yo=
u consider <i>unsigned</i> wrapping detection to be a good thing in the san=
itizer (I assume that is what you mean by "not a bug"), why on ea=
rth do you want <i>signed</i> overflow to wrap?=C2=A0 Do you expect sanitiz=
ers to detect this?=C2=A0 If so, why make it legitimate behavior?</div><div=
><br></div><div>Without wrapping, I don't see enough motivation to chan=
ge the status quo, especially since it needlessly introduces an incompatibi=
lity with C.=C2=A0 And I certainly don't see how this is in the "t=
op 20" things for C++20.</div><div><br></div><div><br></div><div>IMO, =
if the sanitizers are giving false positives, they should remove the mislea=
ding bit about no false positives as a goal in the documentation <<a hre=
f=3D"https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#issue-supp=
ression">https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#issue-=
suppression</a>>.</div></div>-- <br><div class=3D"gmail_signature"><div =
dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=
=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">=
nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1404</div></div></div></div=
></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOp%3DC0FtNeJ4MY7NTKZBiYP76U-=
HCyp3%3DGYhYf11HHtvQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOp=
%3DC0FtNeJ4MY7NTKZBiYP76U-HCyp3%3DGYhYf11HHtvQ%40mail.gmail.com</a>.<br />
--94eb2c19134e4d279c05662126c9--
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Mon, 26 Feb 2018 18:46:04 +0000
Raw View
--001a11439844c10452056621ec0d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, Feb 26, 2018 at 12:50 PM Nevin Liber <nevin@eviloverlord.com> wrote=
:
> On Mon, Feb 26, 2018 at 11:16 AM, JF Bastien <jfbastien@apple.com> wrote:
>
>>
>> I=E2=80=99ve asked Chandler but I=E2=80=99ll ask you as well: data would=
be great in
>> getting committee consensus. To me =E2=80=9Cfalse positive=E2=80=9D soun=
ds an awful lot
>> like =E2=80=9Cnot a bug=E2=80=9D in this context :-)
>>
>
> I don't understand this line of reasoning. If you consider *unsigned*
> wrapping detection to be a good thing in the sanitizer (I assume that is
> what you mean by "not a bug"), why on earth do you want *signed* overflow
> to wrap? Do you expect sanitizers to detect this? If so, why make it
> legitimate behavior?
>
Agreed. Simultaneously saying "signed arithmetic wraps" and encouraging
sanitizers to check for overflow is contradictory. Defining the behavior is
a statement that users can rely on that behavior (otherwise why would you
standardize it at all?). Having a sanitizer then check to make sure that
people aren't overflowing means that people shouldn't rely on it, otherwise
what you get is a sanitizer that has false positives, giving incentive for
people to *not* use it. The end state that you are left with is fewer
people using the sanitizer (leaving bugs latent) while also preventing
optimizations. What exactly is the point, here?
I do not see how this is at all a good direction for the standard. If you
want signed arithmetic to wrap on your implementation, then that is
something you can request from your compiler. I'm all for introducing new
functions for a wrapping add or something along those lines, but trying to
make + wrap, especially with encouragement for sanitizers to still check
for overflow, seems like all negatives to me.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CANh8DEm%2Bf07nSuXG8kPLFFw_rz9HheBgFecb5Vif2cG76=
NH_fw%40mail.gmail.com.
--001a11439844c10452056621ec0d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Fe=
b 26, 2018 at 12:50 PM Nevin Liber <<a href=3D"mailto:nevin@eviloverlord=
..com">nevin@eviloverlord.com</a>> wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr">On Mon, Feb 26, 2018 at 11:16 AM, JF Bastien <spa=
n dir=3D"ltr"><<a href=3D"mailto:jfbastien@apple.com" target=3D"_blank">=
jfbastien@apple.com</a>></span> wrote:<br><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-=
color:rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:break-word=
;line-break:after-white-space"><br><div><div>I=E2=80=99ve asked Chandler bu=
t I=E2=80=99ll ask you as well: data would be great in getting committee co=
nsensus. To me =E2=80=9Cfalse positive=E2=80=9D sounds an awful lot like =
=E2=80=9Cnot a bug=E2=80=9D in this context :-)</div></div></div></blockquo=
te><div><br></div><div>I don't understand this line of reasoning.=C2=A0=
If you consider <i>unsigned</i> wrapping detection to be a good thing in t=
he sanitizer (I assume that is what you mean by "not a bug"), why=
on earth do you want <i>signed</i> overflow to wrap?=C2=A0 Do you expect s=
anitizers to detect this?=C2=A0 If so, why make it legitimate behavior?</di=
v></div></div></div></blockquote><div><br></div><div>Agreed. Simultaneously=
saying "signed arithmetic wraps" and encouraging sanitizers to c=
heck for overflow is contradictory. Defining the behavior is a statement th=
at users can rely on that behavior (otherwise why would you standardize it =
at all?). Having a sanitizer then check to make sure that people aren't=
overflowing means that people shouldn't rely on it, otherwise what you=
get is a sanitizer that has false positives, giving incentive for people t=
o <i>not</i> use it. The end state that you are left with is fewer people u=
sing the sanitizer (leaving bugs latent) while also preventing optimization=
s. What exactly is the point, here?</div><div><br></div><div>I do not see h=
ow this is at all a good direction for the standard. If you want signed ari=
thmetic to wrap on your implementation, then that is something you can requ=
est from your compiler. I'm all for introducing new functions for a wra=
pping add or something along those lines, but trying to make + wrap, especi=
ally with encouragement for sanitizers to still check for overflow, seems l=
ike all negatives to me.</div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEm%2Bf07nSuXG8kPLFFw_rz9HheBgFe=
cb5Vif2cG76NH_fw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEm%2Bf07n=
SuXG8kPLFFw_rz9HheBgFecb5Vif2cG76NH_fw%40mail.gmail.com</a>.<br />
--001a11439844c10452056621ec0d--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Mon, 26 Feb 2018 22:03:53 +0300
Raw View
On 02/26/18 20:50, Nevin Liber wrote:
> On Mon, Feb 26, 2018 at 11:16 AM, JF Bastien <jfbastien@apple.com=20
> <mailto:jfbastien@apple.com>> wrote:
>=20
> Without wrapping, I don't see enough motivation to change the status=20
> quo, especially since it needlessly introduces an incompatibility with=20
> C.=C2=A0 And I certainly don't see how this is in the "top 20" things for=
C++20.
Having two's complement signed in the standard is worth it even without=20
well defined overflow semantics. Just the guaranteed ability to cast=20
from unsigned to signed without UB alone makes it worth it. Currently,=20
there simply isn't a way to cast from unsigned to signed portably and=20
fail-safe. The whole "let's use signed integers everywhere" incentive=20
exists because of this (and therefore is misguided, IMHO).
Personally, I want the language to provide tools with well defined=20
overflow semantics as well. These may not be the current signed integer=20
types, but certainly they should be types with overloaded arithmetic=20
operators (free functions and such are just too verbose for no reason).
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/faae0903-eb2a-f8ef-fe11-f0477a302693%40gmail.com=
..
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 26 Feb 2018 13:27:25 -0600
Raw View
--089e08240ef85fffad0566228257
Content-Type: text/plain; charset="UTF-8"
On Mon, Feb 26, 2018 at 1:03 PM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:
> Having two's complement signed in the standard is worth it even without
> well defined overflow semantics. Just the guaranteed ability to cast from
> unsigned to signed without UB alone makes it worth it. Currently, there
> simply isn't a way to cast from unsigned to signed portably and fail-safe.
But we can add functions to perform that.
Either the bar for breaking C compatibility should be high, or we should
deliberately decide that C compatibility is not longer a goal of C++. This
paper doesn't fit into either of those categories.
> The whole "let's use signed integers everywhere" incentive exists because
> of this (and therefore is misguided, IMHO).
>
There are a bunch of reasons for it, a few of which have been mentioned in
this thread (sanitizers, optimization, etc.).
> Personally, I want the language to provide tools with well defined
> overflow semantics as well. These may not be the current signed integer
> types, but certainly they should be types with overloaded arithmetic
> operators (free functions and such are just too verbose for no reason).
I'd probably support such a proposal, as it meets my criterion that it
indicates when one deliberately wants the overflow semantics vs.
accidentally depending on the overflow semantics (which is what we would
get if we adopted the paper w/o any changes). (Of course, some people will
use it everywhere, but that is an education problem.)
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
<(847)%20691-1404>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPMO1UW59SJ-XT_iM_xt1bqGbVjWmvH0R2Gi%3Do6cmJyTw%40mail.gmail.com.
--089e08240ef85fffad0566228257
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Feb 26, 2018 at 1:03 PM, Andrey Semashev <span dir=
=3D"ltr"><<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank"=
>andrey.semashev@gmail.com</a>></span> wrote:<br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Having two=
9;s complement signed in the standard is worth it even without well defined=
overflow semantics. Just the guaranteed ability to cast from unsigned to s=
igned without UB alone makes it worth it. Currently, there simply isn't=
a way to cast from unsigned to signed portably and fail-safe. </blockquote=
><div><br></div><div>But we can add functions to perform that.</div><div><b=
r></div><div><br></div><div>Either the bar for breaking C compatibility sho=
uld be high, or we should deliberately decide that C compatibility is not l=
onger a goal of C++.=C2=A0 This paper doesn't fit into either of those =
categories.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The whol=
e "let's use signed integers everywhere" incentive exists bec=
ause of this (and therefore is misguided, IMHO).<br></blockquote><div><br><=
/div><div>There are a bunch of reasons for it, a few of which have been men=
tioned in this thread (sanitizers, optimization, etc.).</div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">Personally, I want the language to provid=
e tools with well defined overflow semantics as well. These may not be the =
current signed integer types, but certainly they should be types with overl=
oaded arithmetic operators (free functions and such are just too verbose fo=
r no reason).</blockquote><div><br></div><div>I'd probably support such=
a proposal, as it meets my criterion that it indicates when one deliberate=
ly wants the overflow semantics vs. accidentally depending on the overflow =
semantics (which is what we would get if we adopted the paper w/o any chang=
es). =C2=A0(Of course, some people will use it everywhere, but that is an e=
ducation problem.)</div></div>-- <br><div class=3D"m_-7948489801512446943gm=
ail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><di=
v dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a hr=
ef=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.c=
om</a><wbr>> =C2=A0<a href=3D"tel:(847)%20691-1404" value=3D"+1847691140=
4" target=3D"_blank">+1-847-691-1404</a></div></div></div></div></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPMO1UW59SJ-XT_iM_xt1bqGbVjWm=
vH0R2Gi%3Do6cmJyTw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BPMO1=
UW59SJ-XT_iM_xt1bqGbVjWmvH0R2Gi%3Do6cmJyTw%40mail.gmail.com</a>.<br />
--089e08240ef85fffad0566228257--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 26 Feb 2018 13:34:07 -0600
Raw View
--001a1146919652d7480566229a4f
Content-Type: text/plain; charset="UTF-8"
On Mon, Feb 26, 2018 at 12:46 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
>
> Having a sanitizer then check to make sure that people aren't overflowing
> means that people shouldn't rely on it, otherwise what you get is a
> sanitizer that has false positives, giving incentive for people to *not*
> use it. The end state that you are left with is fewer people using the
> sanitizer (leaving bugs latent) while also preventing optimizations. What
> exactly is the point, here?
>
Yup. My fear is that, like compiler warnings, it migrates to becoming a
style enforcer rather than a problem finder. We jump through hoops to get
our code to compile without warnings, which ranges from painful to nearly
impossible if you use multiple compilers (just ask the Boost folks). But
that is an issue for SG15, not std-proposals...
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNOtR8p-QKid7%2Bru07TDz2%2B5YiCDhAe-M%2BWQzOy_APmxg%40mail.gmail.com.
--001a1146919652d7480566229a4f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Feb 26, 2018 at 12:46 PM, 'Matt Calabrese'=
via ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"m=
ailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org<=
/a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail=
_quote"><span class=3D""><div dir=3D"ltr">=C2=A0Having a sanitizer then che=
ck to make sure that people aren't overflowing means that people should=
n't rely on it, otherwise what you get is a sanitizer that has false po=
sitives, giving incentive for people to <i>not</i> use it. The end state th=
at you are left with is fewer people using the sanitizer (leaving bugs late=
nt) while also preventing optimizations. What exactly is the point, here?<b=
r></div></span></div></div></blockquote><div><br></div><div>Yup.=C2=A0 My f=
ear is that, like compiler warnings, it migrates to becoming a style enforc=
er rather than a problem finder.=C2=A0 We jump through hoops to get our cod=
e to compile without warnings, which ranges from painful to nearly impossib=
le if you use multiple compilers (just ask the Boost folks).=C2=A0 But that=
is an issue for SG15, not std-proposals...</div></div>-- <br><div class=3D=
"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>=
<div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a=
href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlor=
d.com</a>> =C2=A0+1-847-691-1404</div></div></div></div></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNOtR8p-QKid7%2Bru07TDz2%2B5Y=
iCDhAe-M%2BWQzOy_APmxg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2B=
NOtR8p-QKid7%2Bru07TDz2%2B5YiCDhAe-M%2BWQzOy_APmxg%40mail.gmail.com</a>.<br=
/>
--001a1146919652d7480566229a4f--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Mon, 26 Feb 2018 22:40:44 +0300
Raw View
On 02/26/18 22:27, Nevin Liber wrote:
> On Mon, Feb 26, 2018 at 1:03 PM, Andrey Semashev
> <andrey.semashev@gmail.com <mailto:andrey.semashev@gmail.com>> wrote:
>
> Having two's complement signed in the standard is worth it even
> without well defined overflow semantics. Just the guaranteed ability
> to cast from unsigned to signed without UB alone makes it worth it.
> Currently, there simply isn't a way to cast from unsigned to signed
> portably and fail-safe.
>
>
> But we can add functions to perform that.
I don't see how such a function could be fail-safe and portable (that
is, produce the same result regardless of the signed integer
representation) because different representations don't have equivalent
ranges of values.
Further, why should it be a dedicated function when we have static_cast?
What would be the use case to use the old and unreliable static_cast and
not just always use this conversion function? Also, a special function
is difficult to use in generic code and cannot be used when the cast is
implicit (which, presumably, would still be unreliable).
No, IMHO this problem needs to be solved in its source, which is
incompatibility between signed and unsigned integers.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5a33b1cc-a041-ef97-bbe8-5286d7ee9cad%40gmail.com.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 26 Feb 2018 13:51:37 -0600
Raw View
--001a114e5fdaeb371e056622d8b4
Content-Type: text/plain; charset="UTF-8"
On Mon, Feb 26, 2018 at 1:40 PM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:
> I don't see how such a function could be fail-safe and portable (that is,
> produce the same result regardless of the signed integer representation)
> because different representations don't have equivalent ranges of values.
>
If it doesn't exist, you can't do it portably. Seems that would be easier
to pass than being incompatible with C just to support this.
> Further, why should it be a dedicated function when we have static_cast?
I want the function anyway. casting is a many-to-one operation, which
makes it error-prone and clunky to use:
static_cast<make_signed_t<type>>(i)
is less preferable to something like
convert_to_unsigned(i)
No, IMHO this problem needs to be solved in its source, which is
> incompatibility between signed and unsigned integers.
They have different ranges of valid values, so you cannot "make them
compatible" without making some set of users unhappy.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
<(847)%20691-1404>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMo43OqqdnQ3aRxpwvhdUwKZLLASjsU_d1u6D4BbALomA%40mail.gmail.com.
--001a114e5fdaeb371e056622d8b4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Feb 26, 2018 at 1:40 PM, Andrey Semashev <span dir=
=3D"ltr"><<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank"=
>andrey.semashev@gmail.com</a>></span> wrote:<br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't s=
ee how such a function could be fail-safe and portable (that is, produce th=
e same result regardless of the signed integer representation) because diff=
erent representations don't have equivalent ranges of values.<br></bloc=
kquote><div><br></div><div>If it doesn't exist, you can't do it por=
tably.=C2=A0 Seems that would be easier to pass than being incompatible wit=
h C just to support this.</div><div>=C2=A0</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">Further, why should it be a dedicated function when we=
have static_cast?</blockquote><div><br></div><div>I want the function anyw=
ay. =C2=A0casting is a many-to-one operation, which makes it error-prone an=
d clunky to use:</div><div><br></div><div>static_cast<make_signed_t<<=
wbr>type>>(i)</div><div><br></div><div>is less preferable to somethin=
g like</div><div><br></div><div>convert_to_unsigned(i)</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">No, IMHO this problem needs to be solved in =
its source, which is incompatibility between signed and unsigned integers.<=
/blockquote><div><br></div><div>They have different ranges of valid values,=
so you cannot "make them compatible" without making some set of =
users unhappy.</div></div>-- <br><div class=3D"m_-8671639344723920679gmail_=
signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div di=
r=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a><wbr>> =C2=A0<a href=3D"tel:(847)%20691-1404" value=3D"+18476911404"=
target=3D"_blank">+1-847-691-1404</a></div></div></div></div></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMo43OqqdnQ3aRxpwvhdUwKZLLASj=
sU_d1u6D4BbALomA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMo43Oq=
qdnQ3aRxpwvhdUwKZLLASjsU_d1u6D4BbALomA%40mail.gmail.com</a>.<br />
--001a114e5fdaeb371e056622d8b4--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Mon, 26 Feb 2018 12:20:09 -0800
Raw View
--001a114f41809a17c30566233c48
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
@Andrey: Agreed, I'd like to define the conversion behavior of
int(0xFFFFFFFF).
@Matt: Agreed, building "wrap on overflow" into operator+ seems like a bad
idea. I mean, it's a great idea if you know that wrapping is the behavior
you want and you're relying on wrapping =E2=80=94 but it's a terrible idea =
if
you're not even thinking about the possibility of overflow and suddenly
your code starts doing the wrong thing (wrapping on overflow) and you can't
figure out why or where because there's no way to distinguish "intentional"
wrapping from "accidental" wrapping.
The distinction here is that integral conversions, truncations, and bitwise
operations & | ^ ~ << >> depend fundamentally on the representation of
signed integers, which in practice is always two's-complement. The numeric
arithmetic operations + - * / % do not fundamentally depend on
*representation*; they depend on some other property of the mapping from
the mathematical number line onto a C++ data type.
I have tried to reflect this theory a little better in the latest draft of
my "conservative" paper:
https://quuxplusone.github.io/draft/twosc-conservative.html
Also in my latest draft, I've added two tables. Table 1 shows C++
expressions with their current behavior, the behavior that would be
mandated under my revised proposal, and the name of the WD section with the
relevant wording. Table 2 shows some more C++ expressions which also
currently have undefined behavior, and which would continue to have
undefined behavior after my proposal. My understanding is that JF's
proposal =E2=80=94 which, again, is the one that will be shown to EWG =E2=
=80=94 would
mandate defined behavior for the first two examples in Table 2.
=E2=80=93Arthur
On Mon, Feb 26, 2018 at 11:03 AM, Andrey Semashev <andrey.semashev@gmail.co=
m
> wrote:
> On 02/26/18 20:50, Nevin Liber wrote:
>
>> On Mon, Feb 26, 2018 at 11:16 AM, JF Bastien <jfbastien@apple.com
>> <mailto:jfbastien@apple.com>> wrote:
>>
>> Without wrapping, I don't see enough motivation to change the status quo=
,
>> especially since it needlessly introduces an incompatibility with C. An=
d I
>> certainly don't see how this is in the "top 20" things for C++20.
>>
>
> Having two's complement signed in the standard is worth it even without
> well defined overflow semantics. Just the guaranteed ability to cast from
> unsigned to signed without UB alone makes it worth it. Currently, there
> simply isn't a way to cast from unsigned to signed portably and fail-safe=
..
> The whole "let's use signed integers everywhere" incentive exists because
> of this (and therefore is misguided, IMHO).
>
> Personally, I want the language to provide tools with well defined
> overflow semantics as well. These may not be the current signed integer
> types, but certainly they should be types with overloaded arithmetic
> operators (free functions and such are just too verbose for no reason).
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/is
> ocpp.org/d/topic/std-proposals/MZzCyAL1qRo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/faae0903-eb2a-f8ef-fe11-
> f0477a302693%40gmail.com.
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0JOUimwTL9idWRtTwBTj4rwe_Oq-NFmvR%2BVbN06o=
oFo0w%40mail.gmail.com.
--001a114f41809a17c30566233c48
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">@Andrey: Agreed, I'd like to define the conversion beh=
avior of int(0xFFFFFFFF).<div>@Matt: Agreed, building "wrap on overflo=
w" into operator+ seems like a bad idea. I mean, it's a great idea=
if you know that wrapping is the behavior you want and you're relying =
on wrapping =E2=80=94 but it's a terrible idea if you're not even t=
hinking about the possibility of overflow and suddenly your code starts doi=
ng the wrong thing (wrapping on overflow) and you can't figure out why =
or where because there's no way to distinguish "intentional" =
wrapping from "accidental" wrapping.<br><div><br></div><div>The d=
istinction here is that integral conversions, truncations, and bitwise oper=
ations & | ^ ~ << >> depend fundamentally on the representa=
tion of signed integers, which in practice is always two's-complement.=
=C2=A0 The numeric arithmetic operations + - * / % do not fundamentally dep=
end on <i>representation</i>; they depend on some other property of the map=
ping from the mathematical number line onto a C++ data type.</div><div>I ha=
ve tried to reflect this theory a little better in the latest draft of my &=
quot;conservative" paper: <a href=3D"https://quuxplusone.github.io/dra=
ft/twosc-conservative.html">https://quuxplusone.github.io/draft/twosc-conse=
rvative.html</a></div><div><br></div></div><div>Also in my latest draft, I&=
#39;ve added two tables. Table 1 shows C++ expressions with their current b=
ehavior, the behavior that would be mandated under my revised proposal, and=
the name of the WD section with the relevant wording.=C2=A0 Table 2 shows =
some more C++ expressions which also currently have undefined behavior, and=
which would continue to have undefined behavior after my proposal.=C2=A0 M=
y understanding is that JF's proposal =E2=80=94 which, again, is the on=
e that will be shown to EWG =E2=80=94 would mandate defined behavior for th=
e first two examples in Table 2.</div><div><br></div><div>=E2=80=93Arthur</=
div><div><br></div><div><br></div></div><div class=3D"gmail_extra"><br><div=
class=3D"gmail_quote">On Mon, Feb 26, 2018 at 11:03 AM, Andrey Semashev <s=
pan dir=3D"ltr"><<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"=
_blank">andrey.semashev@gmail.com</a>></span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">On 02/26/18 20:50, Nevin Liber wrote:<span class=3D""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Mon, Feb 26, 2018 at 11:16 AM, JF Bastien <<a href=3D"mailto:jfbastie=
n@apple.com" target=3D"_blank">jfbastien@apple.com</a> <mailto:<a href=
=3D"mailto:jfbastien@apple.com" target=3D"_blank">jfbastien@apple.com</a>&g=
t;> wrote:<br>
<br>
Without wrapping, I don't see enough motivation to change the status qu=
o, especially since it needlessly introduces an incompatibility with C.=C2=
=A0 And I certainly don't see how this is in the "top 20" thi=
ngs for C++20.<br>
</blockquote>
<br></span>
Having two's complement signed in the standard is worth it even without=
well defined overflow semantics. Just the guaranteed ability to cast from =
unsigned to signed without UB alone makes it worth it. Currently, there sim=
ply isn't a way to cast from unsigned to signed portably and fail-safe.=
The whole "let's use signed integers everywhere" incentive e=
xists because of this (and therefore is misguided, IMHO).<br>
<br>
Personally, I want the language to provide tools with well defined overflow=
semantics as well. These may not be the current signed integer types, but =
certainly they should be types with overloaded arithmetic operators (free f=
unctions and such are just too verbose for no reason).<span class=3D""><br>
<br>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/MZzCyAL1qRo/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/topic/s=
td-proposals<wbr>/MZzCyAL1qRo/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/faae0903-eb2a-f8ef-fe11-f0477a302693%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/faae0903-eb2a-f8ef-fe11-<wbr>=
f0477a302693%40gmail.com</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0JOUimwTL9idWRtTwBTj4rwe_Oq-NFm=
vR%2BVbN06ooFo0w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0JOUimwTL=
9idWRtTwBTj4rwe_Oq-NFmvR%2BVbN06ooFo0w%40mail.gmail.com</a>.<br />
--001a114f41809a17c30566233c48--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Mon, 26 Feb 2018 23:22:02 +0300
Raw View
On 02/26/18 22:51, Nevin Liber wrote:
> On Mon, Feb 26, 2018 at 1:40 PM, Andrey Semashev=20
> <andrey.semashev@gmail.com <mailto:andrey.semashev@gmail.com>> wrote:
>=20
> I don't see how such a function could be fail-safe and portable
> (that is, produce the same result regardless of the signed integer
> representation) because different representations don't have
> equivalent ranges of values.
>=20
> If it doesn't exist, you can't do it portably.=C2=A0 Seems that would be=
=20
> easier to pass than being incompatible with C just to support this.
Given that two's complement is ubiquitous, I don't think this=20
incompatibility will have much significance. And who knows, maybe C will=20
follow.
> Further, why should it be a dedicated function when we have static_ca=
st?
>=20
> I want the function anyway. =C2=A0casting is a many-to-one operation, whi=
ch=20
> makes it error-prone and clunky to use:
>=20
> static_cast<make_signed_t<type>>(i)
>=20
> is less preferable to something like
>=20
> convert_to_unsigned(i)
Again, this doesn't work with implicit casts.
> No, IMHO this problem needs to be solved in its source, which is
> incompatibility between signed and unsigned integers.
>=20
> They have different ranges of valid values, so you cannot "make them=20
> compatible" without making some set of users unhappy.
They can be made compatible in the sense of casts preserving bitwise=20
value. For that to be portable, signed representation has to be fixed.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/27759c7c-b47d-20e8-beb1-37a85d99e928%40gmail.com=
..
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 26 Feb 2018 15:03:54 -0800
Raw View
On segunda-feira, 26 de fevereiro de 2018 11:03:53 PST Andrey Semashev wrote:
> Just the guaranteed ability to cast
> from unsigned to signed without UB alone makes it worth it.
That's never been UB. But it is IB:
http://eel.is/c++draft/conv.integral#3
"If the destination type is signed, the value is unchanged if it can be
represented in the destination type; otherwise, the value is implementation-
defined."
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3792531.hUIyXVzBxz%40tjmaciei-mobl1.
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Mon, 26 Feb 2018 15:05:20 -0800 (PST)
Raw View
------=_Part_15176_550944315.1519686320454
Content-Type: multipart/alternative;
boundary="----=_Part_15177_2024885741.1519686320454"
------=_Part_15177_2024885741.1519686320454
Content-Type: text/plain; charset="UTF-8"
On Monday, 26 February 2018 19:03:58 UTC, Andrey Semashev wrote:
>
> On 02/26/18 20:50, Nevin Liber wrote:
> > On Mon, Feb 26, 2018 at 11:16 AM, JF Bastien <jfba...@apple.com
> <javascript:>
> > <mailto:jfba...@apple.com <javascript:>>> wrote:
> >
> > Without wrapping, I don't see enough motivation to change the status
> > quo, especially since it needlessly introduces an incompatibility with
> > C. And I certainly don't see how this is in the "top 20" things for
> C++20.
>
> Having two's complement signed in the standard is worth it even without
> well defined overflow semantics. Just the guaranteed ability to cast
> from unsigned to signed without UB alone makes it worth it. Currently,
> there simply isn't a way to cast from unsigned to signed portably and
> fail-safe. The whole "let's use signed integers everywhere" incentive
> exists because of this (and therefore is misguided, IMHO).
>
Did you mean UB? Unsigned to signed conversion is UD, as far as I recall.
Wouldn't it be enough to require the signed-unsigned-signed conversion to
round trip (losing the sign of negative zero)?
Personally, I want the language to provide tools with well defined
> overflow semantics as well. These may not be the current signed integer
> types, but certainly they should be types with overloaded arithmetic
> operators (free functions and such are just too verbose for no reason).
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0f5ca8b7-6e06-4065-8492-fc6bb4cca188%40isocpp.org.
------=_Part_15177_2024885741.1519686320454
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, 26 February 2018 19:03:58 UTC, Andrey Semashev =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 02/26/18 20:50, Nevi=
n Liber wrote:
<br>> On Mon, Feb 26, 2018 at 11:16 AM, JF Bastien <<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"kp6OQsQ1AwAJ" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">jfba...@apple.com</a>=
=20
<br>> <mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"kp6OQsQ1AwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;return true;">jfba...@apple.com</a>>> wrote:
<br>>=20
<br>> Without wrapping, I don't see enough motivation to change the =
status=20
<br>> quo, especially since it needlessly introduces an incompatibility =
with=20
<br>> C.=C2=A0 And I certainly don't see how this is in the "to=
p 20" things for C++20.
<br>
<br>Having two's complement signed in the standard is worth it even wit=
hout=20
<br>well defined overflow semantics. Just the guaranteed ability to cast=20
<br>from unsigned to signed without UB alone makes it worth it. Currently,=
=20
<br>there simply isn't a way to cast from unsigned to signed portably a=
nd=20
<br>fail-safe. The whole "let's use signed integers everywhere&quo=
t; incentive=20
<br>exists because of this (and therefore is misguided, IMHO).
<br></blockquote><div><br></div><div>Did you mean UB? Unsigned to signed co=
nversion is UD, as far as I recall.</div><div><br></div><div>Wouldn't i=
t be enough to require the signed-unsigned-signed conversion to round trip =
(losing the sign of negative zero)?</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">Personally, I want the language to provide tool=
s with well defined=20
<br>overflow semantics as well. These may not be the current signed integer=
=20
<br>types, but certainly they should be types with overloaded arithmetic=20
<br>operators (free functions and such are just too verbose for no reason).
<br></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0f5ca8b7-6e06-4065-8492-fc6bb4cca188%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0f5ca8b7-6e06-4065-8492-fc6bb4cca188=
%40isocpp.org</a>.<br />
------=_Part_15177_2024885741.1519686320454--
------=_Part_15176_550944315.1519686320454--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 26 Feb 2018 15:10:09 -0800
Raw View
On segunda-feira, 26 de fevereiro de 2018 09:14:13 PST JF Bastien wrote:
> > For overflow checks, wouldn't functions that'd return whether an overfl=
ow
> > happened while doing the calculation be simpler?
> We simply disagree on what the default behavior of + - * should be. One
> approach will have less syntax and the others more, I=E2=80=99m sure the =
committee
> will come to a decent consensus solution.
I'd argue that if you want to detect the overflow, a function like GCC/Clan=
g=20
__builtin_add_overflow() is better. It should be able to calculate the resu=
lt=20
and tell you whether that overflowed or underflowed. It's also harder to ge=
t=20
wrong or off-by-one errors (or off by 2 billion).
That has no impact on how overflow without detection should be done. I have=
my=20
opinion on that one, though.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/8540355.rT7mrJT1r1%40tjmaciei-mobl1.
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Mon, 26 Feb 2018 15:22:31 -0800
Raw View
--f403043b37b8cfc47b056625c896
Content-Type: text/plain; charset="UTF-8"
On Mon, Feb 26, 2018 at 3:05 PM, Edward Catmur <ed@catmur.co.uk> wrote:
> On Monday, 26 February 2018 19:03:58 UTC, Andrey Semashev wrote:
>>
>> On 02/26/18 20:50, Nevin Liber wrote:
>> > On Mon, Feb 26, 2018 at 11:16 AM, JF Bastien <jfba...@apple.com
>> > <mailto:jfba...@apple.com>> wrote:
>> >
>> > Without wrapping, I don't see enough motivation to change the status
>> > quo, especially since it needlessly introduces an incompatibility with
>> > C. And I certainly don't see how this is in the "top 20" things for
>> C++20.
>>
>> Having two's complement signed in the standard is worth it even without
>> well defined overflow semantics. Just the guaranteed ability to cast
>> from unsigned to signed without UB alone makes it worth it. Currently,
>> there simply isn't a way to cast from unsigned to signed portably and
>> fail-safe. The whole "let's use signed integers everywhere" incentive
>> exists because of this (and therefore is misguided, IMHO).
>>
>
> Did you mean UB? Unsigned to signed conversion is UD, as far as I recall.
>
> Wouldn't it be enough to require the signed-unsigned-signed conversion to
> round trip (losing the sign of negative zero)?
>
Unsigned-to-signed conversion is UB only when there are enum types involved.
I have added two tables to my paper that explain the current situation and
the proposed situation(s), with examples:
https://quuxplusone.github.io/draft/twosc-conservative.html#intro
HTH,
Arthur
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0KCTF%3DokEx0yhH1TJL4gAQMmNWLN15a7%3DgBuqkM6f0P%2Bw%40mail.gmail.com.
--f403043b37b8cfc47b056625c896
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Feb 26, 2018 at 3:05 PM, Edward Catmur <span dir=
=3D"ltr"><<a href=3D"mailto:ed@catmur.co.uk" target=3D"_blank">ed@catmur=
..co.uk</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204=
,204,204);padding-left:1ex"><div dir=3D"ltr"><span class=3D"gmail-">On Mond=
ay, 26 February 2018 19:03:58 UTC, Andrey Semashev wrote:</span><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-lef=
t:1ex"><span class=3D"gmail-">On 02/26/18 20:50, Nevin Liber wrote:
<br></span><span class=3D"gmail-">> On Mon, Feb 26, 2018 at 11:16 AM, JF=
Bastien <<a rel=3D"nofollow">jfba...@apple.com</a>=20
<br>> <mailto:<a rel=3D"nofollow">jfba...@apple.com</a>>> wrote=
:
<br>>=20
<br>> Without wrapping, I don't see enough motivation to change the =
status=20
<br>> quo, especially since it needlessly introduces an incompatibility =
with=20
<br>> C.=C2=A0 And I certainly don't see how this is in the "to=
p 20" things for C++20.
<br>
<br>Having two's complement signed in the standard is worth it even wit=
hout=20
<br>well defined overflow semantics. Just the guaranteed ability to cast=20
<br>from unsigned to signed without UB alone makes it worth it. Currently,=
=20
<br>there simply isn't a way to cast from unsigned to signed portably a=
nd=20
<br>fail-safe. The whole "let's use signed integers everywhere&quo=
t; incentive=20
<br>exists because of this (and therefore is misguided, IMHO).
<br></span></blockquote><div><br></div><div>Did you mean UB? Unsigned to si=
gned conversion is UD, as far as I recall.</div><div><br></div><div>Wouldn&=
#39;t it be enough to require the signed-unsigned-signed conversion to roun=
d trip (losing the sign of negative zero)?</div></div></blockquote><div><br=
></div><div>Unsigned-to-signed conversion is UB only when there are enum ty=
pes involved.</div><div>I have added two tables to my paper that explain th=
e current situation and the proposed situation(s), with examples:</div><div=
><a href=3D"https://quuxplusone.github.io/draft/twosc-conservative.html#int=
ro">https://quuxplusone.github.io/draft/twosc-conservative.html#intro<br></=
a></div><div><br></div><div>HTH,</div><div>Arthur</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0KCTF%3DokEx0yhH1TJL4gAQMmNWLN1=
5a7%3DgBuqkM6f0P%2Bw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0KCTF=
%3DokEx0yhH1TJL4gAQMmNWLN15a7%3DgBuqkM6f0P%2Bw%40mail.gmail.com</a>.<br />
--f403043b37b8cfc47b056625c896--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Mon, 26 Feb 2018 18:26:05 -0500
Raw View
On February 26, 2018 5:10 PM, Thiago Macieira <thiago@macieira.org> wrote:
>
> I'd argue that if you want to detect the overflow, a function like GCC/Clang
> __builtin_add_overflow() is better. It should be able to calculate the result
> and tell you whether that overflowed or underflowed. It's also harder to get
> wrong or off-by-one errors (or off by 2 billion).
>
See also http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0103r1.html#numbers.overarith
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/LkdY9rbhYcRD86M428_I-ES5fbzPZdzNljXHrfy6-AbzUsoIHsPRAIF4RBPlw72_uEl7Y3VoZ5AYQ-ECZFiQo2c26AftZOe8eL4skCOAOUA%3D%40miator.net.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 26 Feb 2018 16:10:21 -0800
Raw View
On segunda-feira, 26 de fevereiro de 2018 15:22:31 PST Arthur O'Dwyer wrote=
:
> Unsigned-to-signed conversion is UB only when there are enum types involv=
ed.
> I have added two tables to my paper that explain the current situation an=
d
> the proposed situation(s), with examples:
> https://quuxplusone.github.io/draft/twosc-conservative.html#intro
Thanks for the update.
By the way, where you say "Notice that atomic integral types are already tw=
o=E2=80=99s=20
complement and have no undefined results; therefore even freestanding=20
implementations must already support two=E2=80=99s complement somehow.", th=
at's also=20
true for some operations on non-atomics. The conversion from signed to=20
unsigned is basically a two's complement no-op, since it requires
unsigned(-1) =3D
unsigned(infinite_precision(UINT_MAX + 1) - 1) =3D
UINT_MAX
(which is ~0, or 0xFFFFFFFF on 32-bit ints)
An implementation that used one's complement negative values would need to=
=20
mutate the bit pattern by adding 1.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2053653.IsSx0ViyDN%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 26 Feb 2018 16:13:38 -0800
Raw View
On segunda-feira, 26 de fevereiro de 2018 15:26:05 PST Zhihao Yuan wrote:
> See also
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0103r1.html#number
> s.overarith
Instead of "If there is no overflow, writes the computed value to *result.", I
suggest that the overflown and truncated value be stored in *result if it did
overflow.
By doing that, these functions could be used for overflow arithmetic when you
don't care or don't need to know if it did overflow.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1678303.bQV78sKWYA%40tjmaciei-mobl1.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Tue, 27 Feb 2018 03:35:08 +0300
Raw View
On 02/27/18 02:22, Arthur O'Dwyer wrote:
>
> Unsigned-to-signed conversion is UB only when there are enum types involved.
> I have added two tables to my paper that explain the current situation
> and the proposed situation(s), with examples:
> https://quuxplusone.github.io/draft/twosc-conservative.html#intro
You may want to add a peculiar use case to the proposal: IIUC, it should
fix the overflow caused by the expression:
long long x = -9223372036854775808;
(Explanation: the 9223372036854775808 literal is a 64-bit number with
the most significant bit set; this number does not fit in 64-bit signed
long long, but does fit in unsigned. The result of the negation is still
unsigned, 9223372036854775808, which still cannot be stored in the
signed long long without invoking implementation-defined behavior. The
peculiar part is that the negative value -9223372036854775808, which the
user intended from the start, is representable in two's complement
signed long long.)
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5fd8159b-f69a-9009-a736-f1ab6e7af7d4%40gmail.com.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Tue, 27 Feb 2018 04:04:49 +0300
Raw View
On 02/27/18 03:10, Thiago Macieira wrote:
> On segunda-feira, 26 de fevereiro de 2018 15:22:31 PST Arthur O'Dwyer wro=
te:
>> Unsigned-to-signed conversion is UB only when there are enum types invol=
ved.
>> I have added two tables to my paper that explain the current situation a=
nd
>> the proposed situation(s), with examples:
>> https://quuxplusone.github.io/draft/twosc-conservative.html#intro
>=20
> Thanks for the update.
>=20
> By the way, where you say "Notice that atomic integral types are already =
two=E2=80=99s
> complement and have no undefined results; therefore even freestanding
> implementations must already support two=E2=80=99s complement somehow.", =
that's also
> true for some operations on non-atomics. The conversion from signed to
> unsigned is basically a two's complement no-op, since it requires
>=20
> unsigned(-1) =3D
> unsigned(infinite_precision(UINT_MAX + 1) - 1) =3D
> UINT_MAX
> (which is ~0, or 0xFFFFFFFF on 32-bit ints)
>=20
> An implementation that used one's complement negative values would need t=
o
> mutate the bit pattern by adding 1.
The conversion basically adds the mathematical value of the signed=20
integer to the unsigned two's complement 0. It doesn't require the=20
signed integer to have a two's complement representation if the machine=20
can perform such heterogeneous addition (or an equivalent conversion).
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/97daeb9e-fe0b-2c4b-b4b2-741ca2714a04%40gmail.com=
..
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Tue, 27 Feb 2018 04:06:52 +0300
Raw View
On 02/27/18 02:03, Thiago Macieira wrote:
> On segunda-feira, 26 de fevereiro de 2018 11:03:53 PST Andrey Semashev wrote:
>> Just the guaranteed ability to cast
>> from unsigned to signed without UB alone makes it worth it.
>
> That's never been UB. But it is IB:
>
> http://eel.is/c++draft/conv.integral#3
> "If the destination type is signed, the value is unchanged if it can be
> represented in the destination type; otherwise, the value is implementation-
> defined."
Right. It doesn't make it portable, though, so there's no practical
difference.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bba79176-f0cb-c4eb-d0cb-0c3fe6977e3c%40gmail.com.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Tue, 27 Feb 2018 04:13:22 +0300
Raw View
On 02/27/18 02:05, Edward Catmur wrote:
> On Monday, 26 February 2018 19:03:58 UTC, Andrey Semashev wrote:
>
> Having two's complement signed in the standard is worth it even without
> well defined overflow semantics. Just the guaranteed ability to cast
> from unsigned to signed without UB alone makes it worth it. Currently,
> there simply isn't a way to cast from unsigned to signed portably and
> fail-safe. The whole "let's use signed integers everywhere" incentive
> exists because of this (and therefore is misguided, IMHO).
>
>
> Did you mean UB? Unsigned to signed conversion is UD, as far as I recall.
Right, it's implementation-defined. Not much better, though.
> Wouldn't it be enough to require the signed-unsigned-signed conversion
> to round trip (losing the sign of negative zero)?
This would not provide portable conversion from unsigned to signed
negative values.
And why should the conversion lose any information?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7080fb4a-5691-d19b-df79-aa6a40eecf63%40gmail.com.
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Mon, 26 Feb 2018 17:28:13 -0800
Raw View
--001a114f4180542bbb0566278a2f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, Feb 26, 2018 at 4:35 PM, Andrey Semashev <andrey.semashev@gmail.com=
>
wrote:
> On 02/27/18 02:22, Arthur O'Dwyer wrote:
>
>>
>> Unsigned-to-signed conversion is UB only when there are enum types
>> involved.
>> I have added two tables to my paper that explain the current situation
>> and the proposed situation(s), with examples:
>> https://quuxplusone.github.io/draft/twosc-conservative.html#intro
>>
>
> You may want to add a peculiar use case to the proposal: IIUC, it should
> fix the overflow caused by the expression:
>
> long long x =3D -9223372036854775808;
>
> (Explanation: the 9223372036854775808 literal is a 64-bit number with the
> most significant bit set; this number does not fit in 64-bit signed long
> long, but does fit in unsigned. The result of the negation is still
> unsigned, 9223372036854775808, which still cannot be stored in the signed
> long long without invoking implementation-defined behavior. The peculiar
> part is that the negative value -9223372036854775808, which the user
> intended from the start, is representable in two's complement signed long
> long.)
Thanks =E2=80=94 updated!
(And I notice that GCC and Clang do subtly different things with that
expression. On Clang -9223372036854775808 is unsigned and the conversion
unfolds as you described; on GCC -9223372036854775808 is actually of type
signed __int128, so it gets a signed-to-signed conversion.... which is
still implementation-defined, though.)
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0LJvgZRNz-qrxErwyoc_nT4cDh%2BgfYh4LB3iH_h7=
WenTg%40mail.gmail.com.
--001a114f4180542bbb0566278a2f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Feb 26, 2018 at 4:35 PM, Andrey Semashev <span dir=
=3D"ltr"><<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank"=
>andrey.semashev@gmail.com</a>></span> wrote:<br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;borde=
r-left-color:rgb(204,204,204);padding-left:1ex"><span class=3D"gmail-">On 0=
2/27/18 02:22, Arthur O'Dwyer wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex">
<br>
Unsigned-to-signed conversion is UB only when there are enum types involved=
..<br>
I have added two tables to my paper that explain the current situation and =
the proposed situation(s), with examples:<br>
<a href=3D"https://quuxplusone.github.io/draft/twosc-conservative.html#intr=
o" rel=3D"noreferrer" target=3D"_blank">https://quuxplusone.github.io/<wbr>=
draft/twosc-conservative.html#<wbr>intro</a><br>
</blockquote>
<br></span>
You may want to add a peculiar use case to the proposal: IIUC, it should fi=
x the overflow caused by the expression:<br>
<br>
=C2=A0 long long x =3D -9223372036854775808;<br>
<br>
(Explanation: the 9223372036854775808 literal is a 64-bit number with the m=
ost significant bit set; this number does not fit in 64-bit signed long lon=
g, but does fit in unsigned. The result of the negation is still unsigned, =
9223372036854775808, which still cannot be stored in the signed long long w=
ithout invoking implementation-defined behavior. The peculiar part is that =
the negative value -9223372036854775808, which the user intended from the s=
tart, is representable in two's complement signed long long.)</blockquo=
te><div><br></div><div>Thanks =E2=80=94 updated!</div><div>(And I notice th=
at GCC and Clang do subtly different things with that expression. On Clang =
-9223372036854775808 is unsigned and the conversion unfolds as you describe=
d; on GCC -9223372036854775808 is actually of type signed __int128, so it g=
ets a signed-to-signed conversion.... which is still implementation-defined=
, though.)</div><div><br></div><div>=E2=80=93Arthur</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0LJvgZRNz-qrxErwyoc_nT4cDh%2Bgf=
Yh4LB3iH_h7WenTg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0LJvgZRNz=
-qrxErwyoc_nT4cDh%2BgfYh4LB3iH_h7WenTg%40mail.gmail.com</a>.<br />
--001a114f4180542bbb0566278a2f--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 26 Feb 2018 17:33:57 -0800
Raw View
On segunda-feira, 26 de fevereiro de 2018 17:28:13 PST Arthur O'Dwyer wrote:
> unfolds as you described; on GCC -9223372036854775808 is actually of type
> signed __int128, so it gets a signed-to-signed conversion.... which is
> still implementation-defined, though.)
Only if the target type cannot represent the value. In this case, it can.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2140195.afrQ3jm2S5%40tjmaciei-mobl1.
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Mon, 26 Feb 2018 18:02:02 -0800
Raw View
--94eb2c0460884b27c00566280382
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, Feb 26, 2018 at 5:33 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> On segunda-feira, 26 de fevereiro de 2018 17:28:13 PST Arthur O'Dwyer
> wrote:
> > unfolds as you described; on GCC -9223372036854775808 is actually of ty=
pe
> > signed __int128, so it gets a signed-to-signed conversion.... which is
> > still implementation-defined, though.)
>
> Only if the target type cannot represent the value. In this case, it can.
>
Oops! Good catch. Fixed. Thanks.
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0%2B1vEB259kREjBHD-Y5y98fTSHbvDp2xuw6EWRMp=
R1%2BQQ%40mail.gmail.com.
--94eb2c0460884b27c00566280382
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Feb 26, 2018 at 5:33 PM, Thiago Macieira <span dir=
=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiag=
o@macieira.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On segun=
da-feira, 26 de fevereiro de 2018 17:28:13 PST Arthur O'Dwyer wrote:<br=
>
> unfolds as you described; on GCC -9223372036854775808 is actually of t=
ype<br>
> signed __int128, so it gets a signed-to-signed conversion.... which is=
<br>
> still implementation-defined, though.)<br>
<br>
</span>Only if the target type cannot represent the value. In this case, it=
can.<br></blockquote><div><br></div><div>Oops!=C2=A0 Good catch. Fixed. Th=
anks.</div><div><br></div><div>=E2=80=93Arthur</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2B1vEB259kREjBHD-Y5y98fTSHbvD=
p2xuw6EWRMpR1%2BQQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2B1vE=
B259kREjBHD-Y5y98fTSHbvDp2xuw6EWRMpR1%2BQQ%40mail.gmail.com</a>.<br />
--94eb2c0460884b27c00566280382--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 27 Feb 2018 08:51:42 +0000
Raw View
--001a11444996582bb705662dbc57
Content-Type: text/plain; charset="UTF-8"
On Tue, Feb 27, 2018 at 1:13 AM, Andrey Semashev <andrey.semashev@gmail.com>
wrote:
> On 02/27/18 02:05, Edward Catmur wrote:
>
>> On Monday, 26 February 2018 19:03:58 UTC, Andrey Semashev wrote:
>>
>> Having two's complement signed in the standard is worth it even
>> without
>> well defined overflow semantics. Just the guaranteed ability to cast
>> from unsigned to signed without UB alone makes it worth it. Currently,
>> there simply isn't a way to cast from unsigned to signed portably and
>> fail-safe. The whole "let's use signed integers everywhere" incentive
>> exists because of this (and therefore is misguided, IMHO).
>>
>>
>> Did you mean UB? Unsigned to signed conversion is UD, as far as I recall.
>>
>
> Right, it's implementation-defined. Not much better, though.
>
It makes a big difference; it's usable in constexpr, for one. Also, it
isn't diagnosable by ubsan in normal modes.
> Wouldn't it be enough to require the signed-unsigned-signed conversion to
>> round trip (losing the sign of negative zero)?
>>
>
> This would not provide portable conversion from unsigned to signed
> negative values.
>
It would provide portable conversion for every value in unsigned that is
the result of a conversion from a value in signed, which is every value in
unsigned if signed is two's complement and every value except 0x80...
otherwise. In what circumstances would that be insufficient?
> And why should the conversion lose any information?
It's the signed-to-unsigned conversion that loses information; this is
because we want zero and negative zero to be treated similarly. It's the
same for conversions from floating point to integral.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOb7HAgKoynSH69nbyT3hrVYqGugb_BSH%3D-JsjS3-qynyw%40mail.gmail.com.
--001a11444996582bb705662dbc57
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Feb 27, 2018 at 1:13 AM, Andrey Semashev <span dir=3D"ltr"><<a href=
=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gma=
il.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D"">On 02/27/18 02:05, Edward Catmur wrote:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span class=3D"">
On Monday, 26 February 2018 19:03:58 UTC, Andrey Semashev wrote:<br>
<br></span><span class=3D"">
=C2=A0 =C2=A0 Having two's complement signed in the standard is worth i=
t even without<br>
=C2=A0 =C2=A0 well defined overflow semantics. Just the guaranteed ability =
to cast<br>
=C2=A0 =C2=A0 from unsigned to signed without UB alone makes it worth it. C=
urrently,<br>
=C2=A0 =C2=A0 there simply isn't a way to cast from unsigned to signed =
portably and<br>
=C2=A0 =C2=A0 fail-safe. The whole "let's use signed integers ever=
ywhere" incentive<br>
=C2=A0 =C2=A0 exists because of this (and therefore is misguided, IMHO).<br=
>
<br>
<br>
Did you mean UB? Unsigned to signed conversion is UD, as far as I recall.<b=
r>
</span></blockquote>
<br>
Right, it's implementation-defined. Not much better, though.<span class=
=3D""><br></span></blockquote><div><br></div><div>It makes a big difference=
; it's usable in constexpr, for one. Also, it isn't diagnosable by =
ubsan in normal modes.</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><span class=3D"">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Wouldn't it be enough to require the signed-unsigned-signed conversion =
to round trip (losing the sign of negative zero)?<br>
</blockquote>
<br></span>
This would not provide portable conversion from unsigned to signed negative=
values.<br></blockquote><div><br></div><div>It would provide portable conv=
ersion for every value in unsigned that is the result of a conversion from =
a value in signed, which is every value in unsigned if signed is two's =
complement and every value except 0x80... otherwise. In what circumstances =
would that be insufficient?</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
And why should the conversion lose any information?</blockquote><div><br></=
div><div>It's the signed-to-unsigned conversion that loses information;=
this is because we want zero and negative zero to be treated similarly. It=
's the same for conversions from floating point to integral.</div><div>=
<br></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOb7HAgKoynSH69nbyT3hrVYqGugb_BS=
H%3D-JsjS3-qynyw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOb7HAgKoy=
nSH69nbyT3hrVYqGugb_BSH%3D-JsjS3-qynyw%40mail.gmail.com</a>.<br />
--001a11444996582bb705662dbc57--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Tue, 27 Feb 2018 13:01:14 +0300
Raw View
On 02/27/18 11:51, 'Edward Catmur' via ISO C++ Standard - Future
Proposals wrote:
> On Tue, Feb 27, 2018 at 1:13 AM, Andrey Semashev
> <andrey.semashev@gmail.com <mailto:andrey.semashev@gmail.com>> wrote:
>
> On 02/27/18 02:05, Edward Catmur wrote:
>
> Wouldn't it be enough to require the signed-unsigned-signed
> conversion to round trip (losing the sign of negative zero)?
>
> This would not provide portable conversion from unsigned to signed
> negative values.
>
> It would provide portable conversion for every value in unsigned that is
> the result of a conversion from a value in signed, which is every value
> in unsigned if signed is two's complement and every value except 0x80...
> otherwise. In what circumstances would that be insufficient?
See my -9223372036854775808 example in the reply to Arthur O'Dwyer.
Also, the conversions of unsigned to signed negative need to be well
defined and portable if you want to implement signed overflow in a
library. You would normally convert to unsigned, perform arithmetics and
then memcpy the result to signed (because a regular cast is
implementation-defined, which basically gives no guarantees on the
result). For that to provide a portable and meaningful result, signed
representation must be two's complement.
> And why should the conversion lose any information?
>
> It's the signed-to-unsigned conversion that loses information; this is
> because we want zero and negative zero to be treated similarly. It's the
> same for conversions from floating point to integral.
Floating point numbers are not representable in integers in general,
hence the inherent loss of information on conversion. Signed integers
are much closer to unsigned integers in that the number of distinct
values is the same and non-negative values are represented the same way.
Therefore the conversion can be made without loss of information.
Anyway, I don't think negative zero is relevant as I'm in favor of
mandating two's complement representation.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4dce3fb4-405a-f5bb-6f43-2f0c56e199e9%40gmail.com.
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 27 Feb 2018 11:19:13 +0000
Raw View
--001a114725dae828c105662fcb5b
Content-Type: text/plain; charset="UTF-8"
On Tue, Feb 27, 2018 at 10:01 AM, Andrey Semashev <andrey.semashev@gmail.com
> wrote:
> On 02/27/18 11:51, 'Edward Catmur' via ISO C++ Standard - Future Proposals
> wrote:
>
>> On Tue, Feb 27, 2018 at 1:13 AM, Andrey Semashev <
>> andrey.semashev@gmail.com <mailto:andrey.semashev@gmail.com>> wrote:
>>
>> On 02/27/18 02:05, Edward Catmur wrote:
>>
>> Wouldn't it be enough to require the signed-unsigned-signed
>> conversion to round trip (losing the sign of negative zero)?
>>
>> This would not provide portable conversion from unsigned to signed
>> negative values.
>>
>> It would provide portable conversion for every value in unsigned that is
>> the result of a conversion from a value in signed, which is every value in
>> unsigned if signed is two's complement and every value except 0x80...
>> otherwise. In what circumstances would that be insufficient?
>>
>
> See my -9223372036854775808 example in the reply to Arthur O'Dwyer.
>
Negating 9223372036854775808 in unsigned gives 9223372036854775808, which
happens to be the result of converting -9223372036854775808 into (64-bit)
unsigned. So provided a round-trip guarantee and that -9223372036854775808 is
a value in the signed type, which it is for 64-bit two's complement,
9223372036854775808 in unsigned would convert to -9223372036854775808 in
signed. That is, -9223372036854775808 would be guaranteed to result in
-9223372036854775808
if that value exists in the signed type.
> Also, the conversions of unsigned to signed negative need to be well
> defined and portable if you want to implement signed overflow in a library.
> You would normally convert to unsigned, perform arithmetics and then memcpy
> the result to signed (because a regular cast is implementation-defined,
> which basically gives no guarantees on the result). For that to provide a
> portable and meaningful result, signed representation must be two's
> complement.
>
Surely the normal approach would be to wrap the compiler intrinsics for
overflow arithmetic. If they aren't available for whatever reason, tests
will confirm that the conversion behaves as expected. If you can't use the
intrinsics and can't test, how confident can you be that the compiler has
implemented the conversion correctly or indeed that you have written your
arithmetic correctly? On the other hand if the conversion is guaranteed to
round-trip then you can use a cast instead of memcpy. There is no
circumstance in which memcpy is preferable to an arithmetic conversion,
except in the entirely hypothetical situation in which you have confirmed
that the implementation uses two's complement but not that it performs the
conversion from unsigned to signed in the obvious manner.
And why should the conversion lose any information?
>>
>> It's the signed-to-unsigned conversion that loses information; this is
>> because we want zero and negative zero to be treated similarly. It's the
>> same for conversions from floating point to integral.
>>
>
> Floating point numbers are not representable in integers in general, hence
> the inherent loss of information on conversion. Signed integers are much
> closer to unsigned integers in that the number of distinct values is the
> same and non-negative values are represented the same way. Therefore the
> conversion can be made without loss of information.
>
The number of distinct values is the same only if positive and negative
zero are considered distinct.
> Anyway, I don't think negative zero is relevant as I'm in favor of
> mandating two's complement representation.
Negative zero is the reason why the signed-unsigned conversion loses
information only if the signed type has negative zero. Obviously it is
irrelevant if the signed type does not have negative zero. In itself this
is not a reason to require two's complement.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaZX%3DR7%3D2LQyjdZh6vL41-Lm7R4gm-zgEsZkFGPgrNt5A%40mail.gmail.com.
--001a114725dae828c105662fcb5b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Feb 27, 2018 at 10:01 AM, Andrey Semashev <span dir=3D"ltr"><=
;<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.sema=
shev@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 0=
2/27/18 11:51, 'Edward Catmur' via ISO C++ Standard - Future Propos=
als wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Tue, Feb 27, 2018 at 1:13 AM, Andrey Semashev <<a href=3D"mailto:andr=
ey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gmail.com</a> <=
mailto:<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andre=
y.semashev@gmail.<wbr>com</a>>> wrote:<br>
<br>
=C2=A0 =C2=A0 On 02/27/18 02:05, Edward Catmur wrote:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Wouldn't it be enough to require the signed=
-unsigned-signed<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 conversion to round trip (losing the sign of ne=
gative zero)?<br>
<br>
=C2=A0 =C2=A0 This would not provide portable conversion from unsigned to s=
igned<br>
=C2=A0 =C2=A0 negative values.<br>
<br>
It would provide portable conversion for every value in unsigned that is th=
e result of a conversion from a value in signed, which is every value in un=
signed if signed is two's complement and every value except 0x80... oth=
erwise. In what circumstances would that be insufficient?<br>
</blockquote>
<br>
See my -9223372036854775808 example in the reply to Arthur O'Dwyer.<br>=
</blockquote><div><br></div><div>Negating=C2=A0<span style=3D"color:rgb(34,=
34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-=
variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-sp=
acing:normal;text-align:start;text-indent:0px;text-transform:none;white-spa=
ce:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoratio=
n-style:initial;text-decoration-color:initial;float:none;display:inline">92=
23372036854775808<span>=C2=A0in unsigned gives=C2=A0<span style=3D"color:rg=
b(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;=
font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;lett=
er-spacing:normal;text-align:start;text-indent:0px;text-transform:none;whit=
e-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-deco=
ration-style:initial;text-decoration-color:initial;float:none;display:inlin=
e">9223372036854775808, which happens to be the result of converting -<span=
style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;=
font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;fo=
nt-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-t=
ransform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,=
255,255);text-decoration-style:initial;text-decoration-color:initial;float:=
none;display:inline">9223372036854775808<span>=C2=A0into (64-bit) unsigned.=
So provided a round-trip guarantee and that -<span style=3D"color:rgb(34,3=
4,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-v=
ariant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spa=
cing:normal;text-align:start;text-indent:0px;text-transform:none;white-spac=
e:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration=
-style:initial;text-decoration-color:initial;float:none;display:inline">922=
3372036854775808<span>=C2=A0is a value in the signed type, which it is for =
64-bit two's complement</span></span>,=C2=A0<span style=3D"color:rgb(34=
,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font=
-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-s=
pacing:normal;text-align:start;text-indent:0px;text-transform:none;white-sp=
ace:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decorati=
on-style:initial;text-decoration-color:initial;float:none;display:inline">9=
223372036854775808<span>=C2=A0in unsigned would convert to -<span style=3D"=
color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style=
:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:=
400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:n=
one;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);t=
ext-decoration-style:initial;text-decoration-color:initial;float:none;displ=
ay:inline">9223372036854775808<span>=C2=A0in signed. That is, -<span style=
=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-s=
tyle:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-wei=
ght:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transfo=
rm:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,25=
5);text-decoration-style:initial;text-decoration-color:initial;float:none;d=
isplay:inline">9223372036854775808<span>=C2=A0would be guaranteed to result=
in -<span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-s=
ize:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps=
:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:=
0px;text-transform:none;white-space:normal;word-spacing:0px;background-colo=
r:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:init=
ial;float:none;display:inline">9223372036854775808 if that value exists in =
the signed type.</span></span></span></span></span></span></span></span></s=
pan></span></span></span></div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
Also, the conversions of unsigned to signed negative need to be well define=
d and portable if you want to implement signed overflow in a library. You w=
ould normally convert to unsigned, perform arithmetics and then memcpy the =
result to signed (because a regular cast is implementation-defined, which b=
asically gives no guarantees on the result). For that to provide a portable=
and meaningful result, signed representation must be two's complement.=
<br></blockquote><div><br></div><div>Surely the normal approach would be to=
wrap the compiler intrinsics for overflow arithmetic. If they aren't a=
vailable for whatever reason, tests will confirm that the conversion behave=
s as expected. If you can't use the intrinsics and can't test, how =
confident can you be that the compiler has implemented the conversion corre=
ctly or indeed that you have written your arithmetic correctly? On the othe=
r hand if the conversion is guaranteed to round-trip then you can use a cas=
t instead of memcpy. There is no circumstance in which memcpy is preferable=
to an arithmetic conversion, except in the entirely hypothetical situation=
in which you have confirmed that the implementation uses two's complem=
ent but not that it performs the conversion from unsigned to signed in the =
obvious manner.</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
=C2=A0 =C2=A0 And why should the conversion lose any information?<br>
<br>
It's the signed-to-unsigned conversion that loses information; this is =
because we want zero and negative zero to be treated similarly. It's th=
e same for conversions from floating point to integral.<br>
</blockquote>
<br>
Floating point numbers are not representable in integers in general, hence =
the inherent loss of information on conversion. Signed integers are much cl=
oser to unsigned integers in that the number of distinct values is the same=
and non-negative values are represented the same way. Therefore the conver=
sion can be made without loss of information.<br></blockquote><div><br></di=
v><div>The number of distinct values is the same only if positive and negat=
ive zero are considered distinct.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
Anyway, I don't think negative zero is relevant as I'm in favor of =
mandating two's complement representation.</blockquote><div><br></div><=
div>Negative zero is the reason why the signed-unsigned conversion loses in=
formation only if the signed type has negative zero. Obviously it is irrele=
vant if the signed type does not have negative zero. In itself this is not =
a reason to require two's complement.</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaZX%3DR7%3D2LQyjdZh6vL41-Lm7R4=
gm-zgEsZkFGPgrNt5A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaZX%3D=
R7%3D2LQyjdZh6vL41-Lm7R4gm-zgEsZkFGPgrNt5A%40mail.gmail.com</a>.<br />
--001a114725dae828c105662fcb5b--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Tue, 27 Feb 2018 15:07:32 +0300
Raw View
On 02/27/18 14:19, 'Edward Catmur' via ISO C++ Standard - Future=20
Proposals wrote:
>=20
> On Tue, Feb 27, 2018 at 10:01 AM, Andrey Semashev=20
> <andrey.semashev@gmail.com <mailto:andrey.semashev@gmail.com>> wrote:
>=20
> On 02/27/18 11:51, 'Edward Catmur' via ISO C++ Standard - Future
> Proposals wrote:
>=20
> On Tue, Feb 27, 2018 at 1:13 AM, Andrey Semashev
> <andrey.semashev@gmail.com <mailto:andrey.semashev@gmail.com>
> <mailto:andrey.semashev@gmail.com
> <mailto:andrey.semashev@gmail.com>>> wrote:
>=20
> =C2=A0 =C2=A0 On 02/27/18 02:05, Edward Catmur wrote:
>=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Wouldn't it be enough to require the=
signed-unsigned-signed
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 conversion to round trip (losing the=
sign of negative
> zero)?
>=20
> =C2=A0 =C2=A0 This would not provide portable conversion from un=
signed to
> signed
> =C2=A0 =C2=A0 negative values.
>=20
> It would provide portable conversion for every value in unsigned
> that is the result of a conversion from a value in signed, which
> is every value in unsigned if signed is two's complement and
> every value except 0x80... otherwise. In what circumstances
> would that be insufficient?
>=20
>=20
> See my -9223372036854775808 example in the reply to Arthur O'Dwyer.
>=20
>=20
> Negating 9223372036854775808=C2=A0in unsigned gives 9223372036854775808,=
=20
> which happens to be the result of converting -9223372036854775808=C2=A0in=
to=20
> (64-bit) unsigned. So provided a round-trip guarantee and that=20
> -9223372036854775808=C2=A0is a value in the signed type, which it is for=
=20
> 64-bit two's complement, 9223372036854775808=C2=A0in unsigned would conve=
rt=20
> to -9223372036854775808=C2=A0in signed. That is, -9223372036854775808=C2=
=A0would=20
> be guaranteed to result in -9223372036854775808 if that value exists in=
=20
> the signed type.
No, the roundtrip guarantee does not provide the guarantee that the=20
resulting signed value will be -9223372036854775808. In other words, the=20
roundtrip guarantee is this:
unsigned long long x1 =3D 9223372036854775808;
signed long long x2 =3D x1; // x2 value is unknown. trap, possibly?
unsigned long long x3 =3D x2; // x3 =3D=3D x1
What I really want, and what the original example requires, is that x2=20
is guaranteed to have value -9223372036854775808 and nothing else.
> Also, the conversions of unsigned to signed negative need to be well
> defined and portable if you want to implement signed overflow in a
> library. You would normally convert to unsigned, perform arithmetics
> and then memcpy the result to signed (because a regular cast is
> implementation-defined, which basically gives no guarantees on the
> result). For that to provide a portable and meaningful result,
> signed representation must be two's complement.
>=20
> Surely the normal approach would be to wrap the compiler intrinsics for=
=20
> overflow arithmetic.
Compiler intrinsics or inline assembler are not portable. I want this=20
ability in portable legal C++.
> If they aren't available for whatever reason, tests=20
> will confirm that the conversion behaves as expected.
As long as the conversion is implementation-defined, the tests would=20
only verify that the implementation is doing what we expect. While that=20
sort of protects from unexpected results (as long as the tests are run=20
by the users), that is not what I would like to have as a library=20
developer. I want to be able to say to my users what will be the result=20
of operations of my library and I can't do that if I use=20
implementation-defined or undefined behavior in my implementation.
> If you can't use=20
> the intrinsics and can't test, how confident can you be that the=20
> compiler has implemented the conversion correctly or indeed that you=20
> have written your arithmetic correctly? On the other hand if the=20
> conversion is guaranteed to round-trip then you can use a cast instead=20
> of memcpy. There is no circumstance in which memcpy is preferable to an=
=20
> arithmetic conversion, except in the entirely hypothetical situation in=
=20
> which you have confirmed that the implementation uses two's complement=20
> but not that it performs the conversion from unsigned to signed in the=20
> obvious manner.
I consider whatever is not defined by the standard to be not portable.=20
Even if it is implementation-defined and if you would expect every=20
implementation to do it in an obvious way. If it's not defined then it=20
can do whatever weird stuff. OTOH, if there is only one reasonable way=20
to implement it then why is it not defined in the standard?
As long as I'm in the non-portable land, I can do whatever hacks the=20
particular compiler allows to get the job done. But I don't consider=20
that a good thing that every other developer should do in their code.=20
Therefore I want this very basic thing, integer conversion, to "just=20
work" and produce portable well-defined results, unsurprising to most=20
users. Naturally, if integer conversion is defined to work the way we=20
expect (i.e. to be equivalent to memcpy) the memcpy trick becomes=20
unnecessary.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/32edb539-a093-088d-f5fe-7c5f86c979ad%40gmail.com=
..
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 27 Feb 2018 15:27:25 +0000
Raw View
--001a11417f2a8ff87505663343b4
Content-Type: text/plain; charset="UTF-8"
On Tue, Feb 27, 2018 at 12:07 PM, Andrey Semashev <andrey.semashev@gmail.com
> wrote:
> On 02/27/18 14:19, 'Edward Catmur' via ISO C++ Standard - Future Proposals
> wrote:
>
>>
>> On Tue, Feb 27, 2018 at 10:01 AM, Andrey Semashev <
>> andrey.semashev@gmail.com <mailto:andrey.semashev@gmail.com>> wrote:
>>
>> On 02/27/18 11:51, 'Edward Catmur' via ISO C++ Standard - Future
>> Proposals wrote:
>>
>> On Tue, Feb 27, 2018 at 1:13 AM, Andrey Semashev
>> <andrey.semashev@gmail.com <mailto:andrey.semashev@gmail.com>
>> <mailto:andrey.semashev@gmail.com
>> <mailto:andrey.semashev@gmail.com>>> wrote:
>>
>> On 02/27/18 02:05, Edward Catmur wrote:
>>
>> Wouldn't it be enough to require the
>> signed-unsigned-signed
>> conversion to round trip (losing the sign of negative
>> zero)?
>>
>> This would not provide portable conversion from unsigned to
>> signed
>> negative values.
>>
>> It would provide portable conversion for every value in unsigned
>> that is the result of a conversion from a value in signed, which
>> is every value in unsigned if signed is two's complement and
>> every value except 0x80... otherwise. In what circumstances
>> would that be insufficient?
>>
>>
>> See my -9223372036854775808 example in the reply to Arthur O'Dwyer.
>>
>>
>> Negating 9223372036854775808 in unsigned gives 9223372036854775808, which
>> happens to be the result of converting -9223372036854775808 into (64-bit)
>> unsigned. So provided a round-trip guarantee and that
>> -9223372036854775808 is a value in the signed type, which it is for 64-bit
>> two's complement, 9223372036854775808 in unsigned would convert to
>> -9223372036854775808 in signed. That is, -9223372036854775808 would be
>> guaranteed to result in -9223372036854775808 if that value exists in the
>> signed type.
>>
>
> No, the roundtrip guarantee does not provide the guarantee that the
> resulting signed value will be -9223372036854775808. In other words, the
> roundtrip guarantee is this:
>
> unsigned long long x1 = 9223372036854775808;
> signed long long x2 = x1; // x2 value is unknown. trap, possibly?
> unsigned long long x3 = x2; // x3 == x1
>
> What I really want, and what the original example requires, is that x2 is
> guaranteed to have value -9223372036854775808 and nothing else.
>
If x3 == x1, then x2 must have had the value -9223372036854775808 and it
cannot have been a trap representation. There is no other value in signed
64-bit that converts to 9223372036854775808.
Actually, this raises an issue with your paper: you appear to have left
open whether values of the form 0x80... (such as -9223372036854775808) are
trap representations. Was this intentional, or have I missed something?
Also, the conversions of unsigned to signed negative need to be well
>> defined and portable if you want to implement signed overflow in a
>> library. You would normally convert to unsigned, perform arithmetics
>> and then memcpy the result to signed (because a regular cast is
>> implementation-defined, which basically gives no guarantees on the
>> result). For that to provide a portable and meaningful result,
>> signed representation must be two's complement.
>>
>> Surely the normal approach would be to wrap the compiler intrinsics for
>> overflow arithmetic.
>>
>
> Compiler intrinsics or inline assembler are not portable. I want this
> ability in portable legal C++.
>
The intrinsics are available on every actively maintained compiler, and
result in clearer and more efficient code. There is little point in
expanding the space of strictly conforming programs if they are slow and
abstruse. It would be far better to standardize the intrinsics.
If they aren't available for whatever reason, tests will confirm that the
>> conversion behaves as expected.
>>
>
> As long as the conversion is implementation-defined, the tests would only
> verify that the implementation is doing what we expect. While that sort of
> protects from unexpected results (as long as the tests are run by the
> users), that is not what I would like to have as a library developer. I
> want to be able to say to my users what will be the result of operations of
> my library and I can't do that if I use implementation-defined or undefined
> behavior in my implementation.
>
You absolutely can; you either test at compile time that the
implementation-defined behavior enables your approach, or you test that the
implementation is one documented to behave as you require. Or you ask your
users to do so.
If you can't use the intrinsics and can't test, how confident can you be
>> that the compiler has implemented the conversion correctly or indeed that
>> you have written your arithmetic correctly? On the other hand if the
>> conversion is guaranteed to round-trip then you can use a cast instead of
>> memcpy. There is no circumstance in which memcpy is preferable to an
>> arithmetic conversion, except in the entirely hypothetical situation in
>> which you have confirmed that the implementation uses two's complement but
>> not that it performs the conversion from unsigned to signed in the obvious
>> manner.
>>
>
> I consider whatever is not defined by the standard to be not portable.
> Even if it is implementation-defined and if you would expect every
> implementation to do it in an obvious way. If it's not defined then it can
> do whatever weird stuff. OTOH, if there is only one reasonable way to
> implement it then why is it not defined in the standard?
>
Implementation-defined behavior is required to be documented, so you can
very quickly check whether any "weird stuff" is on the cards. And for the
most part it is detectable at compile time by user code.
As long as I'm in the non-portable land, I can do whatever hacks the
> particular compiler allows to get the job done. But I don't consider that a
> good thing that every other developer should do in their code. Therefore I
> want this very basic thing, integer conversion, to "just work" and produce
> portable well-defined results, unsurprising to most users. Naturally, if
> integer conversion is defined to work the way we expect (i.e. to be
> equivalent to memcpy) the memcpy trick becomes unnecessary.
If you're writing low-level code such as is dependent on unsigned-to-signed
conversion, you will tune your code to implementations so it will not be
strictly conforming anyway.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObvtL3M_aT26zTgULEFXO19vAniZ09eQ1qs1HtzhNbKGQ%40mail.gmail.com.
--001a11417f2a8ff87505663343b4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Feb 27, 2018 at 12:07 PM, Andrey Semashev <span dir=3D"ltr"><<a href=
=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gma=
il.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 02/27/18 =
14:19, 'Edward Catmur' via ISO C++ Standard - Future Proposals wrot=
e:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
On Tue, Feb 27, 2018 at 10:01 AM, Andrey Semashev <<a href=3D"mailto:and=
rey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gmail.com</a> <=
;mailto:<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andr=
ey.semashev@gmail.<wbr>com</a>>> wrote:<br>
<br>
=C2=A0 =C2=A0 On 02/27/18 11:51, 'Edward Catmur' via ISO C++ Standa=
rd - Future<br>
=C2=A0 =C2=A0 Proposals wrote:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Tue, Feb 27, 2018 at 1:13 AM, Andrey Semashe=
v<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"mailto:andrey.semashev@gmail.com=
" target=3D"_blank">andrey.semashev@gmail.com</a> <mailto:<a href=3D"mai=
lto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gmail.<wbr=
>com</a>><br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:<a href=3D"mailto:andrey.semashev@gm=
ail.com" target=3D"_blank">andrey.semashev@gmail.<wbr>com</a><br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:<a href=3D"mailto:andrey.semashev@gm=
ail.com" target=3D"_blank">andrey.semashev@gmail.<wbr>com</a>>>> w=
rote:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 On 02/27/18 02:05, Edward C=
atmur wrote:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 Wouldn't =
it be enough to require the signed-unsigned-signed<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 conversion to=
round trip (losing the sign of negative<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 zero)?<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 This would not provide port=
able conversion from unsigned to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 signed<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 negative values.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 It would provide portable conversion for every =
value in unsigned<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that is the result of a conversion from a value=
in signed, which<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is every value in unsigned if signed is two'=
;s complement and<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 every value except 0x80... otherwise. In what c=
ircumstances<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 would that be insufficient?<br>
<br>
<br>
=C2=A0 =C2=A0 See my -9223372036854775808 example in the reply to Arthur O&=
#39;Dwyer.<br>
<br>
<br>
Negating 9223372036854775808=C2=A0in unsigned gives 9223372036854775808, wh=
ich happens to be the result of converting -9223372036854775808=C2=A0into (=
64-bit) unsigned. So provided a round-trip guarantee and that -922337203685=
4775808=C2=A0is a value in the signed type, which it is for 64-bit two'=
s complement, 9223372036854775808=C2=A0in unsigned would convert to -922337=
2036854775808=C2=A0in signed. That is, -9223372036854775808=C2=A0would be g=
uaranteed to result in -9223372036854775808 if that value exists in the sig=
ned type.<br>
</blockquote>
<br>
No, the roundtrip guarantee does not provide the guarantee that the resulti=
ng signed value will be -9223372036854775808. In other words, the roundtrip=
guarantee is this:<br>
<br>
=C2=A0 unsigned long long x1 =3D 9223372036854775808;<br>
=C2=A0 signed long long x2 =3D x1; // x2 value is unknown. trap, possibly?<=
br>
=C2=A0 unsigned long long x3 =3D x2; // x3 =3D=3D x1<br>
<br>
What I really want, and what the original example requires, is that x2 is g=
uaranteed to have value -9223372036854775808 and nothing else.<br></blockqu=
ote><div><br></div><div>If x3 =3D=3D x1, then x2 must have had the value=C2=
=A0<span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-siz=
e:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:n=
ormal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0p=
x;text-transform:none;white-space:normal;word-spacing:0px;background-color:=
rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initia=
l;float:none;display:inline">-9223372036854775808 and it cannot have been a=
trap representation. There is no other value in signed 64-bit that convert=
s to=C2=A0<span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;f=
ont-size:small;font-style:normal;font-variant-ligatures:normal;font-variant=
-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-in=
dent:0px;text-transform:none;white-space:normal;word-spacing:0px;background=
-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color=
:initial;float:none;display:inline">9223372036854775808.</span></span></div=
><div><span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-=
size:small;font-style:normal;font-variant-ligatures:normal;font-variant-cap=
s:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent=
:0px;text-transform:none;white-space:normal;word-spacing:0px;background-col=
or:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:ini=
tial;float:none;display:inline"><br></span></div><div><span style=3D"color:=
rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:norma=
l;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;le=
tter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;wh=
ite-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-de=
coration-style:initial;text-decoration-color:initial;float:none;display:inl=
ine">Actually, this raises an issue with your paper: you appear to have lef=
t open whether values of the form 0x80... (such as=C2=A0<span style=3D"colo=
r:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:nor=
mal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;=
letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;=
white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-=
decoration-style:initial;text-decoration-color:initial;float:none;display:i=
nline"><span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font=
-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-ca=
ps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-inden=
t:0px;text-transform:none;white-space:normal;word-spacing:0px;background-co=
lor:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:in=
itial;float:none;display:inline">-9223372036854775808) are trap representat=
ions. Was this intentional, or have I missed something?</span></span></span=
></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
=C2=A0 =C2=A0 Also, the conversions of unsigned to signed negative need to =
be well<br>
=C2=A0 =C2=A0 defined and portable if you want to implement signed overflow=
in a<br>
=C2=A0 =C2=A0 library. You would normally convert to unsigned, perform arit=
hmetics<br>
=C2=A0 =C2=A0 and then memcpy the result to signed (because a regular cast =
is<br>
=C2=A0 =C2=A0 implementation-defined, which basically gives no guarantees o=
n the<br>
=C2=A0 =C2=A0 result). For that to provide a portable and meaningful result=
,<br>
=C2=A0 =C2=A0 signed representation must be two's complement.<br>
<br>
Surely the normal approach would be to wrap the compiler intrinsics for ove=
rflow arithmetic.<br>
</blockquote>
<br>
Compiler intrinsics or inline assembler are not portable. I want this abili=
ty in portable legal C++.<br></blockquote><div><br></div><div>The intrinsic=
s are available on every actively maintained compiler, and result in cleare=
r and more efficient code. There is little point in expanding the space of =
strictly conforming programs if they are slow and abstruse. It would be far=
better to standardize the intrinsics.</div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
If they aren't available for whatever reason, tests will confirm that t=
he conversion behaves as expected.<br>
</blockquote>
<br>
As long as the conversion is implementation-defined, the tests would only v=
erify that the implementation is doing what we expect. While that sort of p=
rotects from unexpected results (as long as the tests are run by the users)=
, that is not what I would like to have as a library developer. I want to b=
e able to say to my users what will be the result of operations of my libra=
ry and I can't do that if I use implementation-defined or undefined beh=
avior in my implementation.<br></blockquote><div><br></div><div>You absolut=
ely can; you either test at compile time that the implementation-defined be=
havior enables your approach, or you test that the implementation is one do=
cumented to behave as you require. Or you ask your users to do so.</div><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
If you can't use the intrinsics and can't test, how confident can y=
ou be that the compiler has implemented the conversion correctly or indeed =
that you have written your arithmetic correctly? On the other hand if the c=
onversion is guaranteed to round-trip then you can use a cast instead of me=
mcpy. There is no circumstance in which memcpy is preferable to an arithmet=
ic conversion, except in the entirely hypothetical situation in which you h=
ave confirmed that the implementation uses two's complement but not tha=
t it performs the conversion from unsigned to signed in the obvious manner.=
<br>
</blockquote>
<br>
I consider whatever is not defined by the standard to be not portable. Even=
if it is implementation-defined and if you would expect every implementati=
on to do it in an obvious way. If it's not defined then it can do whate=
ver weird stuff. OTOH, if there is only one reasonable way to implement it =
then why is it not defined in the standard?<br></blockquote><div><br></div>=
<div>Implementation-defined behavior is required to be documented, so you c=
an very quickly check whether any "weird stuff" is on the cards. =
And for the most part it is detectable at compile time by user code.</div><=
div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
As long as I'm in the non-portable land, I can do whatever hacks the pa=
rticular compiler allows to get the job done. But I don't consider that=
a good thing that every other developer should do in their code. Therefore=
I want this very basic thing, integer conversion, to "just work"=
and produce portable well-defined results, unsurprising to most users. Nat=
urally, if integer conversion is defined to work the way we expect (i.e. to=
be equivalent to memcpy) the memcpy trick becomes unnecessary.</blockquote=
><div><br></div><div>If you're writing low-level code such as is depend=
ent on unsigned-to-signed conversion, you will tune your code to implementa=
tions so it will not be strictly conforming anyway.=C2=A0</div></div></div>=
</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJnLdObvtL3M_aT26zTgULEFXO19vAniZ09e=
Q1qs1HtzhNbKGQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdObvtL3M_aT2=
6zTgULEFXO19vAniZ09eQ1qs1HtzhNbKGQ%40mail.gmail.com</a>.<br />
--001a11417f2a8ff87505663343b4--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Tue, 27 Feb 2018 10:03:08 -0800
Raw View
--001a114edde46b40b70566357065
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tue, Feb 27, 2018 at 7:27 AM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> On Tue, Feb 27, 2018 at 12:07 PM, Andrey Semashev <
> andrey.semashev@gmail.com> wrote:
>
>> On 02/27/18 14:19, 'Edward Catmur' via ISO C++ Standard - Future
>> Proposals wrote:
>>>
>>>
>>> Negating 9223372036854775808 in unsigned gives 9223372036854775808,
>>> which happens to be the result of converting -9223372036854775808 into
>>> (64-bit) unsigned. So provided a round-trip guarantee and that
>>> -9223372036854775808 is a value in the signed type, which it is for 64-=
bit
>>> two's complement, 9223372036854775808 in unsigned would convert to
>>> -9223372036854775808 in signed. That is, -9223372036854775808 would be
>>> guaranteed to result in -9223372036854775808 if that value exists in th=
e
>>> signed type.
>>>
>>
>> No, the roundtrip guarantee does not provide the guarantee that the
>> resulting signed value will be -9223372036854775808. In other words, the
>> roundtrip guarantee is this:
>>
>> unsigned long long x1 =3D 9223372036854775808;
>> signed long long x2 =3D x1; // x2 value is unknown. trap, possibly?
>> unsigned long long x3 =3D x2; // x3 =3D=3D x1
>>
>> What I really want, and what the original example requires, is that x2 i=
s
>> guaranteed to have value -9223372036854775808 and nothing else.
>>
>
> If x3 =3D=3D x1, then x2 must have had the value -9223372036854775808 and=
it
> cannot have been a trap representation. There is no other value in signed
> 64-bit that converts to 9223372036854775808.
>
I observe that you two may be miscommunicating your premises. Andrey, it
seems that you want the expression `int64_t(-9223372036854775808)` to
evaluate to the numeric value -9223372036854775808. Edward, IIUC, you're
talking about present-day standard C++, where it is possible that the
number -9223372036854775808 is not representable in `int64_t` at all =E2=80=
=94 in
which case clearly Andrey's goal is impossible. Andrey can't make
`int64_t(-9223372036854775808)` evaluate to -9223372036854775808 if there
is no such value in `int64_t`.
In both JF Bastien's P0907R0 and my "conservative" tweak of it, we are both
proposing that the number -9223372036854775808 should be representable in
future-C++. I think this is a useful property that programmers will enjoy
relying upon.
Edward, do you happen to have first-hand experience with any C++ platform
where -9223372036854775808 is not representable in `int64_t`? (Any
second-hand knowledge of such platforms?) This could be valuable input to
the discussion around P0907R0.
Actually, this raises an issue with your paper: you appear to have left
> open whether values of the form 0x80... (such as -9223372036854775808)
> are trap representations. Was this intentional, or have I missed somethin=
g?
>
I am not sure what JF's intention is, but my guess is that he intends
integral types to have no trap representations at all.
Certainly, my own intention is for integral types to have no trap
representations at all. However, I admit that I tried and failed to figure
out where that wording lives.
What chain of reasoning in the present-day C++ standard do you think
permits implementations to make 0x80... a trap representation? If you can
point to a surviving loophole, I will do my best to close it up.
https://quuxplusone.github.io/draft/twosc-conservative.html#word
=E2=80=93Arthur
P.S.:
As long as the conversion is implementation-defined, the tests would only
>> verify that the implementation is doing what we expect. While that sort =
of
>> protects from unexpected results (as long as the tests are run by the
>> users), that is not what I would like to have as a library developer. I
>> want to be able to say to my users what will be the result of operations=
of
>> my library and I can't do that if I use implementation-defined or undefi=
ned
>> behavior in my implementation.
>>
>
> You absolutely can; you either test at compile time that the
> implementation-defined behavior enables your approach, or you test that t=
he
> implementation is one documented to behave as you require. Or you ask you=
r
> users to do so.
>
This suggestion smells like the awkward `std::endian
<http://en.cppreference.com/w/cpp/types/endian>` feature from the C++2a
working draft. Down this road lies `if constexpr
(std::integer_representation =3D=3D std::twos_complement)` and so on. I wou=
ld
much rather just cut out the problem at the root, given the empirical
dearth (absence?) of present-day C++ implementations that are not
two's-complement. (Endianness is different because there empirically *do*
exist both big-endian and little-endian systems.)
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0KvcaSQvuUOAyaXwhOG_v9%2BYTK79Pec1e9bAQ7n1=
viDpg%40mail.gmail.com.
--001a114edde46b40b70566357065
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Feb 27, 2018 at 7:27 AM, 'Edward Catmur' v=
ia ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"mai=
lto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a=
>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><div><div class=3D"gmail-h5">On Tue, Feb 27, 2018 at 12:07=
PM, Andrey Semashev <span dir=3D"ltr"><<a href=3D"mailto:andrey.semashe=
v@gmail.com" target=3D"_blank">andrey.semashev@gmail.com</a>></span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204=
,204);padding-left:1ex">On 02/27/18 14:19, 'Edward Catmur' via ISO =
C++ Standard - Future Proposals wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:soli=
d;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
Negating 9223372036854775808=C2=A0in unsigned gives 9223372036854775808, wh=
ich happens to be the result of converting -9223372036854775808=C2=A0into (=
64-bit) unsigned. So provided a round-trip guarantee and that -922337203685=
4775808=C2=A0is a value in the signed type, which it is for 64-bit two'=
s complement, 9223372036854775808=C2=A0in unsigned would convert to -922337=
2036854775808=C2=A0in signed. That is, -9223372036854775808=C2=A0would be g=
uaranteed to result in -9223372036854775808 if that value exists in the sig=
ned type.<br>
</blockquote>
<br>
No, the roundtrip guarantee does not provide the guarantee that the resulti=
ng signed value will be -9223372036854775808. In other words, the roundtrip=
guarantee is this:<br>
<br>
=C2=A0 unsigned long long x1 =3D 9223372036854775808;<br>
=C2=A0 signed long long x2 =3D x1; // x2 value is unknown. trap, possibly?<=
br>
=C2=A0 unsigned long long x3 =3D x2; // x3 =3D=3D x1<br>
<br>
What I really want, and what the original example requires, is that x2 is g=
uaranteed to have value -9223372036854775808 and nothing else.<br></blockqu=
ote><div><br></div></div></div><div>If x3 =3D=3D x1, then x2 must have had =
the value=C2=A0<span style=3D"color:rgb(34,34,34);font-family:arial,sans-se=
rif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-va=
riant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;te=
xt-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;backg=
round-color:rgb(255,255,255);float:none;display:inline">-922337203685477580=
8 and it cannot have been a trap representation. There is no other value in=
signed 64-bit that converts to=C2=A0<span style=3D"color:rgb(34,34,34);fon=
t-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-li=
gatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:norm=
al;text-align:start;text-indent:0px;text-transform:none;white-space:normal;=
word-spacing:0px;background-color:rgb(255,255,255);float:none;display:inlin=
e">9223372036854775808.</span></span></div></div></div></div></blockquote><=
div><br></div><div>I observe that you two may be miscommunicating your prem=
ises. Andrey, it seems that you want the expression `int64_t(-9223372036854=
775808)` to evaluate=C2=A0to the numeric value -9223372036854775808. Edward=
, IIUC, you're talking about present-day standard C++, where it is poss=
ible that the number -9223372036854775808 is not representable in `int64_t`=
at all =E2=80=94 in which case clearly Andrey's goal is impossible. An=
drey can't make `int64_t(-9223372036854775808)` evaluate to -9223372036=
854775808 if there is no such value in `int64_t`.</div><div><br></div><div>=
In both JF Bastien's P0907R0 and my "conservative" tweak of i=
t, we are both proposing that the number -9223372036854775808 should be rep=
resentable in future-C++. I think this is a useful property that programmer=
s will enjoy relying upon.</div><div><br></div><div>Edward, do you happen t=
o have first-hand experience with any C++ platform where -92233720368547758=
08 is not representable in `int64_t`? =C2=A0(Any second-hand knowledge of s=
uch platforms?) =C2=A0This could be valuable input to the discussion around=
P0907R0.</div><div><br></div><div><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-sty=
le:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Actually, th=
is raises an issue with your paper: you appear to have left open whether va=
lues of the form 0x80... (such as=C2=A0<span style=3D"font-variant-ligature=
s:normal"><span style=3D"font-variant-ligatures:normal">-922337203685477580=
8) are trap representations. Was this intentional, or have I missed somethi=
ng?</span></span></div></div></div></div></blockquote><div><br></div><div>I=
am not sure what JF's intention is, but my guess is that he intends in=
tegral types to have no trap representations at all.</div><div>Certainly, m=
y own intention is for integral types to have no trap representations at al=
l. However, I admit that I tried and failed to figure out where that wordin=
g lives.</div><div>What chain of reasoning in the present-day C++ standard =
do you think permits implementations to make 0x80... a trap representation?=
=C2=A0 If you can point to a surviving loophole, I will do my best to close=
it up.</div><div><a href=3D"https://quuxplusone.github.io/draft/twosc-cons=
ervative.html#word">https://quuxplusone.github.io/draft/twosc-conservative.=
html#word</a><br></div><div><br></div><div>=E2=80=93Arthur</div><div><br></=
div><div>P.S.:</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"gmail-"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padd=
ing-left:1ex">As long as the conversion is implementation-defined, the test=
s would only verify that the implementation is doing what we expect. While =
that sort of protects from unexpected results (as long as the tests are run=
by the users), that is not what I would like to have as a library develope=
r. I want to be able to say to my users what will be the result of operatio=
ns of my library and I can't do that if I use implementation-defined or=
undefined behavior in my implementation.<br></blockquote><div><br></div></=
span><div>You absolutely can; you either test at compile time that the impl=
ementation-defined behavior enables your approach, or you test that the imp=
lementation is one documented to behave as you require. Or you ask your use=
rs to do so.</div></div></div></div></blockquote><div><br></div><div>This s=
uggestion smells like the awkward `<a href=3D"http://en.cppreference.com/w/=
cpp/types/endian">std::endian</a>` feature from the C++2a working draft. Do=
wn this road lies `if constexpr (std::integer_representation =3D=3D std::tw=
os_complement)` and so on. I would much rather just cut out the problem at =
the root, given the empirical dearth (absence?) of present-day C++ implemen=
tations that are not two's-complement. =C2=A0(Endianness is different b=
ecause there empirically <i>do</i> exist both big-endian and little-endian =
systems.)</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0KvcaSQvuUOAyaXwhOG_v9%2BYTK79P=
ec1e9bAQ7n1viDpg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0KvcaSQvu=
UOAyaXwhOG_v9%2BYTK79Pec1e9bAQ7n1viDpg%40mail.gmail.com</a>.<br />
--001a114edde46b40b70566357065--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Tue, 27 Feb 2018 21:36:10 +0300
Raw View
On 02/27/18 18:27, 'Edward Catmur' via ISO C++ Standard - Future=20
Proposals wrote:
> On Tue, Feb 27, 2018 at 12:07 PM, Andrey Semashev=20
> <andrey.semashev@gmail.com <mailto:andrey.semashev@gmail.com>> wrote:
>=20
> No, the roundtrip guarantee does not provide the guarantee that the
> resulting signed value will be -9223372036854775808. In other words,
> the roundtrip guarantee is this:
>=20
> =C2=A0 unsigned long long x1 =3D 9223372036854775808;
> =C2=A0 signed long long x2 =3D x1; // x2 value is unknown. trap, pos=
sibly?
> =C2=A0 unsigned long long x3 =3D x2; // x3 =3D=3D x1
>=20
> What I really want, and what the original example requires, is that
> x2 is guaranteed to have value -9223372036854775808 and nothing else.
>=20
> If x3 =3D=3D x1, then x2 must have had the value -9223372036854775808 and=
it=20
> cannot have been a trap representation. There is no other value in=20
> signed 64-bit that converts to 9223372036854775808.
I don't think so. For example, the implementation could produce a trap=20
value that it is able to convert back to 9223372036854775808 unsigned=20
but using it in any other context would result in a trap.
> Actually, this raises an issue with your paper: you appear to have left=
=20
> open whether values of the form 0x80... (such as -9223372036854775808)=20
> are trap representations. Was this intentional, or have I missed somethin=
g?
I have not presented a paper in this thread. The two mentioned papers=20
were from Arthur and JF Bastien. But as I understand Arthur's proposal,=20
it doesn't prohibit trap representations or padding bits. Let Arthur=20
correct me if I'm wrong.
> Compiler intrinsics or inline assembler are not portable. I want
> this ability in portable legal C++.
>=20
> The intrinsics are available on every actively maintained compiler, and=
=20
> result in clearer and more efficient code. There is little point in=20
> expanding the space of strictly conforming programs if they are slow and=
=20
> abstruse. It would be far better to standardize the intrinsics.
The only relevant intrinsics I'm aware of are gcc's overflow=20
intrinsics[1], which appeared in gcc 7, IIRC. This is one compiler, a=20
very recent version, too. Also, note that gcc supports only two's=20
complement signed integers.
As for standardizing intrinsics, or rather function wrappers, I don't=20
think this is the right interface for such functionality.
[1]: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
> As long as the conversion is implementation-defined, the tests would
> only verify that the implementation is doing what we expect. While
> that sort of protects from unexpected results (as long as the tests
> are run by the users), that is not what I would like to have as a
> library developer. I want to be able to say to my users what will be
> the result of operations of my library and I can't do that if I use
> implementation-defined or undefined behavior in my implementation.
>=20
> You absolutely can; you either test at compile time that the=20
> implementation-defined behavior enables your approach, or you test that=
=20
> the implementation is one documented to behave as you require.
As a library author, I cannot reasonably inspect every compiler's=20
documentation to find out if it does something fancy on integer=20
conversion. And I shouldn't have to. We have the standard to tell us=20
what should happen and currently it tells us anything could happen, as=20
long as it is documented.
> Or you ask your users to do so.
In other words, shift responsibility further down the line.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0cb74826-7953-5300-80ef-da92183fb15d%40gmail.com=
..
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Tue, 27 Feb 2018 22:42:32 +0300
Raw View
On 02/27/18 21:03, Arthur O'Dwyer wrote:
> On Tue, Feb 27, 2018 at 7:27 AM, 'Edward Catmur' via ISO C++ Standard -=
=20
> Future Proposals <std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>> wrote:
>=20
> Actually, this raises an issue with your paper: you appear to have
> left open whether values of the form 0x80... (such as
> -9223372036854775808) are trap representations. Was this
> intentional, or have I missed something?
>=20
> I am not sure what JF's intention is, but my guess is that he intends=20
> integral types to have no trap representations at all.
> Certainly, my own intention is for integral types to have no trap=20
> representations at all. However, I admit that I tried and failed to=20
> figure out where that wording lives.
> What chain of reasoning in the present-day C++ standard do you think=20
> permits implementations to make 0x80... a trap representation?=C2=A0 If y=
ou=20
> can point to a surviving loophole, I will do my best to close it up.
> https://quuxplusone.github.io/draft/twosc-conservative.html#word
As I understand it, it follows from [basic.types]/4, which explicitly=20
separates object representation and value representation; the bits that=20
are part of object representation but not value representation are=20
called padding bits.
Further, [basic.fundamental] does not require value and object=20
representation to match for integral types, except narrow character=20
types. [basic.fundamental]/3 refers to the C standard section 5.2.4.2.1,=20
which defines integral limits and then refers to section 6.2.6 that=20
defines representation of types. 6.2.6.2 defines integer types and=20
paragraph 2 explicitly mentions padding bits.
Regarding trap bits, I didn't see a clause that explicitly allows them=20
to be in the object representation of integral types, but I didn't see=20
one that prohibits them. But there is `std::numeric_limits<T>::traps`=20
member ([numeric.limits.members]/64), which is said to be meaningful for=20
all types, including integers.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/cb35d432-80b0-febf-6796-dcbd926ce9a1%40gmail.com=
..
.
Author: John McFarlane <john@mcfarlane.name>
Date: Tue, 27 Feb 2018 20:58:34 +0000
Raw View
--001a11457ec67a6481056637e481
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, Feb 26, 2018 at 9:37 AM JF Bastien <jfbastien@apple.com> wrote:
> These are true, but then the current undefined behavior on signed overflo=
w
>> has some unmentioned good effects, too:
>>
>> - Unintentional unsigned wraparound (for example, in the argument to
>> `malloc`) has been a known source of bugs for a long time. See for examp=
le
>> [Regehr2012] <https://www.cs.utah.edu/~regehr/papers/overflow12.pdf>,
>> whose final sentence is, "Our results also imply that tools for detectin=
g
>> integer numerical errors need to *distinguish intentional from
>> unintentional uses of wraparound operations* =E2=80=94 a challenging tas=
k =E2=80=94 in
>> order to minimize false alarms. [emphasis added]" The current
>> undefinedness of signed overflow permits implementations, such as UBSan,=
to
>> detect all signed wraparound behavior as unintentional by definition, an=
d
>> diagnose it accordingly.
>>
>>
>> unsigned wraparound isn=E2=80=99t UB, and I claim that signed overflow i=
s UB
>> because of the 3 representation, not to catch bugs, otherwise unsigned
>> overflow would also have been UB. [...] I claim that this is also an
>> emergent feature, not by design, caused by the 3 signed integer
>> representations.
>>
>
> I think you are right in the historical sense. These days the emergent
> "catch bugs" rationale has survived, though, even as the exotic hardwares
> have died out.
>
>
> Sure, I just think it=E2=80=99s unprincipled in where it=E2=80=99s applie=
d because it=E2=80=99s
> only applied through historical accidents. That=E2=80=99s highly non-intu=
itive:
> "where can I catch bugs? Where there used to be hardware variance!=E2=80=
=9D How do
> we expect newcomers to learn C++? We can=E2=80=99t just say =E2=80=9CC++ =
offers a direct
> map to hardware=E2=80=9D, and =E2=80=9CC++ leaves no room for a language =
between itself and
> hardware=E2=80=9D, because in many cases it=E2=80=99s just not true. Two=
=E2=80=99s complement
> hardware just wraps signed integers.
>
IIUC, two's complement hardware does not *just* wrap signed integers. It
also sets the carry flag so that multi-word integer arithmetic can be
performed efficiently. In other words, it does not wrap integers because
they are in any sense "circular" but because that is how you perform long
addition, long multiplication etc.. Hence the view that it's unsigned
integers which break a hardware-level abstraction and not signed integers
which impose a language-level abstraction.
I=E2=80=99d much rather have a principled approach, say a library integer w=
hich can
> wrap / trap / saturate / UB. There=E2=80=99s a proposal for saturation, a=
nd I think
> the committee will take my paper and offer guidance on what a principled
> approach will be.
>
> +1
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CABPJVnRD-P0DvOWuxJUgxUYH5u99qpr2oyZ4ncfWNn-cJt%=
3Dw9w%40mail.gmail.com.
--001a11457ec67a6481056637e481
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Feb 26=
, 2018 at 9:37 AM JF Bastien <<a href=3D"mailto:jfbastien@apple.com" tar=
get=3D"_blank">jfbastien@apple.com</a>> wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div style=3D"word-wrap:break-word;line-break:after-white-sp=
ace"><div><blockquote type=3D"cite"><div><div dir=3D"ltr"><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid=
;border-left-color:rgb(204,204,204);padding-left:1ex"><div style=3D"word-wr=
ap:break-word;line-break:after-white-space"><div><span class=3D"m_-52352161=
92252494980m_4123980029995797018m_-5098254893511035267gmail-"><blockquote t=
ype=3D"cite"><div><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D=
"gmail_quote"><div>These are true, but then the current undefined behavior =
on signed overflow has some unmentioned good effects, too:</div><div><br></=
div><div>- Unintentional unsigned wraparound (for example, in the argument =
to `malloc`) has been a known source of bugs for a long time. See for examp=
le <a href=3D"https://www.cs.utah.edu/~regehr/papers/overflow12.pdf" target=
=3D"_blank">[Regehr2012]</a>, whose final sentence is, "Our results al=
so imply that tools for detecting integer numerical errors need to <b><i>di=
stinguish intentional from unintentional uses of wraparound operations</i><=
/b> =E2=80=94 a challenging task =E2=80=94 in order to minimize false alarm=
s. [emphasis added]" =C2=A0The current undefinedness of signed overflo=
w permits implementations, such as UBSan, to detect all signed wraparound b=
ehavior as unintentional by definition, and diagnose it accordingly.</div><=
/div></div></div></div></blockquote><div><br></div></span><div>unsigned wra=
paround isn=E2=80=99t UB, and I claim that signed overflow is UB because of=
the 3 representation, not to catch bugs, otherwise unsigned overflow would=
also have been UB. [...] I claim that this is also an emergent feature, no=
t by design, caused by the 3 signed integer representations.</div></div></d=
iv></blockquote><div>=C2=A0</div><div>I think you are right in the historic=
al sense. These days the emergent "catch bugs" rationale has surv=
ived, though, even as the exotic hardwares have died out.</div></div></div>=
</div></div></blockquote><div><br></div></div></div><div style=3D"word-wrap=
:break-word;line-break:after-white-space"><div><div>Sure, I just think it=
=E2=80=99s unprincipled in where it=E2=80=99s applied because it=E2=80=99s =
only applied through historical accidents. That=E2=80=99s highly non-intuit=
ive: "where can I catch bugs? Where there used to be hardware variance=
!=E2=80=9D How do we expect newcomers to learn C++? We can=E2=80=99t just s=
ay =E2=80=9CC++ offers a direct map to hardware=E2=80=9D, and =E2=80=9CC++ =
leaves no room for a language between itself and hardware=E2=80=9D, because=
in many cases it=E2=80=99s just not true. Two=E2=80=99s complement hardwar=
e just wraps signed integers.</div></div></div></blockquote></div><div dir=
=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quote"><div><br>IIUC, two'=
;s complement hardware does not *just* wrap signed integers. It also sets t=
he carry flag so that multi-word integer arithmetic can be performed effici=
ently. In other words, it does not wrap integers because they are in any se=
nse "circular" but because that is how you perform long addition,=
long multiplication etc.. Hence the view that it's unsigned integers w=
hich break a hardware-level abstraction and not signed integers which impos=
e a language-level abstraction.<br></div></div></div></div><div dir=3D"ltr"=
><div dir=3D"ltr"><div class=3D"gmail_quote"><br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div style=3D"word-wrap:break-word;line-break:after-white-space"><div>=
<div>I=E2=80=99d much rather have a principled approach, say a library inte=
ger which can wrap / trap / saturate / UB. There=E2=80=99s a proposal for s=
aturation, and I think the committee will take my paper and offer guidance =
on what a principled approach will be.</div></div></div><div style=3D"word-=
wrap:break-word;line-break:after-white-space"><div><div><br></div></div></d=
iv></blockquote></div></div></div><div dir=3D"ltr"><div dir=3D"ltr"><div cl=
ass=3D"gmail_quote"><div>+1<br></div></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CABPJVnRD-P0DvOWuxJUgxUYH5u99qpr2oyZ4=
ncfWNn-cJt%3Dw9w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABPJVnRD-P0DvO=
WuxJUgxUYH5u99qpr2oyZ4ncfWNn-cJt%3Dw9w%40mail.gmail.com</a>.<br />
--001a11457ec67a6481056637e481--
.
Author: Chris Hallock <christopherhallock@gmail.com>
Date: Tue, 27 Feb 2018 15:32:44 -0800 (PST)
Raw View
------=_Part_3138_1250156940.1519774364168
Content-Type: multipart/alternative;
boundary="----=_Part_3139_197576994.1519774364168"
------=_Part_3139_197576994.1519774364168
Content-Type: text/plain; charset="UTF-8"
On Monday, February 26, 2018 at 7:35:13 PM UTC-5, Andrey Semashev wrote:
>
> On 02/27/18 02:22, Arthur O'Dwyer wrote:
> >
> > Unsigned-to-signed conversion is UB only when there are enum types
> involved.
> > I have added two tables to my paper that explain the current situation
> > and the proposed situation(s), with examples:
> > https://quuxplusone.github.io/draft/twosc-conservative.html#intro
>
> You may want to add a peculiar use case to the proposal: IIUC, it should
> fix the overflow caused by the expression:
>
> long long x = -9223372036854775808;
>
> (Explanation: the 9223372036854775808 literal is a 64-bit number with
> the most significant bit set; this number does not fit in 64-bit signed
> long long, but does fit in unsigned. The result of the negation is still
> unsigned, 9223372036854775808, which still cannot be stored in the
> signed long long without invoking implementation-defined behavior. The
> peculiar part is that the negative value -9223372036854775808, which the
> user intended from the start, is representable in two's complement
> signed long long.)
>
Strictly speaking, 9223372036854775808 is ill-formed on current
implementations because its form (decimal literal with no suffix) restricts
it to signed, but no signed type is big enough; see [lex.icon]/2-3
<https://timsong-cpp.github.io/cppwp/lex.icon#2>. GCC and Clang correctly
issue a warning (or error, under -pedantic-errors) for this.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/09c8caec-12e1-4327-93ca-1771202cb367%40isocpp.org.
------=_Part_3139_197576994.1519774364168
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, February 26, 2018 at 7:35:13 PM UTC-5, =
Andrey Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 02/27=
/18 02:22, Arthur O'Dwyer wrote:
<br>>=20
<br>> Unsigned-to-signed conversion is UB only when there are enum types=
involved.
<br>> I have added two tables to my paper that explain the current situa=
tion=20
<br>> and the proposed situation(s), with examples:
<br>> <a href=3D"https://quuxplusone.github.io/draft/twosc-conservative.=
html#intro" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fquuxplusone.github.io%2Fd=
raft%2Ftwosc-conservative.html%23intro\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAF=
QjCNGzP1Di52_AlEADhuY_FCSRPWqsNA';return true;" onclick=3D"this.href=3D=
'https://www.google.com/url?q\x3dhttps%3A%2F%2Fquuxplusone.github.io%2F=
draft%2Ftwosc-conservative.html%23intro\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dA=
FQjCNGzP1Di52_AlEADhuY_FCSRPWqsNA';return true;">https://quuxplusone.gi=
thub.io/<wbr>draft/twosc-conservative.html#<wbr>intro</a>
<br>
<br>You may want to add a peculiar use case to the proposal: IIUC, it shoul=
d=20
<br>fix the overflow caused by the expression:
<br>
<br>=C2=A0 =C2=A0long long x =3D -9223372036854775808;
<br>
<br>(Explanation: the 9223372036854775808 literal is a 64-bit number with=
=20
<br>the most significant bit set; this number does not fit in 64-bit signed=
=20
<br>long long, but does fit in unsigned. The result of the negation is stil=
l=20
<br>unsigned, 9223372036854775808, which still cannot be stored in the=20
<br>signed long long without invoking implementation-defined behavior. The=
=20
<br>peculiar part is that the negative value -9223372036854775808, which th=
e=20
<br>user intended from the start, is representable in two's complement=
=20
<br>signed long long.)
<br></blockquote><div><br>Strictly speaking, 9223372036854775808 is ill-for=
med on current implementations because its form (decimal literal with no su=
ffix) restricts it to signed, but no signed type is big enough; see <a href=
=3D"https://timsong-cpp.github.io/cppwp/lex.icon#2">[lex.icon]/2-3</a>. GCC=
and Clang correctly issue a warning (or error, under <span style=3D"font-f=
amily: courier\ new, monospace;">-pedantic-errors</span>) for this.<br></di=
v></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/09c8caec-12e1-4327-93ca-1771202cb367%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/09c8caec-12e1-4327-93ca-1771202cb367=
%40isocpp.org</a>.<br />
------=_Part_3139_197576994.1519774364168--
------=_Part_3138_1250156940.1519774364168--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 28 Feb 2018 10:07:42 -0800
Raw View
--001a113d67b29a02e30566499e08
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On 26 Feb 2018 09:50, "Nevin Liber" <nevin@eviloverlord.com> wrote:
On Mon, Feb 26, 2018 at 11:16 AM, JF Bastien <jfbastien@apple.com> wrote:
>
> I=E2=80=99ve asked Chandler but I=E2=80=99ll ask you as well: data would =
be great in
> getting committee consensus. To me =E2=80=9Cfalse positive=E2=80=9D sound=
s an awful lot
> like =E2=80=9Cnot a bug=E2=80=9D in this context :-)
>
I don't understand this line of reasoning. If you consider *unsigned*
wrapping detection to be a good thing in the sanitizer (I assume that is
what you mean by "not a bug"), why on earth do you want *signed* overflow
to wrap? Do you expect sanitizers to detect this? If so, why make it
legitimate behavior?
Without wrapping, I don't see enough motivation to change the status quo,
especially since it needlessly introduces an incompatibility with C. And I
certainly don't see how this is in the "top 20" things for C++20.
IMO, if the sanitizers are giving false positives, they should remove the
misleading bit about no false positives as a goal in the documentation <
https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.
html#issue-suppression>.
This sanitizer is not part of ubsan, so that comment does not apply to it.
(For example, it is not enabled by -fsanitize=3Dundefined.)
If that attribute suppresses -fsanitize=3Dunsigned-integer-overflow, I'd
consider that a bug. We should have a different suppression mechanism for
sanitizer complaints on code with defined behaviour.
--=20
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
<(847)%20691-1404>
--=20
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/
isocpp.org/d/msgid/std-proposals/CAGg_6%2BOp%3DC0FtNeJ4MY7NTKZBiYP76U-
HCyp3%3DGYhYf11HHtvQ%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOp%3=
DC0FtNeJ4MY7NTKZBiYP76U-HCyp3%3DGYhYf11HHtvQ%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
..
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOfiQqng-wV5bzYJqvhLOMbWRe2G989YmuDF06D4VY7OKA%=
2BfWQ%40mail.gmail.com.
--001a113d67b29a02e30566499e08
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote=
">On 26 Feb 2018 09:50, "Nevin Liber" <<a href=3D"mailto:nevin=
@eviloverlord.com">nevin@eviloverlord.com</a>> wrote:<br type=3D"attribu=
tion"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"quoted-text">=
On Mon, Feb 26, 2018 at 11:16 AM, JF Bastien <span dir=3D"ltr"><<a href=
=3D"mailto:jfbastien@apple.com" target=3D"_blank">jfbastien@apple.com</a>&g=
t;</span> wrote:<br></div><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><div class=3D"quoted-text"><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bord=
er-left-color:rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:br=
eak-word;line-break:after-white-space"><br><div><div>I=E2=80=99ve asked Cha=
ndler but I=E2=80=99ll ask you as well: data would be great in getting comm=
ittee consensus. To me =E2=80=9Cfalse positive=E2=80=9D sounds an awful lot=
like =E2=80=9Cnot a bug=E2=80=9D in this context :-)</div></div></div></bl=
ockquote><div><br></div></div><div>I don't understand this line of reas=
oning.=C2=A0 If you consider <i>unsigned</i> wrapping detection to be a goo=
d thing in the sanitizer (I assume that is what you mean by "not a bug=
"), why on earth do you want <i>signed</i> overflow to wrap?=C2=A0 Do =
you expect sanitizers to detect this?=C2=A0 If so, why make it legitimate b=
ehavior?</div><div><br></div><div>Without wrapping, I don't see enough =
motivation to change the status quo, especially since it needlessly introdu=
ces an incompatibility with C.=C2=A0 And I certainly don't see how this=
is in the "top 20" things for C++20.</div><div><br></div><div><b=
r></div><div>IMO, if the sanitizers are giving false positives, they should=
remove the misleading bit about no false positives as a goal in the docume=
ntation <<a href=3D"https://clang.llvm.org/docs/UndefinedBehaviorSanitiz=
er.html#issue-suppression" target=3D"_blank">https://clang.llvm.org/docs/<w=
br>UndefinedBehaviorSanitizer.<wbr>html#issue-suppression</a>>.</div></d=
iv></div></div></blockquote></div></div></div><div dir=3D"auto"><br></div><=
div dir=3D"auto">This sanitizer is not part of ubsan, so that comment does =
not apply to it. (For example, it is not enabled by -fsanitize=3Dundefined.=
)</div><div dir=3D"auto"><br></div><div dir=3D"auto">If that attribute supp=
resses -fsanitize=3Dunsigned-integer-overflow, I'd consider that a bug.=
We should have a different suppression mechanism for sanitizer complaints =
on code with defined behaviour.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote=
class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">-- <br><div class=
=3D"m_3094924780660829990gmail_signature"><div dir=3D"ltr"><div><div dir=3D=
"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"ma=
ilto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a><w=
br>> =C2=A0<a href=3D"tel:(847)%20691-1404" value=3D"+18476911404" targe=
t=3D"_blank">+1-847-691-1404</a></div></div></div></div></div>
</div></div><div class=3D"quoted-text">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOp%3DC0FtNeJ4MY7NTKZBiYP76U-=
HCyp3%3DGYhYf11HHtvQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgi=
d/std-<wbr>proposals/CAGg_6%2BOp%<wbr>3DC0FtNeJ4MY7NTKZBiYP76U-<wbr>HCyp3%3=
DGYhYf11HHtvQ%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqng-wV5bzYJqvhLOMbWRe2G989YmuDF=
06D4VY7OKA%2BfWQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqng-wV5bz=
YJqvhLOMbWRe2G989YmuDF06D4VY7OKA%2BfWQ%40mail.gmail.com</a>.<br />
--001a113d67b29a02e30566499e08--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 28 Feb 2018 10:28:47 -0800
Raw View
--f403043538283a18e9056649eba5
Content-Type: text/plain; charset="UTF-8"
On 27 February 2018 at 10:36, Andrey Semashev <andrey.semashev@gmail.com>
wrote:
> On 02/27/18 18:27, 'Edward Catmur' via ISO C++ Standard - Future Proposals
> wrote:
>
>> On Tue, Feb 27, 2018 at 12:07 PM, Andrey Semashev <
>> andrey.semashev@gmail.com <mailto:andrey.semashev@gmail.com>> wrote:
>>
>> No, the roundtrip guarantee does not provide the guarantee that the
>> resulting signed value will be -9223372036854775808. In other words,
>> the roundtrip guarantee is this:
>>
>> unsigned long long x1 = 9223372036854775808;
>> signed long long x2 = x1; // x2 value is unknown. trap, possibly?
>> unsigned long long x3 = x2; // x3 == x1
>>
>> What I really want, and what the original example requires, is that
>> x2 is guaranteed to have value -9223372036854775808 and nothing else.
>>
>> If x3 == x1, then x2 must have had the value -9223372036854775808 and it
>> cannot have been a trap representation. There is no other value in signed
>> 64-bit that converts to 9223372036854775808.
>>
>
> I don't think so. For example, the implementation could produce a trap
> value that it is able to convert back to 9223372036854775808 unsigned but
> using it in any other context would result in a trap.
>
> Actually, this raises an issue with your paper: you appear to have left
>> open whether values of the form 0x80... (such as -9223372036854775808) are
>> trap representations. Was this intentional, or have I missed something?
>>
>
> I have not presented a paper in this thread. The two mentioned papers were
> from Arthur and JF Bastien. But as I understand Arthur's proposal, it
> doesn't prohibit trap representations or padding bits. Let Arthur correct
> me if I'm wrong.
>
> Compiler intrinsics or inline assembler are not portable. I want
>> this ability in portable legal C++.
>>
>> The intrinsics are available on every actively maintained compiler, and
>> result in clearer and more efficient code. There is little point in
>> expanding the space of strictly conforming programs if they are slow and
>> abstruse. It would be far better to standardize the intrinsics.
>>
>
> The only relevant intrinsics I'm aware of are gcc's overflow
> intrinsics[1], which appeared in gcc 7, IIRC. This is one compiler, a very
> recent version, too.
Actually, these builtins were added in Clang 3.4 (and GCC eventually
implemented compatible builtins); they've been in a production compiler for
several years, and are now available in Clang, in GCC, and in EDG's
Clang-compatible mode (though they're not yet enabled in its GCC-compatible
mode as far as I can tell).
> Also, note that gcc supports only two's complement signed integers.
>
> As for standardizing intrinsics, or rather function wrappers, I don't
> think this is the right interface for such functionality.
>
> [1]: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
>
> As long as the conversion is implementation-defined, the tests would
>> only verify that the implementation is doing what we expect. While
>> that sort of protects from unexpected results (as long as the tests
>> are run by the users), that is not what I would like to have as a
>> library developer. I want to be able to say to my users what will be
>> the result of operations of my library and I can't do that if I use
>> implementation-defined or undefined behavior in my implementation.
>>
>> You absolutely can; you either test at compile time that the
>> implementation-defined behavior enables your approach, or you test that the
>> implementation is one documented to behave as you require.
>>
>
> As a library author, I cannot reasonably inspect every compiler's
> documentation to find out if it does something fancy on integer conversion.
> And I shouldn't have to. We have the standard to tell us what should happen
> and currently it tells us anything could happen, as long as it is
> documented.
>
> Or you ask your users to do so.
>>
>
> In other words, shift responsibility further down the line.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/0cb74826-7953-5300-80ef-
> da92183fb15d%40gmail.com.
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm-7LiwHaHhW47EW%3DV53C%2BOnDXSF54xGqG%2BRxzxSkxczg%40mail.gmail.com.
--f403043538283a18e9056649eba5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
7 February 2018 at 10:36, Andrey Semashev <span dir=3D"ltr"><<a href=3D"=
mailto:andrey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gmail.c=
om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 02/27/18 18:2=
7, 'Edward Catmur' via ISO C++ Standard - Future Proposals wrote:<s=
pan class=3D""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Tue, Feb 27, 2018 at 12:07 PM, Andrey Semashev <<a href=3D"mailto:and=
rey.semashev@gmail.com" target=3D"_blank">andrey.semashev@gmail.com</a> <=
;mailto:<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank">andr=
ey.semashev@gmail.<wbr>com</a>>> wrote:<br>
<br>
=C2=A0 =C2=A0 No, the roundtrip guarantee does not provide the guarantee th=
at the<br>
=C2=A0 =C2=A0 resulting signed value will be -9223372036854775808. In other=
words,<br>
=C2=A0 =C2=A0 the roundtrip guarantee is this:<br>
<br>
=C2=A0 =C2=A0 =C2=A0=C2=A0 unsigned long long x1 =3D 9223372036854775808;<b=
r>
=C2=A0 =C2=A0 =C2=A0=C2=A0 signed long long x2 =3D x1; // x2 value is unkno=
wn. trap, possibly?<br>
=C2=A0 =C2=A0 =C2=A0=C2=A0 unsigned long long x3 =3D x2; // x3 =3D=3D x1<br=
>
<br>
=C2=A0 =C2=A0 What I really want, and what the original example requires, i=
s that<br>
=C2=A0 =C2=A0 x2 is guaranteed to have value -9223372036854775808 and nothi=
ng else.<br>
<br>
If x3 =3D=3D x1, then x2 must have had the value -9223372036854775808 and i=
t cannot have been a trap representation. There is no other value in signed=
64-bit that converts to 9223372036854775808.<br>
</blockquote>
<br></span>
I don't think so. For example, the implementation could produce a trap =
value that it is able to convert back to 9223372036854775808 unsigned but u=
sing it in any other context would result in a trap.<span class=3D""><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Actually, this raises an issue with your paper: you appear to have left ope=
n whether values of the form 0x80... (such as -9223372036854775808) are tra=
p representations. Was this intentional, or have I missed something?<br>
</blockquote>
<br></span>
I have not presented a paper in this thread. The two mentioned papers were =
from Arthur and JF Bastien. But as I understand Arthur's proposal, it d=
oesn't prohibit trap representations or padding bits. Let Arthur correc=
t me if I'm wrong.<span class=3D""><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
=C2=A0 =C2=A0 Compiler intrinsics or inline assembler are not portable. I w=
ant<br>
=C2=A0 =C2=A0 this ability in portable legal C++.<br>
<br>
The intrinsics are available on every actively maintained compiler, and res=
ult in clearer and more efficient code. There is little point in expanding =
the space of strictly conforming programs if they are slow and abstruse. It=
would be far better to standardize the intrinsics.<br>
</blockquote>
<br></span>
The only relevant intrinsics I'm aware of are gcc's overflow intrin=
sics[1], which appeared in gcc 7, IIRC. This is one compiler, a very recent=
version, too.</blockquote><div><br></div><div>Actually, these builtins wer=
e added in Clang 3.4 (and GCC eventually implemented compatible builtins); =
they've been in a production compiler for several years, and are now av=
ailable in Clang, in GCC, and in EDG's Clang-compatible mode (though th=
ey're not yet enabled in its GCC-compatible mode as far as I can tell).=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also, note that gcc s=
upports only two's complement signed integers.<br>
<br>
As for standardizing intrinsics, or rather function wrappers, I don't t=
hink this is the right interface for such functionality.<br>
<br>
[1]: <a href=3D"https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtin=
s.html" rel=3D"noreferrer" target=3D"_blank">https://gcc.gnu.org/onlinedocs=
<wbr>/gcc/Integer-Overflow-<wbr>Builtins.html</a><span class=3D""><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
=C2=A0 =C2=A0 As long as the conversion is implementation-defined, the test=
s would<br>
=C2=A0 =C2=A0 only verify that the implementation is doing what we expect. =
While<br>
=C2=A0 =C2=A0 that sort of protects from unexpected results (as long as the=
tests<br>
=C2=A0 =C2=A0 are run by the users), that is not what I would like to have =
as a<br>
=C2=A0 =C2=A0 library developer. I want to be able to say to my users what =
will be<br>
=C2=A0 =C2=A0 the result of operations of my library and I can't do tha=
t if I use<br>
=C2=A0 =C2=A0 implementation-defined or undefined behavior in my implementa=
tion.<br>
<br>
You absolutely can; you either test at compile time that the implementation=
-defined behavior enables your approach, or you test that the implementatio=
n is one documented to behave as you require.<br>
</blockquote>
<br></span>
As a library author, I cannot reasonably inspect every compiler's docum=
entation to find out if it does something fancy on integer conversion. And =
I shouldn't have to. We have the standard to tell us what should happen=
and currently it tells us anything could happen, as long as it is document=
ed.<span class=3D""><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Or you ask your users to do so.<br>
</blockquote>
<br></span>
In other words, shift responsibility further down the line.<span class=3D""=
><br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0cb74826-7953-5300-80ef-da92183fb15d%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/0cb74826-7953-5300-80ef-<wbr>=
da92183fb15d%40gmail.com</a>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm-7LiwHaHhW47EW%3DV53C%2BOnDXS=
F54xGqG%2BRxzxSkxczg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm-7L=
iwHaHhW47EW%3DV53C%2BOnDXSF54xGqG%2BRxzxSkxczg%40mail.gmail.com</a>.<br />
--f403043538283a18e9056649eba5--
.
Author: Myriachan <myriachan@gmail.com>
Date: Wed, 28 Feb 2018 19:29:22 -0800 (PST)
Raw View
------=_Part_377_585151304.1519874963006
Content-Type: multipart/alternative;
boundary="----=_Part_378_101546894.1519874963006"
------=_Part_378_101546894.1519874963006
Content-Type: text/plain; charset="UTF-8"
I haven't had time to review this whole thread, but I saw an error on this
page:
https://quuxplusone.github.io/draft/twosc-conservative.html#intro
"1 << 31 Undefined behavior"
1 << 31 is already well-defined as INT_MIN on two's-complement 32-bit int
systems according to the current Standard:
"Otherwise, if E1 has a signed type and non-negative value, and E1 * 2^E2
is representable in the corresponding unsigned type of the result type,
then that value, converted to the result type, is the resulting value;
otherwise, the behavior is undefined."
1 << 31 is representable in unsigned int on such a system. Thus, it is
already legal to shift a 1 bit into the sign bit when the input was
positive, but you can't go past the sign bit. 1 << 31 == INT_MIN, but 2 <<
31 is undefined behavior.
constexpr int x = 1 << 31; // OK
constexpr int x = 2 << 31; // ill-formed: undefined behavior means
expression is not constant
Melissa
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d2233fa4-6728-4aac-8080-a3c988dbc49a%40isocpp.org.
------=_Part_378_101546894.1519874963006
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I haven't had time to review this whole thread, but I =
saw an error on this page:<br><br>https://quuxplusone.github.io/draft/twosc=
-conservative.html#intro<br><br>"1 << 31=C2=A0=C2=A0=C2=A0=C2=A0=
Undefined behavior"<br><br>1 << 31 is already well-defined as I=
NT_MIN on two's-complement 32-bit int systems according to the current =
Standard:<br><br>"Otherwise, if E1 has a signed type and non-negative =
value, and E1 * 2^E2 is representable in the corresponding unsigned type of=
the result type, then that value, converted to the result type, is the res=
ulting value; otherwise, the behavior is undefined."<br><br>1 <<=
31 is representable in unsigned int on such a system.=C2=A0 Thus, it is al=
ready legal to shift a 1 bit into the sign bit when the input was positive,=
but you can't go past the sign bit.=C2=A0 1 << 31 =3D=3D INT_MIN=
, but 2 << 31 is undefined behavior.<br><br>constexpr int x =3D 1 <=
;< 31;=C2=A0 // OK<br>constexpr int x =3D 2 << 31;=C2=A0 // ill-fo=
rmed: undefined behavior means expression is not constant<br><br>Melissa<br=
></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d2233fa4-6728-4aac-8080-a3c988dbc49a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d2233fa4-6728-4aac-8080-a3c988dbc49a=
%40isocpp.org</a>.<br />
------=_Part_378_101546894.1519874963006--
------=_Part_377_585151304.1519874963006--
.
Author: Myriachan <myriachan@gmail.com>
Date: Wed, 28 Feb 2018 19:32:24 -0800 (PST)
Raw View
------=_Part_407_1887761237.1519875144982
Content-Type: multipart/alternative;
boundary="----=_Part_408_847881391.1519875144982"
------=_Part_408_847881391.1519875144982
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, Feb 26, 2018 at 9:37 AM JF Bastien <jfba...@apple.com <javascript:>=
>=20
wrote:
>
> I=E2=80=99d much rather have a principled approach, say a library integer=
which=20
> can wrap / trap / saturate / UB. There=E2=80=99s a proposal for saturatio=
n, and I=20
> think the committee will take my paper and offer guidance on what a=20
> principled approach will be.
>
>
On these lists before, I've called the modes "snap, trap and wrap". Just a=
=20
convenient English mnemonic for referring to this.
Melissa
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/db327cc6-a2db-4f72-a089-295b6d970f46%40isocpp.or=
g.
------=_Part_408_847881391.1519875144982
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Feb 26, 2018 at 9:37 AM JF Bastien <<a href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"kF7I_JyKAwAJ" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;=
" onclick=3D"this.href=3D'javascript:';return true;">jfba...@apple.=
com</a>> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><br>I=E2=80=99d much rather have a principled approach, say a=
library integer which can wrap / trap / saturate / UB. There=E2=80=99s a p=
roposal for saturation, and I think the committee will take my paper and of=
fer guidance on what a principled approach will be.</div><div dir=3D"ltr"><=
div dir=3D"ltr"><div class=3D"gmail_quote"><div><br></div></div></div></div=
></div></blockquote><div><br>On these lists before, I've called the mod=
es "snap, trap and wrap".=C2=A0 Just a convenient English mnemoni=
c for referring to this.<br><br>Melissa<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/db327cc6-a2db-4f72-a089-295b6d970f46%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/db327cc6-a2db-4f72-a089-295b6d970f46=
%40isocpp.org</a>.<br />
------=_Part_408_847881391.1519875144982--
------=_Part_407_1887761237.1519875144982--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Thu, 1 Mar 2018 00:53:11 -0800
Raw View
--001a114f41805a9123056655fd13
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, Feb 28, 2018 at 7:29 PM, Myriachan <myriachan@gmail.com> wrote:
> I haven't had time to review this whole thread, but I saw an error on thi=
s
> page:
>
> https://quuxplusone.github.io/draft/twosc-conservative.html#intro
>
> "1 << 31 Undefined behavior"
>
> 1 << 31 is already well-defined as INT_MIN on two's-complement 32-bit int
> systems according to the current Standard:
>
> "Otherwise, if E1 has a signed type and non-negative value, and E1 * 2^E2
> is representable *in the corresponding unsigned type* of the result type,
> then that value, converted to the result type, is the resulting value;
> otherwise, the behavior is undefined."
>
Thanks! I have now updated the table to include (2 << 31) as UB, and
changed (1 << 31) to "Implementation-defined value."
I don't think you can safely say that the particular implementation-defined
value in this case *must* be INT_MIN, even on a two's-complement system. It
must be (int)0x80000000u for sure, but the value of that expression is
still implementation-defined, and I don't think there's any hard
requirement that it be defined to exactly INT_MIN on any particular
system. The relevant wording AFAIK is [conv.integral].
Thanks for the correction! This stuff is pretty hairy.
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0Kj%2BqqFfMkxQZkZwoKiTG9Gwx%2B087_hNP0mNov=
zdB5N8Q%40mail.gmail.com.
--001a114f41805a9123056655fd13
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Feb 28, 2018 at 7:29 PM, Myriachan <span dir=3D"lt=
r"><<a href=3D"mailto:myriachan@gmail.com" target=3D"_blank">myriachan@g=
mail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I haven't =
had time to review this whole thread, but I saw an error on this page:<br><=
br><a href=3D"https://quuxplusone.github.io/draft/twosc-conservative.html#i=
ntro" target=3D"_blank">https://quuxplusone.github.io/<wbr>draft/twosc-cons=
ervative.html#<wbr>intro</a><br><br>"1 << 31=C2=A0=C2=A0=C2=A0=
=C2=A0 Undefined behavior"<br><br>1 << 31 is already well-define=
d as INT_MIN on two's-complement 32-bit int systems according to the cu=
rrent Standard:<br><br>"Otherwise, if E1 has a signed type and non-neg=
ative value, and E1 * 2^E2 is representable <b>in the corresponding unsigne=
d type</b> of the result type, then that value, converted to the result typ=
e, is the resulting value; otherwise, the behavior is undefined."<br><=
/div></blockquote><div><br></div><div>Thanks!=C2=A0 I have now updated the =
table to include (2 << 31) as UB, and changed (1 << 31) to &quo=
t;Implementation-defined value."</div><div><br></div><div>I don't =
think you can safely say that the particular implementation-defined value i=
n this case <i>must</i> be INT_MIN, even on a two's-complement system. =
It must be (int)0x80000000u for sure, but the value of that expression is s=
till implementation-defined, and I don't think there's any hard req=
uirement that it be defined to exactly INT_MIN on any particular system.=C2=
=A0 The relevant wording AFAIK is [conv.integral].</div><div><br></div><div=
>Thanks for the correction! This stuff is pretty hairy.</div><div>=E2=80=93=
Arthur</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0Kj%2BqqFfMkxQZkZwoKiTG9Gwx%2B0=
87_hNP0mNovzdB5N8Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0Kj%2Bq=
qFfMkxQZkZwoKiTG9Gwx%2B087_hNP0mNovzdB5N8Q%40mail.gmail.com</a>.<br />
--001a114f41805a9123056655fd13--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Thu, 1 Mar 2018 12:46:22 +0300
Raw View
On 03/01/18 06:29, Myriachan wrote:
> I haven't had time to review this whole thread, but I saw an error on=20
> this page:
>=20
> https://quuxplusone.github.io/draft/twosc-conservative.html#intro
>=20
> "1 << 31=C2=A0=C2=A0=C2=A0=C2=A0 Undefined behavior"
>=20
> 1 << 31 is already well-defined as INT_MIN on two's-complement 32-bit=20
> int systems according to the current Standard:
>=20
> "Otherwise, if E1 has a signed type and non-negative value, and E1 *=20
> 2^E2 is representable in the corresponding unsigned type of the result=20
> type, then that value, converted to the result type, is the resulting=20
> value; otherwise, the behavior is undefined."
>=20
> 1 << 31 is representable in unsigned int on such a system.=C2=A0 Thus, it=
is=20
> already legal to shift a 1 bit into the sign bit when the input was=20
> positive, but you can't go past the sign bit.=C2=A0 1 << 31 =3D=3D INT_MI=
N, but 2=20
> << 31 is undefined behavior.
1 << 31 is implementation-defined then because its result, the value of=20
2147483648, is not representable as a 32-bit signed int.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/dd95aa3d-a9ea-fa44-05d1-c564ae04194a%40gmail.com=
..
.
Author: Valentin Nechayev <netchv@gmail.com>
Date: Sun, 7 Oct 2018 23:07:09 -0700 (PDT)
Raw View
------=_Part_68_1945736116.1538978830049
Content-Type: multipart/alternative;
boundary="----=_Part_69_70253590.1538978830049"
------=_Part_69_70253590.1538978830049
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Saturday, February 24, 2018 at 12:05:20 AM UTC+2, Arthur O'Dwyer wrote:
>
> The pre-JAX mailing contains this discussion-provoking paper by JF Bastie=
n:
> P0907R0 "Signed Integers are Two's Complement"=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html>
>
> My understanding is that JF wants to use this "modest proposal" (for=20
> wrapping arithmetic on `int`, among other things) as a way to incite=20
> discussion among the Committee.
>
It currently looks obvious that neither proposition to reduce C++ area to=
=20
two=CA=BCs-complement machines nor one to fix each integer arithmetic opera=
tion=20
to wrapping mode will succeed. The former looks simply having no=20
strong-grounded aim and the latter drastically reduces optimization=20
opportinuties.
On the other hand, we have good example of local initiative - I mean GCC=20
overflow builtins. Their set is incomplete (at least, narrowing shall be=20
added, and shifts are desired) but exposes the proper trend.=20
Amongst the current proposals, P0103r1 looks the closest to one can=20
succeed, if reduced to minimal required extension set. This includes=20
overflow_{add,sub,mul,cvt}. But the principal thing lacked in P0103r1 is=20
that, if overflow detected, these functions shall still update result value=
=20
with lowest bits of result, the widest that fits into result type. The=20
advantage of such approach is shown in GCC: one will get the truncated=20
(wrapped) value for the only really present case (two=CA=BCs-complement), a=
nd=20
useful guess of real value for other representations. So, adding such=20
requirement is really desired. From compilers=CA=BC side, this would requir=
e=20
minimal efforts but provide basis for any future improvements and,=20
currently, a cumbersome but accessible technique to do the needed things=20
just now.
Another thing that is needed is compile-time provision of detection of=20
signed number representation used at particular platform. Despite we have=
=20
two=CA=BCs-complement in 100% of cases, this is needed to conform to standa=
rd=20
flexibility. This is to be provided using preprocessor macros and useful=20
also for C code.
My proposal concept is here:=20
<https://segfault.kiev.ua/~netch/proposal_cpp_int_arith.html>. It carries=
=20
wording proposal for level 1; ones for higher levels are planned later on. =
=20
Its "level 1" is really a subset of P0103r1 (but planned independently,=20
looking at GCC overflow builtins, and with requirement to save value).=20
Higher levels then could be discussed later on. Level 2 is easy to=20
implement just in library header, provided level 1 is available.
> I have created an as-yet-unofficial "conservative fork" of the proposal,=
=20
> which removes the parts that I think are airballs, while leaving in much =
of=20
> what I consider the good stuff =E2=80=94 notably, making signed-to-unsign=
ed and=20
> unsigned-to-signed conversions well-defined in terms of two's complement=
=20
> representations, and defining what happens when you bit-shift into or out=
=20
> of the sign bit.
> https://quuxplusone.github.io/draft/twosc-conservative.html
>
> I hope that if the Committee asks JF to come back with a more conservativ=
e=20
> proposal, the existence of my "conservative fork" will save time, possibl=
y=20
> even allow further discussion later in the week at JAX.
>
> I personally will not be at JAX, though. JF, will you be? Could I count=
=20
> on you to... not to "champion" my unsubmitted paper, of course, but just =
to=20
> be aware of it in case something like it is asked for by the Committee? =
I=20
> mean, the worst-case, which I would like to avoid, is that JF's paper is=
=20
> rejected as too crazy and then the entire subject is tabled until=20
> Rapperswil. I would like to see some concrete progress in this department=
=20
> at JAX if humanly possible.
>
> =E2=80=93Arthur
>
> P.S. =E2=80=94 Also, if anyone on std-proposals has objections to the spe=
cific=20
> diffs in my conservative proposal, I would like to know about it. I=20
> deliberately tried to remove any whiff of controversy from the diff. (Th=
is=20
> is distinct from objecting to my presumptuousness or objecting to wasting=
=20
> the Committee's time. ;))
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/96dfe6c2-d48d-4ea5-9610-eac2fb26d312%40isocpp.or=
g.
------=_Part_69_70253590.1538978830049
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, February 24, 2018 at 12:05:20 AM UTC+2, Arthu=
r O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>The pre-JAX mailing contains this discussion-provoking paper =
by JF Bastien:</div><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/=
docs/papers/2018/p0907r0.html" target=3D"_blank" rel=3D"nofollow" onmousedo=
wn=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open=
-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp0907r0.html\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE9gMPja1dJR67nv4mPDh4v-ZQqrg';return t=
rue;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F=
%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp0907r0.h=
tml\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE9gMPja1dJR67nv4mPDh4v-ZQqrg=
9;;return true;">P0907R0 "Signed Integers are Two's Complement&quo=
t;</a></div><div><br></div><div>My understanding is that JF wants to use th=
is "modest proposal" (for wrapping arithmetic on `int`, among oth=
er things) as a way to incite discussion among the Committee.</div></div></=
blockquote><div><br></div><div>It currently looks obvious that neither prop=
osition to reduce C++ area to two=CA=BCs-complement machines nor one to fix=
each integer arithmetic operation to wrapping mode will succeed. The forme=
r looks simply having no strong-grounded aim and the latter drastically red=
uces optimization opportinuties.<br><br>On the other hand, we have good exa=
mple of local initiative - I mean GCC overflow builtins. Their set is incom=
plete (at least, narrowing shall be added, and shifts are desired) but expo=
ses the proper trend.=C2=A0</div><div><br>Amongst the current proposals, P0=
103r1 looks the closest to one can succeed, if reduced to minimal required =
extension set. This includes overflow_{add,sub,mul,cvt}. But the principal =
thing lacked in P0103r1 is that, if overflow detected, these functions shal=
l still update result value with lowest bits of result, the widest that fit=
s into result type. The advantage of such approach is shown in GCC: one wil=
l get the truncated (wrapped) value for the only really present case (two=
=CA=BCs-complement), and useful guess of real value for other representatio=
ns. So, adding such requirement is really desired. From compilers=CA=BC sid=
e, this would require minimal efforts but provide basis for any future impr=
ovements and, currently, a cumbersome but accessible technique to do the ne=
eded things just now.<br></div><div><br></div><div>Another thing that is ne=
eded is compile-time provision of detection of signed number representation=
used at particular platform. Despite we have two=CA=BCs-complement in 100%=
of cases, this is needed to conform to standard flexibility. This is to be=
provided using preprocessor macros and useful also for C code.<br><br>My p=
roposal concept is here: <https://segfault.kiev.ua/~netch/proposal_cpp_i=
nt_arith.html>. It carries wording proposal for level 1; ones for higher=
levels are planned later on.=C2=A0 Its "level 1" is really a sub=
set of P0103r1 (but planned independently, looking at GCC overflow builtins=
, and with requirement to save value). Higher levels then could be discusse=
d later on. Level 2 is easy to implement just in library header, provided l=
evel 1 is available.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><br><div>I have created an as-yet-unofficial "c=
onservative fork" of the proposal, which removes the parts that I thin=
k are airballs, while leaving in much of what I consider the good stuff =E2=
=80=94 notably, making signed-to-unsigned and unsigned-to-signed conversion=
s well-defined in terms of two's complement representations, and defini=
ng what happens when you bit-shift into or out of the sign bit.</div><div><=
a href=3D"https://quuxplusone.github.io/draft/twosc-conservative.html" targ=
et=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.=
google.com/url?q\x3dhttps%3A%2F%2Fquuxplusone.github.io%2Fdraft%2Ftwosc-con=
servative.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGs632s2Hzcrh-bIZ84Ct=
8YnIq2zA';return true;" onclick=3D"this.href=3D'https://www.google.=
com/url?q\x3dhttps%3A%2F%2Fquuxplusone.github.io%2Fdraft%2Ftwosc-conservati=
ve.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGs632s2Hzcrh-bIZ84Ct8YnIq2z=
A';return true;">https://quuxplusone.github.io/<wbr>draft/twosc-conserv=
ative.html</a><br></div><div><br></div><div>I hope that if the Committee as=
ks JF to come back with a more conservative proposal, the existence of my &=
quot;conservative fork" will save time, possibly even allow further di=
scussion later in the week at JAX.<br></div><div><br></div><div>I personall=
y will not be at JAX, though.=C2=A0 JF, will you be? Could I count on you t=
o... not to "champion" my unsubmitted paper, of course, but just =
to be aware of it in case something like it is asked for by the Committee?=
=C2=A0 I mean, the worst-case, which I would like to avoid, is that JF'=
s paper is rejected as too crazy and then the entire subject is tabled unti=
l Rapperswil. I would like to see some concrete progress in this department=
at JAX if humanly possible.</div><div><br></div><div>=E2=80=93Arthur</div>=
<div><br></div><div>P.S. =E2=80=94 Also, if anyone on std-proposals has obj=
ections to the specific diffs in my conservative proposal, I would like to =
know about it. I deliberately tried to remove any whiff of controversy from=
the diff. =C2=A0(This is distinct from objecting to my presumptuousness or=
objecting to wasting the Committee's time. ;))</div></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/96dfe6c2-d48d-4ea5-9610-eac2fb26d312%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/96dfe6c2-d48d-4ea5-9610-eac2fb26d312=
%40isocpp.org</a>.<br />
------=_Part_69_70253590.1538978830049--
------=_Part_68_1945736116.1538978830049--
.
Author: JF Bastien <jfbastien@apple.com>
Date: Mon, 08 Oct 2018 09:56:31 -0700
Raw View
--Boundary_(ID_odBoX7uIBpkCM2+o+SLueg)
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
> On Oct 7, 2018, at 11:07 PM, Valentin Nechayev <netchv@gmail.com> wrote:
>=20
> On Saturday, February 24, 2018 at 12:05:20 AM UTC+2, Arthur O'Dwyer wrote=
:
> The pre-JAX mailing contains this discussion-provoking paper by JF Bastie=
n:
> P0907R0 "Signed Integers are Two's Complement" <http://www.open-std.org/j=
tc1/sc22/wg21/docs/papers/2018/p0907r0.html>
>=20
> My understanding is that JF wants to use this "modest proposal" (for wrap=
ping arithmetic on `int`, among other things) as a way to incite discussion=
among the Committee.
>=20
> It currently looks obvious that neither proposition to reduce C++ area to=
two=CA=BCs-complement machines
How so? I see quite the opposite: I expect Jen=E2=80=99s re-worded paper P1=
236 to make it to C++20 in San Diego.
> nor one to fix each integer arithmetic operation to wrapping mode will su=
cceed.
That hasn=E2=80=99t been in papers after r0.
> The former looks simply having no strong-grounded aim and the latter dras=
tically reduces optimization opportinuties.
>=20
> On the other hand, we have good example of local initiative - I mean GCC =
overflow builtins. Their set is incomplete (at least, narrowing shall be ad=
ded, and shifts are desired) but exposes the proper trend.=20
>=20
> Amongst the current proposals, P0103r1 looks the closest to one can succe=
ed, if reduced to minimal required extension set. This includes overflow_{a=
dd,sub,mul,cvt}. But the principal thing lacked in P0103r1 is that, if over=
flow detected, these functions shall still update result value with lowest =
bits of result, the widest that fits into result type. The advantage of suc=
h approach is shown in GCC: one will get the truncated (wrapped) value for =
the only really present case (two=CA=BCs-complement), and useful guess of r=
eal value for other representations. So, adding such requirement is really =
desired. From compilers=CA=BC side, this would require minimal efforts but =
provide basis for any future improvements and, currently, a cumbersome but =
accessible technique to do the needed things just now.
>=20
> Another thing that is needed is compile-time provision of detection of si=
gned number representation used at particular platform. Despite we have two=
=CA=BCs-complement in 100% of cases, this is needed to conform to standard =
flexibility. This is to be provided using preprocessor macros and useful al=
so for C code.
>=20
> My proposal concept is here: <https://segfault.kiev.ua/~netch/proposal_cp=
p_int_arith.html>. It carries wording proposal for level 1; ones for higher=
levels are planned later on. Its "level 1" is really a subset of P0103r1 =
(but planned independently, looking at GCC overflow builtins, and with requ=
irement to save value). Higher levels then could be discussed later on. Lev=
el 2 is easy to implement just in library header, provided level 1 is avail=
able.
>=20
>=20
> I have created an as-yet-unofficial "conservative fork" of the proposal, =
which removes the parts that I think are airballs, while leaving in much of=
what I consider the good stuff =E2=80=94 notably, making signed-to-unsigne=
d and unsigned-to-signed conversions well-defined in terms of two's complem=
ent representations, and defining what happens when you bit-shift into or o=
ut of the sign bit.
> https://quuxplusone.github.io/draft/twosc-conservative.html <https://quux=
plusone.github.io/draft/twosc-conservative.html>
>=20
> I hope that if the Committee asks JF to come back with a more conservativ=
e proposal, the existence of my "conservative fork" will save time, possibl=
y even allow further discussion later in the week at JAX.
>=20
> I personally will not be at JAX, though. JF, will you be? Could I count =
on you to... not to "champion" my unsubmitted paper, of course, but just to=
be aware of it in case something like it is asked for by the Committee? I=
mean, the worst-case, which I would like to avoid, is that JF's paper is r=
ejected as too crazy and then the entire subject is tabled until Rapperswil=
.. I would like to see some concrete progress in this department at JAX if h=
umanly possible.
>=20
> =E2=80=93Arthur
>=20
> P.S. =E2=80=94 Also, if anyone on std-proposals has objections to the spe=
cific diffs in my conservative proposal, I would like to know about it. I d=
eliberately tried to remove any whiff of controversy from the diff. (This =
is distinct from objecting to my presumptuousness or objecting to wasting t=
he Committee's time. ;))
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1E3E0505-D7DA-471D-85E1-170EDD13B659%40apple.com=
..
--Boundary_(ID_odBoX7uIBpkCM2+o+SLueg)
Content-type: text/html; charset="UTF-8"
Content-transfer-encoding: quoted-printable
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; line-break: after-white-space;" class=3D""><br class=3D""><div><br cl=
ass=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Oct 7, 201=
8, at 11:07 PM, Valentin Nechayev <<a href=3D"mailto:netchv@gmail.com" c=
lass=3D"">netchv@gmail.com</a>> wrote:</div><br class=3D"Apple-interchan=
ge-newline"><div class=3D""><div dir=3D"ltr" class=3D"">On Saturday, Februa=
ry 24, 2018 at 12:05:20 AM UTC+2, Arthur O'Dwyer wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr" class=3D""><div class=3D"">The pr=
e-JAX mailing contains this discussion-provoking paper by JF Bastien:</div>=
<div class=3D""><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pape=
rs/2018/p0907r0.html" target=3D"_blank" rel=3D"nofollow" class=3D"">P0907R0=
"Signed Integers are Two's Complement"</a></div><div class=3D""><br class=
=3D""></div><div class=3D"">My understanding is that JF wants to use this "=
modest proposal" (for wrapping arithmetic on `int`, among other things) as =
a way to incite discussion among the Committee.</div></div></blockquote><di=
v class=3D""><br class=3D""></div><div class=3D"">It currently looks obviou=
s that neither proposition to reduce C++ area to two=CA=BCs-complement mach=
ines</div></div></div></blockquote><div><br class=3D""></div><div>How so? I=
see quite the opposite: I expect Jen=E2=80=99s re-worded paper P1236 to ma=
ke it to C++20 in San Diego.</div><div><br class=3D""></div><br class=3D"">=
<blockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=
=3D""><div class=3D"">nor one to fix each integer arithmetic operation to w=
rapping mode will succeed.</div></div></div></blockquote><div><br class=3D"=
"></div><div>That hasn=E2=80=99t been in papers after r0.</div><div><br cla=
ss=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D""><div clas=
s=3D""><div dir=3D"ltr" class=3D""><div class=3D"">The former looks simply =
having no strong-grounded aim and the latter drastically reduces optimizati=
on opportinuties.<br class=3D""><br class=3D"">On the other hand, we have g=
ood example of local initiative - I mean GCC overflow builtins. Their set i=
s incomplete (at least, narrowing shall be added, and shifts are desired) b=
ut exposes the proper trend. </div><div class=3D""><br class=3D"">Amon=
gst the current proposals, P0103r1 looks the closest to one can succeed, if=
reduced to minimal required extension set. This includes overflow_{add,sub=
,mul,cvt}. But the principal thing lacked in P0103r1 is that, if overflow d=
etected, these functions shall still update result value with lowest bits o=
f result, the widest that fits into result type. The advantage of such appr=
oach is shown in GCC: one will get the truncated (wrapped) value for the on=
ly really present case (two=CA=BCs-complement), and useful guess of real va=
lue for other representations. So, adding such requirement is really desire=
d. From compilers=CA=BC side, this would require minimal efforts but provid=
e basis for any future improvements and, currently, a cumbersome but access=
ible technique to do the needed things just now.<br class=3D""></div><div c=
lass=3D""><br class=3D""></div><div class=3D"">Another thing that is needed=
is compile-time provision of detection of signed number representation use=
d at particular platform. Despite we have two=CA=BCs-complement in 100% of =
cases, this is needed to conform to standard flexibility. This is to be pro=
vided using preprocessor macros and useful also for C code.<br class=3D""><=
br class=3D"">My proposal concept is here: <<a href=3D"https://segfault.=
kiev.ua/~netch/proposal_cpp_int_arith.html" class=3D"">https://segfault.kie=
v.ua/~netch/proposal_cpp_int_arith.html</a>>. It carries wording proposa=
l for level 1; ones for higher levels are planned later on. Its "leve=
l 1" is really a subset of P0103r1 (but planned independently, looking at G=
CC overflow builtins, and with requirement to save value). Higher levels th=
en could be discussed later on. Level 2 is easy to implement just in librar=
y header, provided level 1 is available.<br class=3D""><br class=3D""></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr" class=3D""><=
br class=3D""><div class=3D"">I have created an as-yet-unofficial "conserva=
tive fork" of the proposal, which removes the parts that I think are airbal=
ls, while leaving in much of what I consider the good stuff =E2=80=94 notab=
ly, making signed-to-unsigned and unsigned-to-signed conversions well-defin=
ed in terms of two's complement representations, and defining what happens =
when you bit-shift into or out of the sign bit.</div><div class=3D""><a hre=
f=3D"https://quuxplusone.github.io/draft/twosc-conservative.html" target=3D=
"_blank" rel=3D"nofollow" class=3D"">https://quuxplusone.github.io/<wbr cla=
ss=3D"">draft/twosc-conservative.html</a><br class=3D""></div><div class=3D=
""><br class=3D""></div><div class=3D"">I hope that if the Committee asks J=
F to come back with a more conservative proposal, the existence of my "cons=
ervative fork" will save time, possibly even allow further discussion later=
in the week at JAX.<br class=3D""></div><div class=3D""><br class=3D""></d=
iv><div class=3D"">I personally will not be at JAX, though. JF, will =
you be? Could I count on you to... not to "champion" my unsubmitted paper, =
of course, but just to be aware of it in case something like it is asked fo=
r by the Committee? I mean, the worst-case, which I would like to avo=
id, is that JF's paper is rejected as too crazy and then the entire subject=
is tabled until Rapperswil. I would like to see some concrete progress in =
this department at JAX if humanly possible.</div><div class=3D""><br class=
=3D""></div><div class=3D"">=E2=80=93Arthur</div><div class=3D""><br class=
=3D""></div><div class=3D"">P.S. =E2=80=94 Also, if anyone on std-proposals=
has objections to the specific diffs in my conservative proposal, I would =
like to know about it. I deliberately tried to remove any whiff of controve=
rsy from the diff. (This is distinct from objecting to my presumptuou=
sness or objecting to wasting the Committee's time. ;))</div></div>
</blockquote></div></div></blockquote></div><br class=3D""></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1E3E0505-D7DA-471D-85E1-170EDD13B659%=
40apple.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1E3E0505-D7DA-471D-85E1-170EDD13B659%=
40apple.com</a>.<br />
--Boundary_(ID_odBoX7uIBpkCM2+o+SLueg)--
.