Topic: Make more bitwise operations have defined behavior
Author: "Nevin \":-)\" Liber" <"Nevin ":-)" Liber" <nliber@gmail.com>>
Date: Fri, 20 May 2016 14:35:44 -0500
Raw View
--Apple-Mail-7ED7A258-356C-4B04-B0F5-458E45776233
Content-Type: text/plain; charset=UTF-8
In other words, you are proposing to break C compatibility.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-312-623-5420
> On May 20, 2016, at 2:30 PM, ryani.spam@gmail.com wrote:
>
> The following function invokes UB on all inputs:
>
> uint8_t f(uint8_t x)
> {
> return (~x) << 1;
> }
>
> This tripped up everyone I've asked; the function has a clear purpose and function and yet according to the standard it is broken.
>
> This is due to an unfortunate confluence of three problems:
>
> (1) All mathematical operators trigger integer promotion rules to more natural integer sizes for the optimizer. I don't think this should be changed, it gives too many valuable optimization opportunities.
> (2) Integer promotion promotes small unsigned types to signed integers. This is questionable, but there is some argument that given uint8_t, (x - 256) < 0 should be true.
> (3) << on negative signed values is UB (and >> on negative signed values is implementation-defined, which is not as bad, but still not ideal for easily writing portable code)
>
> For example, f(0):
> uint8_t: 0x00
> -> promote to int: 0x00000000
> -> apply operator~: 0xFFFFFFFF whose bit pattern represents -1 on most platforms
> -> apply operator>>: UB because left hand side is negative
>
> The fix is ugly, verbose, and non-intuitive: always cast to the desired result type before executing any shift operators:
>
> return ((uint8_t)(~x)) << 1;
>
> Can anyone point me at discussion of the behavior of bitwise & shift operators? How did we arrive on the rules for >> and <<?
> --
> 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/280296a2-0972-43e1-9145-6cb70489d324%40isocpp.org.
--
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/A4C74956-6DC7-44AD-9001-A67AAD7C15AB%40gmail.com.
--Apple-Mail-7ED7A258-356C-4B04-B0F5-458E45776233
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 dir=3D"auto"><div>In other words, you are proposing =
to break C compatibility. <br><br>-- <div> Nevin ":-)" Liber=
<<a href=3D"mailto:nevin@eviloverlord.com">mailto:nevin@eviloverlord.co=
m</a>> +1-312-623-5420</div></div><div><br>On May 20, 2016, at 2:3=
0 PM, <a href=3D"mailto:ryani.spam@gmail.com">ryani.spam@gmail.com</a> wrot=
e:<br><br></div><blockquote type=3D"cite"><div><div dir=3D"ltr">The followi=
ng function invokes UB on all inputs:<div><br></div><div> uint=
8_t f(uint8_t x)</div><div> {</div><div> &=
nbsp; return (~x) << 1;</div><div> }</div><div><br></div=
><div>This tripped up everyone I've asked; the function has a clear purpose=
and function and yet according to the standard it is broken.</div><div><br=
></div><div>This is due to an unfortunate confluence of three problems:</di=
v><div><br></div><div>(1) All mathematical operators trigger integer promot=
ion rules to more natural integer sizes for the optimizer. I don't th=
ink this should be changed, it gives too many valuable optimization opportu=
nities.</div><div>(2) Integer promotion promotes small unsigned types to si=
gned integers. This is questionable, but there is some argument that =
given uint8_t, (x - 256) < 0 should be true.</div><div>(3) << on n=
egative signed values is UB (and >> on negative signed values is impl=
ementation-defined, which is not as bad, but still not ideal for easily wri=
ting portable code)</div><div><br></div><div>For example, f(0):</div><div>&=
nbsp; uint8_t: 0x00</div><div> -> promote to int: 0x=
00000000</div><div> -> apply operator~: 0xFFFFFFFF whose bi=
t pattern represents -1 on most platforms</div><div> -> app=
ly operator>>: UB because left hand side is negative <br></div><=
div><br></div><div>The fix is ugly, verbose, and non-intuitive: always cast=
to the desired result type before executing any shift operators:</div><div=
><br></div><div> return ((uint8_t)(~x)) << 1;</div=
><div><br></div><div>Can anyone point me at discussion of the behavior of b=
itwise & shift operators? How did we arrive on the rules for >=
> and <<?</div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
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/280296a2-0972-43e1-9145-6cb70489d324%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/280296a2-0972-43e1-9145-6cb70489=
d324%40isocpp.org</a>.<br>
</div></blockquote></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/A4C74956-6DC7-44AD-9001-A67AAD7C15AB%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/A4C74956-6DC7-44AD-9001-A67AAD7C15AB%=
40gmail.com</a>.<br />
--Apple-Mail-7ED7A258-356C-4B04-B0F5-458E45776233--
.
Author: ryani.spam@gmail.com
Date: Fri, 20 May 2016 12:30:55 -0700 (PDT)
Raw View
------=_Part_2822_1749818594.1463772655927
Content-Type: multipart/alternative;
boundary="----=_Part_2823_924880060.1463772655927"
------=_Part_2823_924880060.1463772655927
Content-Type: text/plain; charset=UTF-8
The following function invokes UB on all inputs:
uint8_t f(uint8_t x)
{
return (~x) << 1;
}
This tripped up everyone I've asked; the function has a clear purpose and
function and yet according to the standard it is broken.
This is due to an unfortunate confluence of three problems:
(1) All mathematical operators trigger integer promotion rules to more
natural integer sizes for the optimizer. I don't think this should be
changed, it gives too many valuable optimization opportunities.
(2) Integer promotion promotes small unsigned types to signed integers.
This is questionable, but there is some argument that given uint8_t, (x -
256) < 0 should be true.
(3) << on negative signed values is UB (and >> on negative signed values is
implementation-defined, which is not as bad, but still not ideal for easily
writing portable code)
For example, f(0):
uint8_t: 0x00
-> promote to int: 0x00000000
-> apply operator~: 0xFFFFFFFF whose bit pattern represents -1 on most
platforms
-> apply operator>>: UB because left hand side is negative
The fix is ugly, verbose, and non-intuitive: always cast to the desired
result type before executing any shift operators:
return ((uint8_t)(~x)) << 1;
Can anyone point me at discussion of the behavior of bitwise & shift
operators? How did we arrive on the rules for >> and <<?
--
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/280296a2-0972-43e1-9145-6cb70489d324%40isocpp.org.
------=_Part_2823_924880060.1463772655927
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The following function invokes UB on all inputs:<div><br><=
/div><div>=C2=A0 =C2=A0 uint8_t f(uint8_t x)</div><div>=C2=A0 =C2=A0 {</div=
><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return (~x) << 1;</div><div>=C2=A0 =
=C2=A0 }</div><div><br></div><div>This tripped up everyone I've asked; =
the function has a clear purpose and function and yet according to the stan=
dard it is broken.</div><div><br></div><div>This is due to an unfortunate c=
onfluence of three problems:</div><div><br></div><div>(1) All mathematical =
operators trigger integer promotion rules to more natural integer sizes for=
the optimizer. =C2=A0I don't think this should be changed, it gives to=
o many valuable optimization opportunities.</div><div>(2) Integer promotion=
promotes small unsigned types to signed integers. =C2=A0This is questionab=
le, but there is some argument that given uint8_t, (x - 256) < 0 should =
be true.</div><div>(3) << on negative signed values is UB (and >&g=
t; on negative signed values is implementation-defined, which is not as bad=
, but still not ideal for easily writing portable code)</div><div><br></div=
><div>For example, f(0):</div><div>=C2=A0 =C2=A0 uint8_t: 0x00</div><div>=
=C2=A0 =C2=A0 -> promote to int: 0x00000000</div><div>=C2=A0 =C2=A0 ->=
; apply operator~: 0xFFFFFFFF whose bit pattern represents -1 on most platf=
orms</div><div>=C2=A0 =C2=A0 -> apply operator>>: UB because left =
hand side is negative=C2=A0<br></div><div><br></div><div>The fix is ugly, v=
erbose, and non-intuitive: always cast to the desired result type before ex=
ecuting any shift operators:</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0r=
eturn ((uint8_t)(~x)) << 1;</div><div><br></div><div>Can anyone point=
me at discussion of the behavior of bitwise & shift operators? =C2=A0H=
ow did we arrive on the rules for >> and <<?</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/280296a2-0972-43e1-9145-6cb70489d324%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/280296a2-0972-43e1-9145-6cb70489d324=
%40isocpp.org</a>.<br />
------=_Part_2823_924880060.1463772655927--
------=_Part_2822_1749818594.1463772655927--
.
Author: ryani.spam@gmail.com
Date: Fri, 20 May 2016 12:42:27 -0700 (PDT)
Raw View
------=_Part_2892_1575720167.1463773347864
Content-Type: multipart/alternative;
boundary="----=_Part_2893_1144490108.1463773347864"
------=_Part_2893_1144490108.1463773347864
Content-Type: text/plain; charset=UTF-8
If this is UB in the current C standard then I think the same arguments
about "standard is broken here" apply.
Furthermore, changing UB to DB cannot break compatibility as one possible
result of the UB is the newly defined behavior.
On Friday, May 20, 2016 at 12:35:49 PM UTC-7, Nevin ":-)" Liber wrote:
>
> In other words, you are proposing to break C compatibility.
>
> --
> Nevin ":-)" Liber <mailto...@eviloverlord.com <javascript:>>
> +1-312-623-5420
>
> On May 20, 2016, at 2:30 PM, ryani...@gmail.com <javascript:> wrote:
>
> The following function invokes UB on all inputs:
>
> uint8_t f(uint8_t x)
> {
> return (~x) << 1;
> }
>
> This tripped up everyone I've asked; the function has a clear purpose and
> function and yet according to the standard it is broken.
>
> This is due to an unfortunate confluence of three problems:
>
> (1) All mathematical operators trigger integer promotion rules to more
> natural integer sizes for the optimizer. I don't think this should be
> changed, it gives too many valuable optimization opportunities.
> (2) Integer promotion promotes small unsigned types to signed integers.
> This is questionable, but there is some argument that given uint8_t, (x -
> 256) < 0 should be true.
> (3) << on negative signed values is UB (and >> on negative signed values
> is implementation-defined, which is not as bad, but still not ideal for
> easily writing portable code)
>
> For example, f(0):
> uint8_t: 0x00
> -> promote to int: 0x00000000
> -> apply operator~: 0xFFFFFFFF whose bit pattern represents -1 on most
> platforms
> -> apply operator>>: UB because left hand side is negative
>
> The fix is ugly, verbose, and non-intuitive: always cast to the desired
> result type before executing any shift operators:
>
> return ((uint8_t)(~x)) << 1;
>
> Can anyone point me at discussion of the behavior of bitwise & shift
> operators? How did we arrive on the rules for >> and <<?
>
> --
> 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-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/280296a2-0972-43e1-9145-6cb70489d324%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/280296a2-0972-43e1-9145-6cb70489d324%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
>
--
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/9bcade7a-fb3c-4d3d-ada6-cce3d3c9fc05%40isocpp.org.
------=_Part_2893_1144490108.1463773347864
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">If this is UB in the current C standard then I think the s=
ame arguments about "standard is broken here" apply.<div><br></di=
v><div>Furthermore, changing UB to DB cannot break compatibility as one pos=
sible result of the UB is the newly defined behavior.</div><div><br>On Frid=
ay, May 20, 2016 at 12:35:49 PM UTC-7, Nevin ":-)" Liber wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto"><div>In other =
words, you are proposing to break C compatibility.=C2=A0<br><br>--=C2=A0<di=
v>=C2=A0Nevin ":-)" Liber <<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"HPVkdO3zDAAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">mailto...@eviloverlord.com</a><wbr>>=
=C2=A0+1-312-623-5420</div></div><div><br>On May 20, 2016, at 2:30 PM, <a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"HPVkdO3zDAA=
J" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return=
true;" onclick=3D"this.href=3D'javascript:';return true;">ryani...=
@gmail.com</a> wrote:<br><br></div><blockquote type=3D"cite"><div><div dir=
=3D"ltr">The following function invokes UB on all inputs:<div><br></div><di=
v>=C2=A0 =C2=A0 uint8_t f(uint8_t x)</div><div>=C2=A0 =C2=A0 {</div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return (~x) << 1;</div><div>=C2=A0 =C2=A0=
}</div><div><br></div><div>This tripped up everyone I've asked; the fu=
nction has a clear purpose and function and yet according to the standard i=
t is broken.</div><div><br></div><div>This is due to an unfortunate conflue=
nce of three problems:</div><div><br></div><div>(1) All mathematical operat=
ors trigger integer promotion rules to more natural integer sizes for the o=
ptimizer. =C2=A0I don't think this should be changed, it gives too many=
valuable optimization opportunities.</div><div>(2) Integer promotion promo=
tes small unsigned types to signed integers. =C2=A0This is questionable, bu=
t there is some argument that given uint8_t, (x - 256) < 0 should be tru=
e.</div><div>(3) << on negative signed values is UB (and >> on =
negative signed values is implementation-defined, which is not as bad, but =
still not ideal for easily writing portable code)</div><div><br></div><div>=
For example, f(0):</div><div>=C2=A0 =C2=A0 uint8_t: 0x00</div><div>=C2=A0 =
=C2=A0 -> promote to int: 0x00000000</div><div>=C2=A0 =C2=A0 -> apply=
operator~: 0xFFFFFFFF whose bit pattern represents -1 on most platforms</d=
iv><div>=C2=A0 =C2=A0 -> apply operator>>: UB because left hand si=
de is negative=C2=A0<br></div><div><br></div><div>The fix is ugly, verbose,=
and non-intuitive: always cast to the desired result type before executing=
any shift operators:</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0return (=
(uint8_t)(~x)) << 1;</div><div><br></div><div>Can anyone point me at =
discussion of the behavior of bitwise & shift operators? =C2=A0How did =
we arrive on the rules for >> and <<?</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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
HPVkdO3zDAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"HPVkdO3zDAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/280296a2-0972-43e1-9145-6cb70489d324%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/280296a2-0972-43e1-9145-6cb70489d324%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/280296a2-0972-43e1-9145-6cb70489d324%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/280296a2-0972-43e1-<wbr>9145-=
6cb70489d324%40isocpp.org</a><wbr>.<br>
</div></blockquote></div></blockquote></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/9bcade7a-fb3c-4d3d-ada6-cce3d3c9fc05%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9bcade7a-fb3c-4d3d-ada6-cce3d3c9fc05=
%40isocpp.org</a>.<br />
------=_Part_2893_1144490108.1463773347864--
------=_Part_2892_1575720167.1463773347864--
.
Author: demiobenour@gmail.com
Date: Tue, 26 Jul 2016 22:46:47 -0700 (PDT)
Raw View
------=_Part_2489_202690002.1469598407774
Content-Type: multipart/alternative;
boundary="----=_Part_2490_1330551809.1469598407774"
------=_Part_2490_1330551809.1469598407774
Content-Type: text/plain; charset=UTF-8
I agree. The standard is broken here. I think that shift left should be
defined to wrap, and shift-right to sign-extend.
On Friday, May 20, 2016 at 3:42:27 PM UTC-4, ryani...@gmail.com wrote:
>
> If this is UB in the current C standard then I think the same arguments
> about "standard is broken here" apply.
>
> Furthermore, changing UB to DB cannot break compatibility as one possible
> result of the UB is the newly defined behavior.
>
> On Friday, May 20, 2016 at 12:35:49 PM UTC-7, Nevin ":-)" Liber wrote:
>>
>> In other words, you are proposing to break C compatibility.
>>
>> --
>> Nevin ":-)" Liber <mailto...@eviloverlord.com> +1-312-623-5420
>>
>> On May 20, 2016, at 2:30 PM, ryani...@gmail.com wrote:
>>
>> The following function invokes UB on all inputs:
>>
>> uint8_t f(uint8_t x)
>> {
>> return (~x) << 1;
>> }
>>
>> This tripped up everyone I've asked; the function has a clear purpose and
>> function and yet according to the standard it is broken.
>>
>> This is due to an unfortunate confluence of three problems:
>>
>> (1) All mathematical operators trigger integer promotion rules to more
>> natural integer sizes for the optimizer. I don't think this should be
>> changed, it gives too many valuable optimization opportunities.
>> (2) Integer promotion promotes small unsigned types to signed integers.
>> This is questionable, but there is some argument that given uint8_t, (x -
>> 256) < 0 should be true.
>> (3) << on negative signed values is UB (and >> on negative signed values
>> is implementation-defined, which is not as bad, but still not ideal for
>> easily writing portable code)
>>
>> For example, f(0):
>> uint8_t: 0x00
>> -> promote to int: 0x00000000
>> -> apply operator~: 0xFFFFFFFF whose bit pattern represents -1 on
>> most platforms
>> -> apply operator>>: UB because left hand side is negative
>>
>> The fix is ugly, verbose, and non-intuitive: always cast to the desired
>> result type before executing any shift operators:
>>
>> return ((uint8_t)(~x)) << 1;
>>
>> Can anyone point me at discussion of the behavior of bitwise & shift
>> operators? How did we arrive on the rules for >> and <<?
>>
>> --
>> 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-proposal...@isocpp.org.
>> To post to this group, send email to std-pr...@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/280296a2-0972-43e1-9145-6cb70489d324%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/280296a2-0972-43e1-9145-6cb70489d324%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>>
--
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/61d0b319-bd41-483b-8ff3-e4ebe7daa1e8%40isocpp.org.
------=_Part_2490_1330551809.1469598407774
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I agree.=C2=A0 The standard is broken here.=C2=A0 I think =
that shift left should be defined to wrap, and shift-right to sign-extend.<=
br><br>On Friday, May 20, 2016 at 3:42:27 PM UTC-4, ryani...@gmail.com wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">If this is =
UB in the current C standard then I think the same arguments about "st=
andard is broken here" apply.<div><br></div><div>Furthermore, changing=
UB to DB cannot break compatibility as one possible result of the UB is th=
e newly defined behavior.</div><div><br>On Friday, May 20, 2016 at 12:35:49=
PM UTC-7, Nevin ":-)" Liber wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"auto"><div>In other words, you are proposing to break=
C compatibility.=C2=A0<br><br>--=C2=A0<div>=C2=A0Nevin ":-)" Lib=
er <<a rel=3D"nofollow">mailto...@eviloverlord.com</a>> =C2=A0+1-312-=
623-5420</div></div><div><br>On May 20, 2016, at 2:30 PM, <a rel=3D"nofollo=
w">ryani...@gmail.com</a> wrote:<br><br></div><blockquote type=3D"cite"><di=
v><div dir=3D"ltr">The following function invokes UB on all inputs:<div><br=
></div><div>=C2=A0 =C2=A0 uint8_t f(uint8_t x)</div><div>=C2=A0 =C2=A0 {</d=
iv><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return (~x) << 1;</div><div>=C2=
=A0 =C2=A0 }</div><div><br></div><div>This tripped up everyone I've ask=
ed; the function has a clear purpose and function and yet according to the =
standard it is broken.</div><div><br></div><div>This is due to an unfortuna=
te confluence of three problems:</div><div><br></div><div>(1) All mathemati=
cal operators trigger integer promotion rules to more natural integer sizes=
for the optimizer. =C2=A0I don't think this should be changed, it give=
s too many valuable optimization opportunities.</div><div>(2) Integer promo=
tion promotes small unsigned types to signed integers. =C2=A0This is questi=
onable, but there is some argument that given uint8_t, (x - 256) < 0 sho=
uld be true.</div><div>(3) << on negative signed values is UB (and &g=
t;> on negative signed values is implementation-defined, which is not as=
bad, but still not ideal for easily writing portable code)</div><div><br><=
/div><div>For example, f(0):</div><div>=C2=A0 =C2=A0 uint8_t: 0x00</div><di=
v>=C2=A0 =C2=A0 -> promote to int: 0x00000000</div><div>=C2=A0 =C2=A0 -&=
gt; apply operator~: 0xFFFFFFFF whose bit pattern represents -1 on most pla=
tforms</div><div>=C2=A0 =C2=A0 -> apply operator>>: UB because lef=
t hand side is negative=C2=A0<br></div><div><br></div><div>The fix is ugly,=
verbose, and non-intuitive: always cast to the desired result type before =
executing any shift operators:</div><div><br></div><div>=C2=A0 =C2=A0 =C2=
=A0return ((uint8_t)(~x)) << 1;</div><div><br></div><div>Can anyone p=
oint me at discussion of the behavior of bitwise & shift operators? =C2=
=A0How did we arrive on the rules for >> and <<?</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 rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</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/280296a2-0972-43e1-9145-6cb70489d324%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/280296a2-0972-43e1-9145-6cb70489d324%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/280296a2-0972-43e1-9145-6cb70489d324%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/280296a2-0972-43e1-<wbr>9145-=
6cb70489d324%40isocpp.org</a><wbr>.<br>
</div></blockquote></div></blockquote></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/61d0b319-bd41-483b-8ff3-e4ebe7daa1e8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/61d0b319-bd41-483b-8ff3-e4ebe7daa1e8=
%40isocpp.org</a>.<br />
------=_Part_2490_1330551809.1469598407774--
------=_Part_2489_202690002.1469598407774--
.
Author: "D. B." <db0451@gmail.com>
Date: Wed, 27 Jul 2016 07:06:56 +0100
Raw View
--001a11468e08274b8c053897d338
Content-Type: text/plain; charset=UTF-8
What, so compilers should be forced not to use the most efficient opcodes
and/or to add machine-code fluff to define things most people don't care
about... slowing down everyone else's programs to give convenience to a
few? I don't think so! If you want the defined behaviour, check for it
yourself and handle as required. Don't make everyone else pay for 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/CACGiwhFZyTmjEf%3DAxYKkcxbtjTbn87st_%3DuFyZdcRfFn7dyeeQ%40mail.gmail.com.
--001a11468e08274b8c053897d338
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">What, so compilers should be forced not to use the most ef=
ficient opcodes and/or to add machine-code fluff to define things most peop=
le don't care about... slowing down everyone else's programs to giv=
e convenience to a few? I don't think so! If you want the defined behav=
iour, check for it yourself and handle as required. Don't make everyone=
else pay for it.<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/CACGiwhFZyTmjEf%3DAxYKkcxbtjTbn87st_%=
3DuFyZdcRfFn7dyeeQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFZyTmj=
Ef%3DAxYKkcxbtjTbn87st_%3DuFyZdcRfFn7dyeeQ%40mail.gmail.com</a>.<br />
--001a11468e08274b8c053897d338--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Tue, 26 Jul 2016 23:12:21 -0700 (PDT)
Raw View
------=_Part_1881_341202786.1469599941731
Content-Type: multipart/alternative;
boundary="----=_Part_1882_1328908741.1469599941731"
------=_Part_1882_1328908741.1469599941731
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8827=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8B=E5=8D=882:06:59=EF=BC=8CD. B.=E5=86=99=E9=81=93=EF=BC=9A
>
> What, so compilers should be forced not to use the most efficient opcodes=
=20
> and/or to add machine-code fluff to define things most people don't care=
=20
> about... slowing down everyone else's programs to give convenience to a=
=20
> few? I don't think so! If you want the defined behaviour, check for it=20
> yourself and handle as required. Don't make everyone else pay for it.
>
Promoting to `int` does not guarantee that.
=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/f3df996d-f8e0-4b79-9ae0-63f634dd41fa%40isocpp.or=
g.
------=_Part_1882_1328908741.1469599941731
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8827=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=882:06:59=EF=BC=8CD. B.=E5=86=99=
=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">What, so compilers should be forced not to use the most efficient opco=
des and/or to add machine-code fluff to define things most people don't=
care about... slowing down everyone else's programs to give convenienc=
e to a few? I don't think so! If you want the defined behaviour, check =
for it yourself and handle as required. Don't make everyone else pay fo=
r it.<br></div></blockquote><div><br>Promoting to `int` does not guarantee =
that.<br><br>=C2=A0<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/f3df996d-f8e0-4b79-9ae0-63f634dd41fa%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f3df996d-f8e0-4b79-9ae0-63f634dd41fa=
%40isocpp.org</a>.<br />
------=_Part_1882_1328908741.1469599941731--
------=_Part_1881_341202786.1469599941731--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Tue, 26 Jul 2016 23:23:18 -0700 (PDT)
Raw View
------=_Part_445_235224936.1469600598755
Content-Type: multipart/alternative;
boundary="----=_Part_446_291806491.1469600598756"
------=_Part_446_291806491.1469600598756
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I prefer to get some more sane integer types with different settings of=20
fine-grained features rather than the single option of non intuitive least=
=20
common denominator. Integer promotion should die for non-arithmetic=20
operations. By nominal typing and additional aliasing and conversion rules,=
=20
C compatibility can be remained in single direction.
Eventually we can deprecate the legacy design (as we do for <*.h> headers=
=20
currently), after decades.
=E5=9C=A8 2016=E5=B9=B45=E6=9C=8821=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC=
+8=E4=B8=8A=E5=8D=883:35:49=EF=BC=8CNevin ":-)" Liber=E5=86=99=E9=81=93=EF=
=BC=9A
>
> In other words, you are proposing to break C compatibility.=20
>
> --=20
> Nevin ":-)" Liber <mailto...@eviloverlord.com <javascript:>>=20
> +1-312-623-5420
>
> On May 20, 2016, at 2:30 PM, ryani...@gmail.com <javascript:> wrote:
>
> The following function invokes UB on all inputs:
>
> uint8_t f(uint8_t x)
> {
> return (~x) << 1;
> }
>
> This tripped up everyone I've asked; the function has a clear purpose and=
=20
> function and yet according to the standard it is broken.
>
> This is due to an unfortunate confluence of three problems:
>
> (1) All mathematical operators trigger integer promotion rules to more=20
> natural integer sizes for the optimizer. I don't think this should be=20
> changed, it gives too many valuable optimization opportunities.
> (2) Integer promotion promotes small unsigned types to signed integers.=
=20
> This is questionable, but there is some argument that given uint8_t, (x =
-=20
> 256) < 0 should be true.
> (3) << on negative signed values is UB (and >> on negative signed values=
=20
> is implementation-defined, which is not as bad, but still not ideal for=
=20
> easily writing portable code)
>
> For example, f(0):
> uint8_t: 0x00
> -> promote to int: 0x00000000
> -> apply operator~: 0xFFFFFFFF whose bit pattern represents -1 on mos=
t=20
> platforms
> -> apply operator>>: UB because left hand side is negative=20
>
> The fix is ugly, verbose, and non-intuitive: always cast to the desired=
=20
> result type before executing any shift operators:
>
> return ((uint8_t)(~x)) << 1;
>
> Can anyone point me at discussion of the behavior of bitwise & shift=20
> operators? How did we arrive on the rules for >> and <<?
>
> --=20
> You received this message because you are subscribed to the Google Groups=
=20
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to std-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/280296a2-097=
2-43e1-9145-6cb70489d324%40isocpp.org=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/280296a2-09=
72-43e1-9145-6cb70489d324%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
>
--=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/48d1d94c-35d5-49e1-bf2e-96a50f67107a%40isocpp.or=
g.
------=_Part_446_291806491.1469600598756
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I prefer to get some more sane integer types with differen=
t settings of fine-grained features rather than the single option of non in=
tuitive least common denominator. Integer promotion should die for non-arit=
hmetic operations. By nominal typing and additional aliasing and conversion=
rules, C compatibility can be remained in single direction.<br><br>Eventua=
lly we can deprecate the legacy design (as we do for <*.h> headers cu=
rrently), after decades.<br><br>=E5=9C=A8 2016=E5=B9=B45=E6=9C=8821=E6=97=
=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=883:35:49=EF=BC=8CNevin=
":-)" Liber=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"auto"><div>In other words, you are proposing=
to break C compatibility.=C2=A0<br><br>--=C2=A0<div>=C2=A0Nevin ":-)&=
quot; Liber <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"HPVkdO3zDAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';ret=
urn true;">mailto...@eviloverlord.com</a><wbr>> =C2=A0+1-312-623-5420</d=
iv></div><div><br>On May 20, 2016, at 2:30 PM, <a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"HPVkdO3zDAAJ" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.h=
ref=3D'javascript:';return true;">ryani...@gmail.com</a> wrote:<br>=
<br></div><blockquote type=3D"cite"><div><div dir=3D"ltr">The following fun=
ction invokes UB on all inputs:<div><br></div><div>=C2=A0 =C2=A0 uint8_t f(=
uint8_t x)</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
return (~x) << 1;</div><div>=C2=A0 =C2=A0 }</div><div><br></div><div>=
This tripped up everyone I've asked; the function has a clear purpose a=
nd function and yet according to the standard it is broken.</div><div><br><=
/div><div>This is due to an unfortunate confluence of three problems:</div>=
<div><br></div><div>(1) All mathematical operators trigger integer promotio=
n rules to more natural integer sizes for the optimizer. =C2=A0I don't =
think this should be changed, it gives too many valuable optimization oppor=
tunities.</div><div>(2) Integer promotion promotes small unsigned types to =
signed integers. =C2=A0This is questionable, but there is some argument tha=
t given uint8_t, (x - 256) < 0 should be true.</div><div>(3) << on=
negative signed values is UB (and >> on negative signed values is im=
plementation-defined, which is not as bad, but still not ideal for easily w=
riting portable code)</div><div><br></div><div>For example, f(0):</div><div=
>=C2=A0 =C2=A0 uint8_t: 0x00</div><div>=C2=A0 =C2=A0 -> promote to int: =
0x00000000</div><div>=C2=A0 =C2=A0 -> apply operator~: 0xFFFFFFFF whose =
bit pattern represents -1 on most platforms</div><div>=C2=A0 =C2=A0 -> a=
pply operator>>: UB because left hand side is negative=C2=A0<br></div=
><div><br></div><div>The fix is ugly, verbose, and non-intuitive: always ca=
st to the desired result type before executing any shift operators:</div><d=
iv><br></div><div>=C2=A0 =C2=A0 =C2=A0return ((uint8_t)(~x)) << 1;</d=
iv><div><br></div><div>Can anyone point me at discussion of the behavior of=
bitwise & shift operators? =C2=A0How did we arrive on the rules for &g=
t;> and <<?</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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
HPVkdO3zDAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"HPVkdO3zDAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/280296a2-0972-43e1-9145-6cb70489d324%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/280296a2-0972-43e1-9145-6cb70489d324%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/280296a2-0972-43e1-9145-6cb70489d324%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/280296a2-0972-43e1-<wbr>9145-=
6cb70489d324%40isocpp.org</a><wbr>.<br>
</div></blockquote></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/48d1d94c-35d5-49e1-bf2e-96a50f67107a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/48d1d94c-35d5-49e1-bf2e-96a50f67107a=
%40isocpp.org</a>.<br />
------=_Part_446_291806491.1469600598756--
------=_Part_445_235224936.1469600598755--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 27 Jul 2016 00:17:16 -0700
Raw View
On ter=C3=A7a-feira, 26 de julho de 2016 22:46:47 PDT demiobenour@gmail.com=
wrote:
> I agree. The standard is broken here. I think that shift left should be=
=20
> defined to wrap, and shift-right to sign-extend.
This is a very good example of where the machine code would have to be wors=
e=20
in order to implement what you're asking for, on current and common=20
processors.
The documentation of the SHR/SHL/SAR instructions for x86 says that the=20
register holding the shift count is masked to 5 or 6 bits (depending on the=
=20
instruction). That means a shift by a number higher than 32 or 64 masked of=
f.
unsigned power_of_2(unsigned count)
{
return 1 << count;
}
You may expect that power_of_2(33) to result in 0, as 1 << 33 is out of ran=
ge=20
for 32-bit unsigned. However, with the machine code:
movl %edi, %ecx
movl $1, %eax
sall %cl, %eax
the result will be 2, as the shift count 33 is masked by 0x1f.
--=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/2014648.0gzuHhVcWu%40tjmaciei-mobl1.
.
Author: Bo Persson <bop@gmb.dk>
Date: Wed, 27 Jul 2016 12:50:41 +0200
Raw View
On 2016-07-27 09:17, Thiago Macieira wrote:
> On ter=C3=A7a-feira, 26 de julho de 2016 22:46:47 PDT demiobenour@gmail.c=
om wrote:
>> I agree. The standard is broken here. I think that shift left should b=
e
>> defined to wrap, and shift-right to sign-extend.
>
> This is a very good example of where the machine code would have to be wo=
rse
> in order to implement what you're asking for, on current and common
> processors.
>
> The documentation of the SHR/SHL/SAR instructions for x86 says that the
> register holding the shift count is masked to 5 or 6 bits (depending on t=
he
> instruction). That means a shift by a number higher than 32 or 64 masked =
off.
>
> unsigned power_of_2(unsigned count)
> {
> return 1 << count;
> }
>
> You may expect that power_of_2(33) to result in 0, as 1 << 33 is out of r=
ange
> for 32-bit unsigned. However, with the machine code:
>
> movl %edi, %ecx
> movl $1, %eax
> sall %cl, %eax
>
> the result will be 2, as the shift count 33 is masked by 0x1f.
>
And to make it worse, the original 8086 did not mask the shift count.=20
That would make a single binary behave differently on an IBM PC/XT and a=20
PC/AT.
I can see why the C89 committee didn't want to make one of those=20
machines non-conforming. :-)
Bo Persson
--=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/nna3m3%24c8%241%40ger.gmane.org.
.
Author: demiobenour@gmail.com
Date: Wed, 27 Jul 2016 18:53:11 -0700 (PDT)
Raw View
------=_Part_997_958891108.1469670791764
Content-Type: multipart/alternative;
boundary="----=_Part_998_1675352621.1469670791764"
------=_Part_998_1675352621.1469670791764
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, July 27, 2016 at 6:50:52 AM UTC-4, Bo Persson wrote:
>
> On 2016-07-27 09:17, Thiago Macieira wrote:=20
> > On ter=C3=A7a-feira, 26 de julho de 2016 22:46:47 PDT demio...@gmail.co=
m=20
> <javascript:> wrote:=20
> >> I agree. The standard is broken here. I think that shift left should=
=20
> be=20
> >> defined to wrap, and shift-right to sign-extend.=20
> >=20
> > This is a very good example of where the machine code would have to be=
=20
> worse=20
> > in order to implement what you're asking for, on current and common=20
> > processors.=20
> >=20
> > The documentation of the SHR/SHL/SAR instructions for x86 says that the=
=20
> > register holding the shift count is masked to 5 or 6 bits (depending on=
=20
> the=20
> > instruction). That means a shift by a number higher than 32 or 64 maske=
d=20
> off.=20
> >=20
> > unsigned power_of_2(unsigned count)=20
> > {=20
> > return 1 << count;=20
> > }=20
> >=20
> > You may expect that power_of_2(33) to result in 0, as 1 << 33 is out of=
=20
> range=20
> > for 32-bit unsigned. However, with the machine code:=20
> >=20
> > movl %edi, %ecx=20
> > movl $1, %eax=20
> > sall %cl, %eax=20
> >=20
> > the result will be 2, as the shift count 33 is masked by 0x1f.=20
> >=20
>
> And to make it worse, the original 8086 did not mask the shift count.=20
> That would make a single binary behave differently on an IBM PC/XT and a=
=20
> PC/AT.=20
>
> I can see why the C89 committee didn't want to make one of those=20
> machines non-conforming. :-)=20
>
>
> Bo Persson=20
>
> Did not know that. Are there any non-obsolete machines that do not mask=
=20
the shift count?
Even if there are, I would strongly prefer the behavior to be=20
implementation-defined, not undefined. If one wants the compiler to assume=
=20
that a value is in a certain range, one should do something like (GCC/Clang=
=20
syntax and 64-bit types here)
#define ASSERT_IN_SHIFT_RANGE(x) ((x) >=3D 64 ? __builtin_unreachable() : (
void)0)
My rationale is that undefined behavior often leads to security=20
vulnerabilities.
--=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/c6313ff7-90ce-47e0-ba1e-35888381500f%40isocpp.or=
g.
------=_Part_998_1675352621.1469670791764
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, July 27, 2016 at 6:50:52 AM UTC-4, B=
o Persson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-07-27 =
09:17, Thiago Macieira wrote:
<br>> On ter=C3=A7a-feira, 26 de julho de 2016 22:46:47 PDT <a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"AneSz8TkBAAJ" rel=3D=
"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;">demio...@gmail.co=
m</a> wrote:
<br>>> I agree. =C2=A0The standard is broken here. =C2=A0I think that=
shift left should be
<br>>> defined to wrap, and shift-right to sign-extend.
<br>>
<br>> This is a very good example of where the machine code would have t=
o be worse
<br>> in order to implement what you're asking for, on current and c=
ommon
<br>> processors.
<br>>
<br>> The documentation of the SHR/SHL/SAR instructions for x86 says tha=
t the
<br>> register holding the shift count is masked to 5 or 6 bits (dependi=
ng on the
<br>> instruction). That means a shift by a number higher than 32 or 64 =
masked off.
<br>>
<br>> unsigned power_of_2(unsigned count)
<br>> {
<br>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return 1 << =
count;
<br>> }
<br>>
<br>> You may expect that power_of_2(33) to result in 0, as 1 << 3=
3 is out of range
<br>> for 32-bit unsigned. However, with the machine code:
<br>>
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 movl =C2=A0 =C2=A0%edi, %ecx
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 movl =C2=A0 =C2=A0$1, %eax
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 sall =C2=A0 =C2=A0%cl, %eax
<br>>
<br>> the result will be 2, as the shift count 33 is masked by 0x1f.
<br>>
<br>
<br>And to make it worse, the original 8086 did not mask the shift count.=
=20
<br>That would make a single binary behave differently on an IBM PC/XT and =
a=20
<br>PC/AT.
<br>
<br>I can see why the C89 committee didn't want to make one of those=20
<br>machines non-conforming. =C2=A0:-)
<br>
<br>
<br>=C2=A0 =C2=A0 =C2=A0Bo Persson
<br>
<br></blockquote><div>Did not know that.=C2=A0 Are there any non-obsolete m=
achines that do not mask the shift count?<br><br>Even if there are, I would=
strongly prefer the behavior to be implementation-defined, not undefined.=
=C2=A0 If one wants the compiler to assume that a value is in a certain ran=
ge, one should do something like (GCC/Clang syntax and 64-bit types here)<b=
r><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 2=
50); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1=
px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpr=
ettyprint"><span style=3D"color: #800;" class=3D"styled-by-prettify">#defin=
e</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> ASSERT_I=
N_SHIFT_RANGE</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">((</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">>=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">64</s=
pan><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"> __builtin_unreachable</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">:</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: #008;" class=3D"styled-b=
y-prettify">void</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">)</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></co=
de></div><br>=C2=A0My rationale is that undefined behavior often leads to s=
ecurity vulnerabilities.<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/c6313ff7-90ce-47e0-ba1e-35888381500f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c6313ff7-90ce-47e0-ba1e-35888381500f=
%40isocpp.org</a>.<br />
------=_Part_998_1675352621.1469670791764--
------=_Part_997_958891108.1469670791764--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 27 Jul 2016 22:19:11 -0700
Raw View
On quarta-feira, 27 de julho de 2016 18:53:11 PDT demiobenour@gmail.com wrote:
> Did not know that. Are there any non-obsolete machines that do not mask
> the shift count?
I've just checked my manuals:
* ARM: "only the least significant byte is used", which I understand to mean
that a shift of 0x101 is the same as a shift of 1. No information if the
shift count in that byte is higher than the width of the type.
* MIPS: "The bit-shift amount is specified by the low-order 5 bits of GPR rs."
* POWER: "The contents of the low-order 32 bits of register RS are
shifted left the number of bits specified by (RB)58:63."
* UltraSPARC: "the shift count is the least significant five bits of r[rs2]"
One more detail about x86: the manual simply says that it uses the lowest 5
bits, but makes no mention of operations on 8- and 16-bit registers. That
leads me to conclude that logically shifting left or right by 16 on such a
register should zero it. That doesn't apply to us on modern ABIs since the
integer promotion rules say that the operation is executed on int, which is
32-bit. But don't assume that 16-bit ABIs are a thing of the past: running
certain small sections of code in real mode is still required on x86.
> Even if there are, I would strongly prefer the behavior to be
> implementation-defined, not undefined. If one wants the compiler to assume
> that a value is in a certain range, one should do something like (GCC/Clang
> syntax and 64-bit types here)
>
> #define ASSERT_IN_SHIFT_RANGE(x) ((x) >= 64 ? __builtin_unreachable() : (
> void)0)
>
> My rationale is that undefined behavior often leads to security
> vulnerabilities.
That can be applied to all undefined behaviours left in the standard, not just
specifically for the shifting.
The counter-argument is the same: it allows the implementation to optimise.
--
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/3207915.9bbXE0R6pE%40tjmaciei-mobl1.
.
Author: Myriachan <myriachan@gmail.com>
Date: Thu, 28 Jul 2016 15:07:49 -0700 (PDT)
Raw View
------=_Part_73_1865543485.1469743670039
Content-Type: multipart/alternative;
boundary="----=_Part_74_1627916883.1469743670040"
------=_Part_74_1627916883.1469743670040
Content-Type: text/plain; charset=UTF-8
On Wednesday, July 27, 2016 at 10:19:16 PM UTC-7, Thiago Macieira wrote:
>
> One more detail about x86: the manual simply says that it uses the lowest
> 5
> bits, but makes no mention of operations on 8- and 16-bit registers. That
> leads me to conclude that logically shifting left or right by 16 on such a
> register should zero it. That doesn't apply to us on modern ABIs since the
> integer promotion rules say that the operation is executed on int, which
> is
> 32-bit. But don't assume that 16-bit ABIs are a thing of the past: running
> certain small sections of code in real mode is still required on x86.
>
>
I confirmed this with experiment: shifting an 8-bit or 16-bit value by more
than the number of bits in the register caused a full shift-out: the shift
count was interpreted mod 32 rather than mod 8 or 16.
I personally think that the rules should be something like this:
* Shifting a signed number right can either shift in copies of the high bit
or shift in zeros, implementation-defined.
* Shifting left produces the result as if cast to the corresponding
unsigned type, shifted, and cast back, even in the case of negative numbers.
* Shifting by more than the number of bits in the (promoted) type remains
undefined behavior. Or an unspecified result is another possibility.
Only the middle one changes; to me, that negative numbers can't be shifted
left is ridiculous. Especially when there's a special exception allowing
shifting left into the sign bit.
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/5da7ad00-4432-426d-ace8-f1bb1ec3a89b%40isocpp.org.
------=_Part_74_1627916883.1469743670040
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, July 27, 2016 at 10:19:16 PM UTC-7, Thiago M=
acieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">One more detail =
about x86: the manual simply says that it uses the lowest 5=20
<br>bits, but makes no mention of operations on 8- and 16-bit registers. Th=
at=20
<br>leads me to conclude that logically shifting left or right by 16 on suc=
h a=20
<br>register should zero it. That doesn't apply to us on modern ABIs si=
nce the=20
<br>integer promotion rules say that the operation is executed on int, whic=
h is=20
<br>32-bit. But don't assume that 16-bit ABIs are a thing of the past: =
running=20
<br>certain small sections of code in real mode is still required on x86.
<br>
<br></blockquote><div><br>I confirmed this with experiment: shifting an 8-b=
it or 16-bit value by more than the number of bits in the register caused a=
full shift-out: the shift count was interpreted mod 32 rather than mod 8 o=
r 16.<br><br>I personally think that the rules should be something like thi=
s:<br>* Shifting a signed number right can either shift in copies of the hi=
gh bit or shift in zeros, implementation-defined.<br>* Shifting left produc=
es the result as if cast to the corresponding unsigned type, shifted, and c=
ast back, even in the case of negative numbers.<br>* Shifting by more than =
the number of bits in the (promoted) type remains undefined behavior.=C2=A0=
Or an unspecified result is another possibility.<br><br>Only the middle on=
e changes; to me, that negative numbers can't be shifted left is ridicu=
lous.=C2=A0 Especially when there's a special exception allowing shifti=
ng left into the sign bit.<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/5da7ad00-4432-426d-ace8-f1bb1ec3a89b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5da7ad00-4432-426d-ace8-f1bb1ec3a89b=
%40isocpp.org</a>.<br />
------=_Part_74_1627916883.1469743670040--
------=_Part_73_1865543485.1469743670039--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 28 Jul 2016 15:53:19 -0700
Raw View
On quinta-feira, 28 de julho de 2016 15:07:49 PDT Myriachan wrote:
> I personally think that the rules should be something like this:
> * Shifting a signed number right can either shift in copies of the high bit
> or shift in zeros, implementation-defined.
Unless there are machines that do something different. I was reading about the
Apollo Guidance Calculator and how it dealt with numbers. It wasn't any of the
three implementations we usually talk about, but instead it used two sign bits
in the accummulator. If both sign bits were 0, it was positive; if both were
1, it was negative; if they were different, it indicated that a previous
operation had over- or underflown (the two bits were collapsed when saving to
memory). The AGC did not allow shifting under that condition, but a machine
that did could shift in an alternating pattern, or just one zero followed by
all ones, or one one followed by zeroes, or whatever.
It could trap.
> * Shifting left produces the result as if cast to the corresponding
> unsigned type, shifted, and cast back, even in the case of negative numbers.
Which already can trap, implementation-defined.
> * Shifting by more than the number of bits in the (promoted) type remains
> undefined behavior. Or an unspecified result is another possibility.
What's the point of defined unspecified behaviour?
> Only the middle one changes; to me, that negative numbers can't be shifted
> left is ridiculous. Especially when there's a special exception allowing
> shifting left into the sign bit.
--
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/1778457.hZ8eUVjzd5%40tjmaciei-mobl1.
.
Author: Demi Obenour <demiobenour@gmail.com>
Date: Fri, 29 Jul 2016 03:42:19 -0400
Raw View
--001a114ca92cedb3520538c163a0
Content-Type: text/plain; charset=UTF-8
I don't think that arithmetic should ever result in undefined behavior. On
every non-obsolete system that I know of, arithmetic cannot corrupt
memory. I think that the result should be either fully specified or
implementation-defined.
On Jul 28, 2016 9:23 PM, "Thiago Macieira" <thiago@macieira.org> wrote:
> On quinta-feira, 28 de julho de 2016 15:07:49 PDT Myriachan wrote:
> > I personally think that the rules should be something like this:
> > * Shifting a signed number right can either shift in copies of the high
> bit
> > or shift in zeros, implementation-defined.
>
> Unless there are machines that do something different. I was reading about
> the
> Apollo Guidance Calculator and how it dealt with numbers. It wasn't any of
> the
> three implementations we usually talk about, but instead it used two sign
> bits
> in the accummulator. If both sign bits were 0, it was positive; if both
> were
> 1, it was negative; if they were different, it indicated that a previous
> operation had over- or underflown (the two bits were collapsed when saving
> to
> memory). The AGC did not allow shifting under that condition, but a machine
> that did could shift in an alternating pattern, or just one zero followed
> by
> all ones, or one one followed by zeroes, or whatever.
>
> It could trap.
>
> > * Shifting left produces the result as if cast to the corresponding
> > unsigned type, shifted, and cast back, even in the case of negative
> numbers.
>
> Which already can trap, implementation-defined.
>
> > * Shifting by more than the number of bits in the (promoted) type remains
> > undefined behavior. Or an unspecified result is another possibility.
>
> What's the point of defined unspecified behaviour?
>
> > Only the middle one changes; to me, that negative numbers can't be
> shifted
> > left is ridiculous. Especially when there's a special exception allowing
> > shifting left into the sign bit.
>
> --
> 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 a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Ifq39OuA-vU/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/isocpp.org/d/msgid/std-proposals/1778457.hZ8eUVjzd5%40tjmaciei-mobl1
> .
>
--
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/CAJEMUN8ccWvSrY2dafueQGMwtHh7UX34TgkFbh7Hc_skV9S7eQ%40mail.gmail.com.
--001a114ca92cedb3520538c163a0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">I don't think that arithmetic should ever result in unde=
fined behavior.=C2=A0 On every non-obsolete system that I know of, arithmet=
ic cannot corrupt memory.=C2=A0 I think that the result should be either fu=
lly specified or implementation-defined.</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Jul 28, 2016 9=
:23 PM, "Thiago Macieira" <<a href=3D"mailto:thiago@macieira.o=
rg">thiago@macieira.org</a>> wrote:<br type=3D"attribution"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">On quinta-feira, 28 de julho de 2016 15:07:49 PDT Myriac=
han wrote:<br>
> I personally think that the rules should be something like this:<br>
> * Shifting a signed number right can either shift in copies of the hig=
h bit<br>
> or shift in zeros, implementation-defined.<br>
<br>
Unless there are machines that do something different. I was reading about =
the<br>
Apollo Guidance Calculator and how it dealt with numbers. It wasn't any=
of the<br>
three implementations we usually talk about, but instead it used two sign b=
its<br>
in the accummulator. If both sign bits were 0, it was positive; if both wer=
e<br>
1, it was negative; if they were different, it indicated that a previous<br=
>
operation had over- or underflown (the two bits were collapsed when saving =
to<br>
memory). The AGC did not allow shifting under that condition, but a machine=
<br>
that did could shift in an alternating pattern, or just one zero followed b=
y<br>
all ones, or one one followed by zeroes, or whatever.<br>
<br>
It could trap.<br>
<br>
> * Shifting left produces the result as if cast to the corresponding<br=
>
> unsigned type, shifted, and cast back, even in the case of negative nu=
mbers.<br>
<br>
Which already can trap, implementation-defined.<br>
<br>
> * Shifting by more than the number of bits in the (promoted) type rema=
ins<br>
> undefined behavior.=C2=A0 Or an unspecified result is another possibil=
ity.<br>
<br>
What's the point of defined unspecified behaviour?<br>
<br>
> Only the middle one changes; to me, that negative numbers can't be=
shifted<br>
> left is ridiculous.=C2=A0 Especially when there's a special except=
ion allowing<br>
> shifting left into the sign bit.<br>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<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/Ifq39OuA-vU/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/Ifq39OuA-vU/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">std-proposals+unsubscrib=
e@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/1778457.hZ8eUVjzd5%40tjmaciei-mobl1" =
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org=
/d/msgid/std-proposals/1778457.hZ8eUVjzd5%40tjmaciei-mobl1</a>.<br>
</blockquote></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/CAJEMUN8ccWvSrY2dafueQGMwtHh7UX34TgkF=
bh7Hc_skV9S7eQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJEMUN8ccWvSrY2d=
afueQGMwtHh7UX34TgkFbh7Hc_skV9S7eQ%40mail.gmail.com</a>.<br />
--001a114ca92cedb3520538c163a0--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Fri, 29 Jul 2016 08:24:32 +0000
Raw View
--089e01493f5e716ce20538c1fb57
Content-Type: text/plain; charset=UTF-8
Undefined behavior isn't about memory corruption or whatever - it's
strictly about enabling compiler optimizations, and documenting those is
bound to be a pain.
On Fri, Jul 29, 2016 at 9:42 AM Demi Obenour <demiobenour@gmail.com> wrote:
> I don't think that arithmetic should ever result in undefined behavior.
> On every non-obsolete system that I know of, arithmetic cannot corrupt
> memory. I think that the result should be either fully specified or
> implementation-defined.
>
> On Jul 28, 2016 9:23 PM, "Thiago Macieira" <thiago@macieira.org> wrote:
>
>> On quinta-feira, 28 de julho de 2016 15:07:49 PDT Myriachan wrote:
>> > I personally think that the rules should be something like this:
>> > * Shifting a signed number right can either shift in copies of the high
>> bit
>> > or shift in zeros, implementation-defined.
>>
>> Unless there are machines that do something different. I was reading
>> about the
>> Apollo Guidance Calculator and how it dealt with numbers. It wasn't any
>> of the
>> three implementations we usually talk about, but instead it used two sign
>> bits
>> in the accummulator. If both sign bits were 0, it was positive; if both
>> were
>> 1, it was negative; if they were different, it indicated that a previous
>> operation had over- or underflown (the two bits were collapsed when
>> saving to
>> memory). The AGC did not allow shifting under that condition, but a
>> machine
>> that did could shift in an alternating pattern, or just one zero followed
>> by
>> all ones, or one one followed by zeroes, or whatever.
>>
>> It could trap.
>>
>> > * Shifting left produces the result as if cast to the corresponding
>> > unsigned type, shifted, and cast back, even in the case of negative
>> numbers.
>>
>> Which already can trap, implementation-defined.
>>
>> > * Shifting by more than the number of bits in the (promoted) type
>> remains
>> > undefined behavior. Or an unspecified result is another possibility.
>>
>> What's the point of defined unspecified behaviour?
>>
>> > Only the middle one changes; to me, that negative numbers can't be
>> shifted
>> > left is ridiculous. Especially when there's a special exception
>> allowing
>> > shifting left into the sign bit.
>>
>> --
>> 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 a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Ifq39OuA-vU/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/isocpp.org/d/msgid/std-proposals/1778457.hZ8eUVjzd5%40tjmaciei-mobl1
>> .
>>
> --
> 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/CAJEMUN8ccWvSrY2dafueQGMwtHh7UX34TgkFbh7Hc_skV9S7eQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJEMUN8ccWvSrY2dafueQGMwtHh7UX34TgkFbh7Hc_skV9S7eQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAPCFJdTxJD-aTOa-XELjUTbQ4f%3Dru7Ekv3eknRSQfRw-A%2BHYGw%40mail.gmail.com.
--089e01493f5e716ce20538c1fb57
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Undefined behavior isn't about memory corruption or wh=
atever - it's strictly about enabling compiler optimizations, and docum=
enting those is bound to be a pain.<br></div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr">On Fri, Jul 29, 2016 at 9:42 AM Demi Obenour <<a href=
=3D"mailto:demiobenour@gmail.com">demiobenour@gmail.com</a>> wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">I don't think that a=
rithmetic should ever result in undefined behavior.=C2=A0 On every non-obso=
lete system that I know of, arithmetic cannot corrupt memory.=C2=A0 I think=
that the result should be either fully specified or implementation-defined=
..</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote"></div></div><div =
class=3D"gmail_extra"><div class=3D"gmail_quote">On Jul 28, 2016 9:23 PM, &=
quot;Thiago Macieira" <<a href=3D"mailto:thiago@macieira.org" targe=
t=3D"_blank">thiago@macieira.org</a>> wrote:<br type=3D"attribution"></d=
iv></div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">On quinta-feira, 28 de julho de 2016 15:07:49 PDT Myriac=
han wrote:<br>
> I personally think that the rules should be something like this:<br>
> * Shifting a signed number right can either shift in copies of the hig=
h bit<br>
> or shift in zeros, implementation-defined.<br>
<br>
Unless there are machines that do something different. I was reading about =
the<br>
Apollo Guidance Calculator and how it dealt with numbers. It wasn't any=
of the<br>
three implementations we usually talk about, but instead it used two sign b=
its<br>
in the accummulator. If both sign bits were 0, it was positive; if both wer=
e<br>
1, it was negative; if they were different, it indicated that a previous<br=
>
operation had over- or underflown (the two bits were collapsed when saving =
to<br>
memory). The AGC did not allow shifting under that condition, but a machine=
<br>
that did could shift in an alternating pattern, or just one zero followed b=
y<br>
all ones, or one one followed by zeroes, or whatever.<br>
<br>
It could trap.<br>
<br>
> * Shifting left produces the result as if cast to the corresponding<br=
>
> unsigned type, shifted, and cast back, even in the case of negative nu=
mbers.<br>
<br>
Which already can trap, implementation-defined.<br>
<br>
> * Shifting by more than the number of bits in the (promoted) type rema=
ins<br>
> undefined behavior.=C2=A0 Or an unspecified result is another possibil=
ity.<br>
<br>
What's the point of defined unspecified behaviour?<br>
<br>
> Only the middle one changes; to me, that negative numbers can't be=
shifted<br>
> left is ridiculous.=C2=A0 Especially when there's a special except=
ion allowing<br>
> shifting left into the sign bit.<br>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
--<br></blockquote></div></div><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
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/Ifq39OuA-vU/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/Ifq39OuA-vU/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@isocpp.org</a>.</blockquote></div></div><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1778457.hZ8eUVjzd5%40tjmaciei-mobl1" =
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org=
/d/msgid/std-proposals/1778457.hZ8eUVjzd5%40tjmaciei-mobl1</a>.<br>
</blockquote></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" target=3D"_=
blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJEMUN8ccWvSrY2dafueQGMwtHh7UX34TgkF=
bh7Hc_skV9S7eQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAJEMUN8ccWvSrY2dafueQGMwtHh7UX34TgkFbh7Hc_skV9S7eQ%40mail.gmail.com</=
a>.<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/CAPCFJdTxJD-aTOa-XELjUTbQ4f%3Dru7Ekv3=
eknRSQfRw-A%2BHYGw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTxJD-a=
TOa-XELjUTbQ4f%3Dru7Ekv3eknRSQfRw-A%2BHYGw%40mail.gmail.com</a>.<br />
--089e01493f5e716ce20538c1fb57--
.
Author: Chris Hallock <christopherhallock@gmail.com>
Date: Fri, 29 Jul 2016 08:05:16 -0700 (PDT)
Raw View
------=_Part_189_772139775.1469804717008
Content-Type: multipart/alternative;
boundary="----=_Part_190_1765042942.1469804717008"
------=_Part_190_1765042942.1469804717008
Content-Type: text/plain; charset=UTF-8
On Thursday, July 28, 2016 at 9:23:47 PM UTC-4, Thiago Macieira wrote:
> > * Shifting left produces the result as if cast to the corresponding
> > unsigned type, shifted, and cast back, even in the case of negative
> numbers.
>
> Which already can trap, implementation-defined.
>
Besides having a negative or too-large right operand for the shift
operator, how can that trap?
--
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/830ea591-0e03-4f63-80e8-a52a287daaa1%40isocpp.org.
------=_Part_190_1765042942.1469804717008
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, July 28, 2016 at 9:23:47 PM UTC-4, Thiago Mac=
ieira wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> * Shiftin=
g left produces the result as if cast to the corresponding
<br>> unsigned type, shifted, and cast back, even in the case of negativ=
e numbers.
<br>
<br>Which already can trap, implementation-defined.<br></blockquote><div><b=
r>Besides having a negative or too-large right operand for the shift operat=
or, how can that trap?<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/830ea591-0e03-4f63-80e8-a52a287daaa1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/830ea591-0e03-4f63-80e8-a52a287daaa1=
%40isocpp.org</a>.<br />
------=_Part_190_1765042942.1469804717008--
------=_Part_189_772139775.1469804717008--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 29 Jul 2016 10:29:36 -0700
Raw View
On sexta-feira, 29 de julho de 2016 03:42:19 PDT Demi Obenour wrote:
> I don't think that arithmetic should ever result in undefined behavior. =
On
> every non-obsolete system that I know of, arithmetic cannot corrupt
> memory. I think that the result should be either fully specified or
> implementation-defined.
That's not the point. As Micha=C5=82 replied, the point is that the compile=
r can=20
assume it doesn't happen because you didn't mean to.
Implementation-defined: something must happen, even if you don't know what =
it=20
is and if the compiler can change its mind every time it is run, including =
in=20
many cases simply crash the application. If you want to depend on the=20
behaviour, you have to consult the compiler documentation and your code wil=
l=20
be unportable.
Undefined: it's not supposed to happen in conforming programs, so the compi=
ler=20
is allowed to assume that's not what you meant.
--=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/1537989.sStxT0y9BL%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 29 Jul 2016 10:39:58 -0700
Raw View
On sexta-feira, 29 de julho de 2016 08:05:16 PDT Chris Hallock wrote:
> On Thursday, July 28, 2016 at 9:23:47 PM UTC-4, Thiago Macieira wrote:
> > > * Shifting left produces the result as if cast to the corresponding
> > > unsigned type, shifted, and cast back, even in the case of negative
> >
> > numbers.
> >
> > Which already can trap, implementation-defined.
>
> Besides having a negative or too-large right operand for the shift
> operator, how can that trap?
It wasn't the shift that could trap. It was Melissa's suggestion of shifting
in unsigned, then converting back to signed.
4.8 [conv.integral] p3, "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."
That is, converting the unsigned result to signed could cause a trap.
I can't find anything in the C++ standard (N4606 draft) about trap
representations. The C11 standard does talk about it, though. The equivalent
wording is found in C11 6.3.1.3 p3, "Otherwise, [if] the new type is signed
and the value cannot be represented in it; either the result is
implementation-defined or an implementation-defined signal is raised."
Mind you, C11 does limit the integer types to sign-magnitude, one's complement
or two's complement, with exactly one sign bit. No other representation is
allowed (like the example I gave from the AGC).
--
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/1524506.UZbW8VRupG%40tjmaciei-mobl1.
.
Author: Demi Obenour <demiobenour@gmail.com>
Date: Fri, 29 Jul 2016 20:58:19 -0400
Raw View
--94eb2c122a08ec34c10538cfdcc0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Compilers assume undefined behavior never happens. This can create a
security hole where none existed.
On Jul 29, 2016 4:24 AM, "Micha=C5=82 Dominiak" <griwes@griwes.info> wrote:
> Undefined behavior isn't about memory corruption or whatever - it's
> strictly about enabling compiler optimizations, and documenting those is
> bound to be a pain.
>
> On Fri, Jul 29, 2016 at 9:42 AM Demi Obenour <demiobenour@gmail.com>
> wrote:
>
>> I don't think that arithmetic should ever result in undefined behavior.
>> On every non-obsolete system that I know of, arithmetic cannot corrupt
>> memory. I think that the result should be either fully specified or
>> implementation-defined.
>>
>> On Jul 28, 2016 9:23 PM, "Thiago Macieira" <thiago@macieira.org> wrote:
>>
>>> On quinta-feira, 28 de julho de 2016 15:07:49 PDT Myriachan wrote:
>>> > I personally think that the rules should be something like this:
>>> > * Shifting a signed number right can either shift in copies of the
>>> high bit
>>> > or shift in zeros, implementation-defined.
>>>
>>> Unless there are machines that do something different. I was reading
>>> about the
>>> Apollo Guidance Calculator and how it dealt with numbers. It wasn't any
>>> of the
>>> three implementations we usually talk about, but instead it used two
>>> sign bits
>>> in the accummulator. If both sign bits were 0, it was positive; if both
>>> were
>>> 1, it was negative; if they were different, it indicated that a previou=
s
>>> operation had over- or underflown (the two bits were collapsed when
>>> saving to
>>> memory). The AGC did not allow shifting under that condition, but a
>>> machine
>>> that did could shift in an alternating pattern, or just one zero
>>> followed by
>>> all ones, or one one followed by zeroes, or whatever.
>>>
>>> It could trap.
>>>
>>> > * Shifting left produces the result as if cast to the corresponding
>>> > unsigned type, shifted, and cast back, even in the case of negative
>>> numbers.
>>>
>>> Which already can trap, implementation-defined.
>>>
>>> > * Shifting by more than the number of bits in the (promoted) type
>>> remains
>>> > undefined behavior. Or an unspecified result is another possibility.
>>>
>>> What's the point of defined unspecified behaviour?
>>>
>>> > Only the middle one changes; to me, that negative numbers can't be
>>> shifted
>>> > left is ridiculous. Especially when there's a special exception
>>> allowing
>>> > shifting left into the sign bit.
>>>
>>> --
>>> 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 a topic in the
>>> Google Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Ifq39OuA-v=
U/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/isocpp.org/d/msgid/std-proposals/1778457.hZ=
8eUVjzd5%40tjmaciei-mobl1
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/CAJEMUN8ccW=
vSrY2dafueQGMwtHh7UX34TgkFbh7Hc_skV9S7eQ%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJEMUN8cc=
WvSrY2dafueQGMwtHh7UX34TgkFbh7Hc_skV9S7eQ%40mail.gmail.com?utm_medium=3Dema=
il&utm_source=3Dfooter>
>> .
>>
> --
> 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/isocpp.org/d/topic/std-proposals/Ifq39OuA-vU/=
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/isocpp.org/d/msgid/std-proposals/CAPCFJdTxJD-=
aTOa-XELjUTbQ4f%3Dru7Ekv3eknRSQfRw-A%2BHYGw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTxJD=
-aTOa-XELjUTbQ4f%3Dru7Ekv3eknRSQfRw-A%2BHYGw%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/CAJEMUN-0ZqfMG-KKRt2bSXPj0KLg9DM46wU0u6-Zi6bij97=
fAA%40mail.gmail.com.
--94eb2c122a08ec34c10538cfdcc0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Compilers assume undefined behavior never happens.=C2=A0 Thi=
s can create a security hole where none existed.</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Jul 29, 2016 4=
:24 AM, "Micha=C5=82 Dominiak" <<a href=3D"mailto:griwes@griwe=
s.info">griwes@griwes.info</a>> wrote:<br type=3D"attribution"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr">Undefined behavior isn't about m=
emory corruption or whatever - it's strictly about enabling compiler op=
timizations, and documenting those is bound to be a pain.<br></div><br><div=
class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Jul 29, 2016 at 9:42 AM Dem=
i Obenour <<a href=3D"mailto:demiobenour@gmail.com" target=3D"_blank">de=
miobenour@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<p dir=3D"ltr">I don't think that arithmetic should ever result in unde=
fined behavior.=C2=A0 On every non-obsolete system that I know of, arithmet=
ic cannot corrupt memory.=C2=A0 I think that the result should be either fu=
lly specified or implementation-defined.</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote"></div></div><div =
class=3D"gmail_extra"><div class=3D"gmail_quote">On Jul 28, 2016 9:23 PM, &=
quot;Thiago Macieira" <<a href=3D"mailto:thiago@macieira.org" targe=
t=3D"_blank">thiago@macieira.org</a>> wrote:<br type=3D"attribution"></d=
iv></div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">On quinta-feira, 28 de julho de 2016 15:07:49 PDT Myriac=
han wrote:<br>
> I personally think that the rules should be something like this:<br>
> * Shifting a signed number right can either shift in copies of the hig=
h bit<br>
> or shift in zeros, implementation-defined.<br>
<br>
Unless there are machines that do something different. I was reading about =
the<br>
Apollo Guidance Calculator and how it dealt with numbers. It wasn't any=
of the<br>
three implementations we usually talk about, but instead it used two sign b=
its<br>
in the accummulator. If both sign bits were 0, it was positive; if both wer=
e<br>
1, it was negative; if they were different, it indicated that a previous<br=
>
operation had over- or underflown (the two bits were collapsed when saving =
to<br>
memory). The AGC did not allow shifting under that condition, but a machine=
<br>
that did could shift in an alternating pattern, or just one zero followed b=
y<br>
all ones, or one one followed by zeroes, or whatever.<br>
<br>
It could trap.<br>
<br>
> * Shifting left produces the result as if cast to the corresponding<br=
>
> unsigned type, shifted, and cast back, even in the case of negative nu=
mbers.<br>
<br>
Which already can trap, implementation-defined.<br>
<br>
> * Shifting by more than the number of bits in the (promoted) type rema=
ins<br>
> undefined behavior.=C2=A0 Or an unspecified result is another possibil=
ity.<br>
<br>
What's the point of defined unspecified behaviour?<br>
<br>
> Only the middle one changes; to me, that negative numbers can't be=
shifted<br>
> left is ridiculous.=C2=A0 Especially when there's a special except=
ion allowing<br>
> shifting left into the sign bit.<br>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
--<br></blockquote></div></div><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
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/Ifq39OuA-vU/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/Ifq39OuA-vU/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@isocpp.org</a>.</blockquote></div></div><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1778457.hZ8eUVjzd5%40tjmaciei-mobl1" =
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org=
/d/msgid/std-proposals/1778457.hZ8eUVjzd5%40tjmaciei-mobl1</a>.<br>
</blockquote></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" target=3D"_=
blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAJEMUN8ccWvSrY2dafueQGMwtHh7UX34TgkF=
bh7Hc_skV9S7eQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CAJEMUN8ccWvSrY2dafueQGMwtHh7UX34TgkFbh7Hc_skV9S7eQ%40mail.gmail.com</=
a>.<br>
</blockquote></div>
<p></p>
-- <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/Ifq39OuA-vU/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Ifq39OuA-vU=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTxJD-aTOa-XELjUTbQ4f%3Dru7Ekv3=
eknRSQfRw-A%2BHYGw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAPCFJdTxJD-aTOa-XELjUTbQ4f%3Dru7Ekv3eknRSQfRw-A%2BHYGw%40mail.gma=
il.com</a>.<br>
</blockquote></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/CAJEMUN-0ZqfMG-KKRt2bSXPj0KLg9DM46wU0=
u6-Zi6bij97fAA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJEMUN-0ZqfMG-KK=
Rt2bSXPj0KLg9DM46wU0u6-Zi6bij97fAA%40mail.gmail.com</a>.<br />
--94eb2c122a08ec34c10538cfdcc0--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 29 Jul 2016 19:24:46 -0700
Raw View
On sexta-feira, 29 de julho de 2016 20:58:19 PDT Demi Obenour wrote:
> Compilers assume undefined behavior never happens. This can create a
> security hole where none existed.
That's a matter of interpretation. From the point of view of the standard, the
code was never correct in the first place. So the security hole always existed.
--
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/2264268.XWfVhEIKWF%40tjmaciei-mobl1.
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Sat, 30 Jul 2016 03:15:02 -0700 (PDT)
Raw View
------=_Part_446_1888548843.1469873702122
Content-Type: multipart/alternative;
boundary="----=_Part_447_231495521.1469873702122"
------=_Part_447_231495521.1469873702122
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8829=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8B=E5=8D=883:42:21=EF=BC=8CDemi Obenour=E5=86=99=E9=81=93=EF=BC=9A
>
> I don't think that arithmetic should ever result in undefined behavior. =
=20
> On every non-obsolete system that I know of, arithmetic cannot corrupt=20
> memory. I think that the result should be either fully specified or=20
> implementation-defined.
>
> To be mathematical, arithmetics can have undefined result. For example,=
=20
divide by zero is undefined in most arithmetic systems. If you want that=20
behavior to be defined, how do you specify the result? You will eventually=
=20
implement another system if you make such extensions.
Since integers in machines are bounded with limited precision, overflow=20
can't be naturally defined as an exact result. Treating overflow as=20
undefined result leads to efficient implementation in a simple way. You may=
=20
need systems with defined behavior on overflow; this is OK. But it should=
=20
not *override *the case where people can guarantee it is safe to work with=
=20
such undefined behavior.
=20
> On Jul 28, 2016 9:23 PM, "Thiago Macieira" <thi...@macieira.org=20
> <javascript:>> wrote:
>
>> On quinta-feira, 28 de julho de 2016 15:07:49 PDT Myriachan wrote:
>> > I personally think that the rules should be something like this:
>> > * Shifting a signed number right can either shift in copies of the hig=
h=20
>> bit
>> > or shift in zeros, implementation-defined.
>>
>> Unless there are machines that do something different. I was reading=20
>> about the
>> Apollo Guidance Calculator and how it dealt with numbers. It wasn't any=
=20
>> of the
>> three implementations we usually talk about, but instead it used two sig=
n=20
>> bits
>> in the accummulator. If both sign bits were 0, it was positive; if both=
=20
>> were
>> 1, it was negative; if they were different, it indicated that a previous
>> operation had over- or underflown (the two bits were collapsed when=20
>> saving to
>> memory). The AGC did not allow shifting under that condition, but a=20
>> machine
>> that did could shift in an alternating pattern, or just one zero followe=
d=20
>> by
>> all ones, or one one followed by zeroes, or whatever.
>>
>> It could trap.
>>
>> > * Shifting left produces the result as if cast to the corresponding
>> > unsigned type, shifted, and cast back, even in the case of negative=20
>> numbers.
>>
>> Which already can trap, implementation-defined.
>>
>> > * Shifting by more than the number of bits in the (promoted) type=20
>> remains
>> > undefined behavior. Or an unspecified result is another possibility.
>>
>> What's the point of defined unspecified behaviour?
>>
>> > Only the middle one changes; to me, that negative numbers can't be=20
>> shifted
>> > left is ridiculous. Especially when there's a special exception=20
>> allowing
>> > shifting left into the sign bit.
>>
>> --
>> 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 a topic in the=
=20
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit=20
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Ifq39OuA-vU=
/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to=20
>> std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1778457.hZ8=
eUVjzd5%40tjmaciei-mobl1
>> .
>>
>
--=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/f23be799-e209-431d-8bd5-7c63fa196cc7%40isocpp.or=
g.
------=_Part_447_231495521.1469873702122
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8829=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=E5=8D=883:42:21=EF=BC=8CDemi Obenour=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p =
dir=3D"ltr">I don't think that arithmetic should ever result in undefin=
ed behavior.=C2=A0 On every non-obsolete system that I know of, arithmetic =
cannot corrupt memory.=C2=A0 I think that the result should be either fully=
specified or implementation-defined.</p>
<div><br></div></blockquote><div>To be mathematical, arithmetics can have u=
ndefined result. For example, divide by zero is undefined in most arithmeti=
c systems. If you want that behavior to be defined, how do you specify the =
result? You will eventually implement another system if you make such exten=
sions.<br><br>Since integers in machines are bounded with limited precision=
, overflow can't be naturally defined as an exact result. Treating over=
flow as undefined result leads to efficient implementation in a simple way.=
You may need systems with defined behavior on overflow; this is OK. But it=
should not <i>override </i>the case where people can guarantee it is safe =
to work with such undefined behavior.<br>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div><div class=3D"gmail_quote">On Jul 28, 2016=
9:23 PM, "Thiago Macieira" <<a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"fSASb9SqBQAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">thi...@macieira.org</a>> wrote:<b=
r type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On quinta-feira, 28 d=
e julho de 2016 15:07:49 PDT Myriachan wrote:<br>
> I personally think that the rules should be something like this:<br>
> * Shifting a signed number right can either shift in copies of the hig=
h bit<br>
> or shift in zeros, implementation-defined.<br>
<br>
Unless there are machines that do something different. I was reading about =
the<br>
Apollo Guidance Calculator and how it dealt with numbers. It wasn't any=
of the<br>
three implementations we usually talk about, but instead it used two sign b=
its<br>
in the accummulator. If both sign bits were 0, it was positive; if both wer=
e<br>
1, it was negative; if they were different, it indicated that a previous<br=
>
operation had over- or underflown (the two bits were collapsed when saving =
to<br>
memory). The AGC did not allow shifting under that condition, but a machine=
<br>
that did could shift in an alternating pattern, or just one zero followed b=
y<br>
all ones, or one one followed by zeroes, or whatever.<br>
<br>
It could trap.<br>
<br>
> * Shifting left produces the result as if cast to the corresponding<br=
>
> unsigned type, shifted, and cast back, even in the case of negative nu=
mbers.<br>
<br>
Which already can trap, implementation-defined.<br>
<br>
> * Shifting by more than the number of bits in the (promoted) type rema=
ins<br>
> undefined behavior.=C2=A0 Or an unspecified result is another possibil=
ity.<br>
<br>
What's the point of defined unspecified behaviour?<br>
<br>
> Only the middle one changes; to me, that negative numbers can't be=
shifted<br>
> left is ridiculous.=C2=A0 Especially when there's a special except=
ion allowing<br>
> shifting left into the sign bit.<br>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"nofol=
low" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQ=
jCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D&=
#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;">=
macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" rel=3D"nofollow"=
target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/ur=
l?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHGRJdo5=
_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<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/Ifq39OuA-vU/unsubscribe" rel=3D"nofollow=
" target=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.c=
om/a/isocpp.org/d/topic/std-proposals/Ifq39OuA-vU/unsubscribe';return t=
rue;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/=
topic/std-proposals/Ifq39OuA-vU/unsubscribe';return true;">https://grou=
ps.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/Ifq39OuA-vU/<wbr=
>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"fSASb9SqBQAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return tru=
e;" onclick=3D"this.href=3D'javascript:';return true;">std-proposal=
....@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"fSASb9SqBQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/1778457.hZ8eUVjzd5%40tjmaciei-mobl1" =
rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'https://=
groups.google.com/a/isocpp.org/d/msgid/std-proposals/1778457.hZ8eUVjzd5%40t=
jmaciei-mobl1';return true;" onclick=3D"this.href=3D'https://groups=
..google.com/a/isocpp.org/d/msgid/std-proposals/1778457.hZ8eUVjzd5%40tjmacie=
i-mobl1';return true;">https://groups.google.com/a/<wbr>isocpp.org/d/ms=
gid/std-<wbr>proposals/1778457.hZ8eUVjzd5%<wbr>40tjmaciei-mobl1</a>.<br>
</blockquote></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/f23be799-e209-431d-8bd5-7c63fa196cc7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f23be799-e209-431d-8bd5-7c63fa196cc7=
%40isocpp.org</a>.<br />
------=_Part_447_231495521.1469873702122--
------=_Part_446_1888548843.1469873702122--
.
Author: Chris Hallock <christopherhallock@gmail.com>
Date: Sat, 30 Jul 2016 09:30:39 -0700 (PDT)
Raw View
------=_Part_551_269163947.1469896240055
Content-Type: multipart/alternative;
boundary="----=_Part_552_947798514.1469896240055"
------=_Part_552_947798514.1469896240055
Content-Type: text/plain; charset=UTF-8
On Friday, July 29, 2016 at 1:40:02 PM UTC-4, Thiago Macieira wrote:
>
> On sexta-feira, 29 de julho de 2016 08:05:16 PDT Chris Hallock wrote:
> > On Thursday, July 28, 2016 at 9:23:47 PM UTC-4, Thiago Macieira wrote:
> > > > * Shifting left produces the result as if cast to the corresponding
> > > > unsigned type, shifted, and cast back, even in the case of negative
> > > > numbers.
> > >
> > > Which already can trap, implementation-defined.
> >
> > Besides having a negative or too-large right operand for the shift
> > operator, how can that trap?
>
> It wasn't the shift that could trap. It was Melissa's suggestion of
> shifting
> in unsigned, then converting back to signed.
>
> 4.8 [conv.integral] p3, "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."
>
> That is, converting the unsigned result to signed could cause a trap.
>
So in C++, an implementation-defined value is allowed to cause undefined
behavior? That seems to break from the intent of C, which has the following
definitions:
*implementation-defined value*
> unspecified value where each implementation documents how the choice is
> made
> [...]
> *unspecified value*
> valid value of the relevant type where this International Standard imposes
> no requirements on which value is chosen in any instance
> NOTE An unspecified value cannot be a trap representation.
>
Granted, the note that prevents unspecified (and hence
implementation-defined) values from being trap representations is merely a
non-normative note.
--
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/84f86452-27b5-4617-87dd-f56d289fd01e%40isocpp.org.
------=_Part_552_947798514.1469896240055
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, July 29, 2016 at 1:40:02 PM UTC-4, Thiago Macie=
ira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On sexta-feira, 29 d=
e julho de 2016 08:05:16 PDT Chris Hallock wrote:
<br>> On Thursday, July 28, 2016 at 9:23:47 PM UTC-4, Thiago Macieira wr=
ote:
<br>> > > * Shifting left produces the result as if cast to the co=
rresponding
<br>> > > unsigned type, shifted, and cast back, even in the case =
of negative
<br>> > > numbers.
<br>> >=20
<br>> > Which already can trap, implementation-defined.
<br>>=20
<br>> Besides having a negative or too-large right operand for the shift
<br>> operator, how can that trap?
<br>
<br>It wasn't the shift that could trap. It was Melissa's suggestio=
n of shifting=20
<br>in unsigned, then converting back to signed.
<br>
<br>4.8 [conv.integral] p3, "If the destination type is signed, the va=
lue is=20
<br>unchanged if it can be represented in the destination type; otherwise, =
the=20
<br>value is implementation-defined."
<br>
<br>That is, converting the unsigned result to signed could cause a trap.<b=
r></blockquote><div><br>So in C++, an implementation-defined value is allow=
ed to cause undefined behavior? That seems to break from the intent of C, w=
hich has the following definitions:<br><br><blockquote style=3D"margin: 0px=
0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1e=
x;" class=3D"gmail_quote"><b>implementation-defined value</b><br>unspecifie=
d value where each implementation documents how the choice is made<br>[...]=
<br><b>unspecified value</b><br>valid value of the relevant type where this=
International Standard imposes no requirements on which value is chosen in=
any instance<br><font size=3D"1">NOTE=C2=A0=C2=A0=C2=A0 An unspecified val=
ue cannot be a trap representation.</font><br></blockquote><br>Granted, the=
note that prevents unspecified (and hence implementation-defined) values f=
rom being trap representations is merely a non-normative note.<br></div></d=
iv>
<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/84f86452-27b5-4617-87dd-f56d289fd01e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/84f86452-27b5-4617-87dd-f56d289fd01e=
%40isocpp.org</a>.<br />
------=_Part_552_947798514.1469896240055--
------=_Part_551_269163947.1469896240055--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 30 Jul 2016 10:39:22 -0700
Raw View
On s=C3=A1bado, 30 de julho de 2016 09:30:39 PDT Chris Hallock wrote:
> > It wasn't the shift that could trap. It was Melissa's suggestion of
> > shifting
> > in unsigned, then converting back to signed.
> >=20
> > 4.8 [conv.integral] p3, "If the destination type is signed, the value i=
s
> > unchanged if it can be represented in the destination type; otherwise, =
the
> > value is implementation-defined."
> >=20
> > That is, converting the unsigned result to signed could cause a trap.
>=20
> So in C++, an implementation-defined value is allowed to cause undefined
> behavior? That seems to break from the intent of C, which has the followi=
ng
> definitions:
That's not what I said. I didn't say it was undefined behaviour. I said tha=
t it=20
could trap.
> > *implementation-defined value*
> > unspecified value where each implementation documents how the choice is
> > made
> > [...]
> > *unspecified value*
> > valid value of the relevant type where this International Standard impo=
ses
> > no requirements on which value is chosen in any instance
> > NOTE An unspecified value cannot be a trap representation.
>=20
> Granted, the note that prevents unspecified (and hence
> implementation-defined) values from being trap representations is merely =
a
> non-normative note.
Hmm... but that should preclude from being a trap representation. Except th=
at=20
might be inefficient, since the value stored in the equivalent unsigned cou=
ld=20
literally be the trap representation (for two's complement, high bit set=20
followed by zeroes). If the implementation is not allowed to convert to the=
=20
trap, then the conversion needs to check if it is the trap representation=
=20
before and change to another, implementation-defined value.
--=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/2493064.qtOsSfkHBU%40tjmaciei-mobl1.
.
Author: Chris Hallock <christopherhallock@gmail.com>
Date: Sat, 30 Jul 2016 16:14:18 -0700 (PDT)
Raw View
------=_Part_155_960291265.1469920458245
Content-Type: multipart/alternative;
boundary="----=_Part_156_1228395033.1469920458245"
------=_Part_156_1228395033.1469920458245
Content-Type: text/plain; charset=UTF-8
On Saturday, July 30, 2016 at 1:39:26 PM UTC-4, Thiago Macieira wrote:
> > So in C++, an implementation-defined value is allowed to cause undefined
> > behavior? That seems to break from the intent of C, which has the
> following
> > definitions:
>
> That's not what I said. I didn't say it was undefined behaviour. I said
> that it
> could trap.
>
In C, an integer-to-signed-integer conversion that can't preserve the
original value results in either an implementation-defined value or an
implementation-defined signal being raised. In C++, the same conversion
results only in an implementation-defined value. If by "trap" you were
referring the signal, then that's only in C. If instead you were referring
to the possibility of a trap representation, then "trap" as a verb not the
most precise word because in C, accessing a trap representation (via
non-character type lvalues) explicitly triggers undefined behavior,
according to 6.2.6.1/5 (both C99 and C11). I had assumed you meant the
latter, which is why I mentioned undefined behavior.
--
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/c6a2683e-5269-4dc6-a3f1-bdbd276f10c7%40isocpp.org.
------=_Part_156_1228395033.1469920458245
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, July 30, 2016 at 1:39:26 PM UTC-4, Thiago Mac=
ieira wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> So in C++=
, an implementation-defined value is allowed to cause undefined
<br>> behavior? That seems to break from the intent of C, which has the =
following
<br>> definitions:
<br>
<br>That's not what I said. I didn't say it was undefined behaviour=
.. I said that it=20
<br>could trap.<br></blockquote><div><br>In C, an integer-to-signed-integer=
conversion that can't preserve the original value results in either an=
implementation-defined value or an implementation-defined signal being rai=
sed. In C++, the same conversion results only in an implementation-defined =
value. If by "trap" you were referring the signal, then that'=
s only in C. If instead you were referring to the possibility of a trap rep=
resentation, then "trap" as a verb not the most precise word beca=
use in C, accessing a trap representation (via non-character type lvalues) =
explicitly triggers undefined behavior, according to 6.2.6.1/5 (both C99 an=
d C11). I had assumed you meant the latter, which is why I mentioned undefi=
ned behavior.<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/c6a2683e-5269-4dc6-a3f1-bdbd276f10c7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c6a2683e-5269-4dc6-a3f1-bdbd276f10c7=
%40isocpp.org</a>.<br />
------=_Part_156_1228395033.1469920458245--
------=_Part_155_960291265.1469920458245--
.
Author: Demi Obenour <demiobenour@gmail.com>
Date: Sun, 31 Jul 2016 02:35:12 -0400
Raw View
--001a113bcc7e9c9d500538e8af1c
Content-Type: text/plain; charset=UTF-8
I like this, if shifting by too-large amounts has implementation-defined
results.
On Jul 28, 2016 6:07 PM, "Myriachan" <myriachan@gmail.com> wrote:
> On Wednesday, July 27, 2016 at 10:19:16 PM UTC-7, Thiago Macieira wrote:
>>
>> One more detail about x86: the manual simply says that it uses the lowest
>> 5
>> bits, but makes no mention of operations on 8- and 16-bit registers. That
>> leads me to conclude that logically shifting left or right by 16 on such
>> a
>> register should zero it. That doesn't apply to us on modern ABIs since
>> the
>> integer promotion rules say that the operation is executed on int, which
>> is
>> 32-bit. But don't assume that 16-bit ABIs are a thing of the past:
>> running
>> certain small sections of code in real mode is still required on x86.
>>
>>
> I confirmed this with experiment: shifting an 8-bit or 16-bit value by
> more than the number of bits in the register caused a full shift-out: the
> shift count was interpreted mod 32 rather than mod 8 or 16.
>
> I personally think that the rules should be something like this:
> * Shifting a signed number right can either shift in copies of the high
> bit or shift in zeros, implementation-defined.
> * Shifting left produces the result as if cast to the corresponding
> unsigned type, shifted, and cast back, even in the case of negative numbers.
> * Shifting by more than the number of bits in the (promoted) type remains
> undefined behavior. Or an unspecified result is another possibility.
>
> Only the middle one changes; to me, that negative numbers can't be shifted
> left is ridiculous. Especially when there's a special exception allowing
> shifting left into the sign bit.
>
> Melissa
>
> --
> 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/isocpp.org/d/topic/std-proposals/Ifq39OuA-vU/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/isocpp.org/d/msgid/std-proposals/5da7ad00-4432-426d-ace8-f1bb1ec3a89b%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5da7ad00-4432-426d-ace8-f1bb1ec3a89b%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CAJEMUN9jECzMGLYC_X6jKRx1f0yqMd1oimhdEjkujf13Zoj73w%40mail.gmail.com.
--001a113bcc7e9c9d500538e8af1c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">I like this, if shifting by too-large amounts has implementa=
tion-defined results.</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Jul 28, 2016 6=
:07 PM, "Myriachan" <<a href=3D"mailto:myriachan@gmail.com">my=
riachan@gmail.com</a>> wrote:<br type=3D"attribution"><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">On Wednesday, July 27, 2016 at 10:19:16 PM U=
TC-7, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">One mor=
e detail about x86: the manual simply says that it uses the lowest 5=20
<br>bits, but makes no mention of operations on 8- and 16-bit registers. Th=
at=20
<br>leads me to conclude that logically shifting left or right by 16 on suc=
h a=20
<br>register should zero it. That doesn't apply to us on modern ABIs si=
nce the=20
<br>integer promotion rules say that the operation is executed on int, whic=
h is=20
<br>32-bit. But don't assume that 16-bit ABIs are a thing of the past: =
running=20
<br>certain small sections of code in real mode is still required on x86.
<br>
<br></blockquote><div><br>I confirmed this with experiment: shifting an 8-b=
it or 16-bit value by more than the number of bits in the register caused a=
full shift-out: the shift count was interpreted mod 32 rather than mod 8 o=
r 16.<br><br>I personally think that the rules should be something like thi=
s:<br>* Shifting a signed number right can either shift in copies of the hi=
gh bit or shift in zeros, implementation-defined.<br>* Shifting left produc=
es the result as if cast to the corresponding unsigned type, shifted, and c=
ast back, even in the case of negative numbers.<br>* Shifting by more than =
the number of bits in the (promoted) type remains undefined behavior.=C2=A0=
Or an unspecified result is another possibility.<br><br>Only the middle on=
e changes; to me, that negative numbers can't be shifted left is ridicu=
lous.=C2=A0 Especially when there's a special exception allowing shifti=
ng left into the sign bit.<br><br>Melissa<br></div></div>
<p></p>
-- <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/Ifq39OuA-vU/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Ifq39OuA-vU=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5da7ad00-4432-426d-ace8-f1bb1ec3a89b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5da7ad00-4432-=
426d-ace8-f1bb1ec3a89b%40isocpp.org</a>.<br>
</blockquote></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/CAJEMUN9jECzMGLYC_X6jKRx1f0yqMd1oimhd=
Ejkujf13Zoj73w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJEMUN9jECzMGLYC=
_X6jKRx1f0yqMd1oimhdEjkujf13Zoj73w%40mail.gmail.com</a>.<br />
--001a113bcc7e9c9d500538e8af1c--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 30 Jul 2016 23:42:29 -0700
Raw View
On domingo, 31 de julho de 2016 02:35:12 PDT Demi Obenour wrote:
> I like this, if shifting by too-large amounts has implementation-defined
> results.
I believe one of the reasons that shifting currently can have undefined
behaviour is because of the trap representation for signed values. Shifting
can generate them. Other arithmetic operations are required to never produce
it.
In order to make shifting never have undefined behaviour, we'd have to either
allow production of trap representations, like the arithmetic operations, or
we'd have to require that the compiler check if it resulted in a trap and then
fix it.
--
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/9592419.uxCk8fDJCn%40tjmaciei-mobl1.
.
Author: Demi Obenour <demiobenour@gmail.com>
Date: Sun, 31 Jul 2016 04:06:01 -0400
Raw View
--94eb2c1245b662f3920538e9f4c0
Content-Type: text/plain; charset=UTF-8
Do integers have trap representations on any platform worth worrying
about? I don't know of any (ancient and obsolete platforms don't count),
and would prefer that integers be required not to have any.
On Jul 31, 2016 02:42, "Thiago Macieira" <thiago@macieira.org> wrote:
> On domingo, 31 de julho de 2016 02:35:12 PDT Demi Obenour wrote:
> > I like this, if shifting by too-large amounts has implementation-defined
> > results.
>
> I believe one of the reasons that shifting currently can have undefined
> behaviour is because of the trap representation for signed values. Shifting
> can generate them. Other arithmetic operations are required to never
> produce
> it.
>
> In order to make shifting never have undefined behaviour, we'd have to
> either
> allow production of trap representations, like the arithmetic operations,
> or
> we'd have to require that the compiler check if it resulted in a trap and
> then
> fix it.
>
> --
> 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 a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Ifq39OuA-vU/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/isocpp.org/d/msgid/std-proposals/9592419.uxCk8fDJCn%40tjmaciei-mobl1
> .
>
--
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/CAJEMUN9LODnq%3DkP3Y3Q2r-iU8ri9Q-x9ZyCjrUD5mwE7SJRudg%40mail.gmail.com.
--94eb2c1245b662f3920538e9f4c0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Do integers have trap representations on any platform worth =
worrying about?=C2=A0 I don't know of any (ancient and obsolete platfor=
ms don't count), and would prefer that integers be required not to have=
any.</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Jul 31, 2016 0=
2:42, "Thiago Macieira" <<a href=3D"mailto:thiago@macieira.org=
">thiago@macieira.org</a>> wrote:<br type=3D"attribution"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">On domingo, 31 de julho de 2016 02:35:12 PDT Demi Obenour =
wrote:<br>
> I like this, if shifting by too-large amounts has implementation-defin=
ed<br>
> results.<br>
<br>
I believe one of the reasons that shifting currently can have undefined<br>
behaviour is because of the trap representation for signed values. Shifting=
<br>
can generate them. Other arithmetic operations are required to never produc=
e<br>
it.<br>
<br>
In order to make shifting never have undefined behaviour, we'd have to =
either<br>
allow production of trap representations, like the arithmetic operations, o=
r<br>
we'd have to require that the compiler check if it resulted in a trap a=
nd then<br>
fix it.<br>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<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/Ifq39OuA-vU/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/Ifq39OuA-vU/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">std-proposals+unsubscrib=
e@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/9592419.uxCk8fDJCn%40tjmaciei-mobl1" =
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org=
/d/msgid/std-proposals/9592419.uxCk8fDJCn%40tjmaciei-mobl1</a>.<br>
</blockquote></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/CAJEMUN9LODnq%3DkP3Y3Q2r-iU8ri9Q-x9Zy=
CjrUD5mwE7SJRudg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJEMUN9LODnq%3=
DkP3Y3Q2r-iU8ri9Q-x9ZyCjrUD5mwE7SJRudg%40mail.gmail.com</a>.<br />
--94eb2c1245b662f3920538e9f4c0--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 31 Jul 2016 07:06:49 -0700 (PDT)
Raw View
------=_Part_716_383198433.1469974009991
Content-Type: multipart/alternative;
boundary="----=_Part_717_1087621410.1469974009991"
------=_Part_717_1087621410.1469974009991
Content-Type: text/plain; charset=UTF-8
On Sunday, July 31, 2016 at 4:06:03 AM UTC-4, Demi Obenour wrote:
>
> Do integers have trap representations on any platform worth worrying about?
>
Any platform that currently supports C++ is "worth worrying about". We
shouldn't arbitrarily cut platforms off from C++ just because it creates a
minor inconvenience for some users. Indeed, it's not even a "minor
inconvenience" for them. The standard allows this behavior; it just doesn't
*guarantee* it.
That's why I much prefer to keep the existing wording, but to provide a
constexpr variable that you can `static_assert`/`if constexpr` on which, if
true, will guarantee you specific behavior. That's the most effective way
of standardizing behavior for the majority of platforms *without* cutting
off platforms that do unusual things.
Lastly, top-posting makes it very difficult to follow the thread of
conversation. Please reply beneath the post you're replying to.
I don't know of any (ancient and obsolete platforms don't count), and would
> prefer that integers be required not to have any.
>
--
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/823b86f7-5189-44f2-8a74-1b48f950dcba%40isocpp.org.
------=_Part_717_1087621410.1469974009991
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, July 31, 2016 at 4:06:03 AM UTC-4, Demi Obenour=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">Do integ=
ers have trap representations on any platform worth worrying about?</p></bl=
ockquote><div><br>Any platform that currently supports C++ is "worth w=
orrying about". We shouldn't arbitrarily cut platforms off from C+=
+ just because it creates a minor inconvenience for some users. Indeed, it&=
#39;s not even a "minor inconvenience" for them. The standard all=
ows this behavior; it just doesn't *guarantee* it.<br><br>That's wh=
y I much prefer to keep the existing wording, but to provide a constexpr va=
riable that you can `static_assert`/`if constexpr` on which, if true, will =
guarantee you specific behavior. That's the most effective way of stand=
ardizing behavior for the majority of platforms <i>without</i> cutting off =
platforms that do unusual things.<br><br>Lastly, top-posting makes it very =
difficult to follow the thread of conversation. Please reply beneath the po=
st you're replying to.<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><p dir=3D"ltr">I don't know of any (ancient and obsolete plat=
forms don't count), and would prefer that integers be required not to h=
ave any.</p>
</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/823b86f7-5189-44f2-8a74-1b48f950dcba%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/823b86f7-5189-44f2-8a74-1b48f950dcba=
%40isocpp.org</a>.<br />
------=_Part_717_1087621410.1469974009991--
------=_Part_716_383198433.1469974009991--
.
Author: Demi Obenour <demiobenour@gmail.com>
Date: Mon, 01 Aug 2016 17:12:01 -0400
Raw View
--=-k3KABKyprEEY57XLphf4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sun, 2016-07-31 at 07:06 -0700, Nicol Bolas wrote:
> On Sunday, July 31, 2016 at 4:06:03 AM UTC-4, Demi Obenour wrote:> > Do i=
ntegers have trap representations on any platform worth worrying about?
> > > >=20
Any platform that currently supports C++ is "worth worrying about". We shou=
ldn't arbitrarily cut platforms off from C++ just because it creates a mino=
r inconvenience for some users. Indeed, it's not even a "minor inconvenienc=
e" for them. The standard allows this behavior; it just doesn't *guarantee*=
it.>=20
That's why I much prefer to keep the existing wording, but to provide a con=
stexpr variable that you can `static_assert`/`if constexpr` on which, if tr=
ue, will guarantee you specific behavior. That's the most effective way of =
standardizing behavior for the majority of platforms without cutting off pl=
atforms that do unusual things.>=20
Lastly, top-posting makes it very difficult to follow the thread of convers=
ation. Please reply beneath the post you're replying to.>=20
> > > > I don't know of any (ancient and obsolete platforms don't count), a=
nd would prefer that integers be required not to have any.
By "worth worrying about" I mean "used on any system in use today, that
one can name". =C2=A0I can't think of any where integers have trap
representations. =C2=A0Can you name a specific platform?
--=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/1470085921.17218.0.camel%40gmail.com.
--=-k3KABKyprEEY57XLphf4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><div>On Sun, 2016-07-31 at 07:06 -0700, Nicol Bola=
s wrote:</div><blockquote type=3D"cite"><div dir=3D"ltr">On Sunday, July 31=
, 2016 at 4:06:03 AM UTC-4, Demi Obenour wrote:<blockquote type=3D"cite"><p=
dir=3D"ltr">Do integers have trap representations on any platform worth wo=
rrying about?</p><br></blockquote><div><br>Any platform that currently supp=
orts C++ is "worth worrying about". We shouldn't arbitrarily cut platforms =
off from C++ just because it creates a minor inconvenience for some users. =
Indeed, it's not even a "minor inconvenience" for them. The standard allows=
this behavior; it just doesn't *guarantee* it.<br><br>That's why I much pr=
efer to keep the existing wording, but to provide a constexpr variable that=
you can `static_assert`/`if constexpr` on which, if true, will guarantee y=
ou specific behavior. That's the most effective way of standardizing behavi=
or for the majority of platforms <i>without</i> cutting off platforms that =
do unusual things.<br><br>Lastly, top-posting makes it very difficult to fo=
llow the thread of conversation. Please reply beneath the post you're reply=
ing to.<br><br></div><blockquote type=3D"cite"><p dir=3D"ltr">I don't know =
of any (ancient and obsolete platforms don't count), and would prefer that =
integers be required not to have any.</p>
<br></blockquote></div></blockquote><div><br></div><div>By "worth worrying =
about" I mean "used on any system in use today, that one can name". I=
can't think of any where integers have trap representations. Can you=
name a specific platform?</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/1470085921.17218.0.camel%40gmail.com?=
utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/a/isocpp.=
org/d/msgid/std-proposals/1470085921.17218.0.camel%40gmail.com</a>.<br />
--=-k3KABKyprEEY57XLphf4--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 01 Aug 2016 16:45:35 -0700
Raw View
On segunda-feira, 1 de agosto de 2016 17:12:01 PDT Demi Obenour wrote:
> That's why I much prefer to keep the existing wording, but to provide a
> constexpr variable that you can `static_assert`/`if constexpr` on which, if
> true, will guarantee you specific behavior. That's the most effective way
> of standardizing behavior for the majority of platforms without cutting off
> platforms that do unusual things.>
I have to question that. If you're writing code intended to be portable, then
either you don't take advantage of those optimisations or you write code next
to it as a fallback. For these low-level operations, the compiler will
probably do what you wanted anyway, so there's no gain in having two code
paths.
If you're going to write non-portable code anyway, then what's the point of
the constexpr values? To static_assert and cause a compilation error?
--
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/13916129.YKkF5O4DgY%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 1 Aug 2016 17:47:49 -0700 (PDT)
Raw View
------=_Part_1194_1778526115.1470098869252
Content-Type: multipart/alternative;
boundary="----=_Part_1195_1581534608.1470098869260"
------=_Part_1195_1581534608.1470098869260
Content-Type: text/plain; charset=UTF-8
On Monday, August 1, 2016 at 7:45:43 PM UTC-4, Thiago Macieira wrote:
>
> On segunda-feira, 1 de agosto de 2016 17:12:01 PDT Demi Obenour wrote:
> > That's why I much prefer to keep the existing wording, but to provide a
> > constexpr variable that you can `static_assert`/`if constexpr` on which,
> if
> > true, will guarantee you specific behavior. That's the most effective
> way
> > of standardizing behavior for the majority of platforms without cutting
> off
> > platforms that do unusual things.>
>
> I have to question that. If you're writing code intended to be portable,
> then
> either you don't take advantage of those optimisations or you write code
> next
> to it as a fallback. For these low-level operations, the compiler will
> probably do what you wanted anyway, so there's no gain in having two code
> paths.
>
> If you're going to write non-portable code anyway, then what's the point
> of
> the constexpr values? To static_assert and cause a compilation error?
Yes. Or to `if constexpr` around the places where you rely on such behavior.
Consider writing a type that implements a two's complement integer, with
all bitshifting and so forth working in accord with platform expectations,
but it'll be slower than actual hardware support. If the `constexpr`
variable is `true`, then you know that you can use the default type `int`,
and just use the default `int` operations. If not, then you have to build
them based on unsigned integer operations and such.
The goal there is not to write "non-portable code". The goal is to write
code that performs as well as the platform allows, but without using a
bunch of platform-specific `#ifdef`s and the like.
We're not talking about "non-portable code". It *is* portable; just not as
portable as C++ itself is. It'll run on Windows, Android, Linux, MacOSX,
iOS, and many other platforms. You will run on the *majority* of C++
platforms, but not on *all of them*.
The reality is that a lot of people do write code that will work on all of
those platforms, but cannot work on other oddball cases. I think it's a
good idea to have the standard recognize this fact, that the majority of
systems have one answer to many of the implementation-defined cases, and
that users ought to be able to query if the current platform is one of them.
That way, I can write code that will fail to compile if someone takes it to
an oddball system, rather than simply having subtle errors.
--
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/1b64f695-0452-444c-bb70-80d5520256b4%40isocpp.org.
------=_Part_1195_1581534608.1470098869260
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, August 1, 2016 at 7:45:43 PM UTC-4, Thi=
ago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On segunda-=
feira, 1 de agosto de 2016 17:12:01 PDT Demi Obenour wrote:
<br>> That's why I much prefer to keep the existing wording, but to =
provide a
<br>> constexpr variable that you can `static_assert`/`if constexpr` on =
which, if
<br>> true, will guarantee you specific behavior. That's the most ef=
fective way
<br>> of standardizing behavior for the majority of platforms without cu=
tting off
<br>> platforms that do unusual things.>=20
<br>
<br>I have to question that. If you're writing code intended to be port=
able, then=20
<br>either you don't take advantage of those optimisations or you write=
code next=20
<br>to it as a fallback. For these low-level operations, the compiler will=
=20
<br>probably do what you wanted anyway, so there's no gain in having tw=
o code=20
<br>paths.
<br>
<br>If you're going to write non-portable code anyway, then what's =
the point of=20
<br>the constexpr values? To static_assert and cause a compilation error?</=
blockquote><div><br>Yes. Or to `if constexpr` around the places where you r=
ely on such behavior.<br><br>Consider writing a type that implements a two&=
#39;s complement integer, with all bitshifting and so forth working in acco=
rd with platform expectations, but it'll be slower than actual hardware=
support. If the `constexpr` variable is `true`, then you know that you can=
use the default type `int`, and just use the default `int` operations. If =
not, then you have to build them based on unsigned integer operations and s=
uch.</div><br>The goal there is not to write "non-portable code".=
The goal is to write code that performs as well as the platform allows, bu=
t without using a bunch of platform-specific `#ifdef`s and the like.<br><br=
>We're not talking about "non-portable code". It <i>is</i> po=
rtable; just not as portable as C++ itself is. It'll run on Windows, An=
droid, Linux, MacOSX, iOS, and many other platforms. You will run on the <i=
>majority</i> of C++ platforms, but not on <i>all of them</i>.<br><br>The r=
eality is that a lot of people do write code that will work on all of those=
platforms, but cannot work on other oddball cases. I think it's a good=
idea to have the standard recognize this fact, that the majority of system=
s have one answer to many of the implementation-defined cases, and that use=
rs ought to be able to query if the current platform is one of them.<br><br=
>That way, I can write code that will fail to compile if someone takes it t=
o an oddball system, rather than simply having subtle errors.<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/1b64f695-0452-444c-bb70-80d5520256b4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1b64f695-0452-444c-bb70-80d5520256b4=
%40isocpp.org</a>.<br />
------=_Part_1195_1581534608.1470098869260--
------=_Part_1194_1778526115.1470098869252--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 1 Aug 2016 17:53:11 -0700 (PDT)
Raw View
------=_Part_1173_177059502.1470099191571
Content-Type: multipart/alternative;
boundary="----=_Part_1174_2068864870.1470099191571"
------=_Part_1174_2068864870.1470099191571
Content-Type: text/plain; charset=UTF-8
On Monday, August 1, 2016 at 8:47:49 PM UTC-4, Nicol Bolas wrote:
>
> On Monday, August 1, 2016 at 7:45:43 PM UTC-4, Thiago Macieira wrote:
>>
>> On segunda-feira, 1 de agosto de 2016 17:12:01 PDT Demi Obenour wrote:
>> > That's why I much prefer to keep the existing wording, but to provide a
>> > constexpr variable that you can `static_assert`/`if constexpr` on
>> which, if
>> > true, will guarantee you specific behavior. That's the most effective
>> way
>> > of standardizing behavior for the majority of platforms without cutting
>> off
>> > platforms that do unusual things.>
>>
>> I have to question that. If you're writing code intended to be portable,
>> then
>> either you don't take advantage of those optimisations or you write code
>> next
>> to it as a fallback. For these low-level operations, the compiler will
>> probably do what you wanted anyway, so there's no gain in having two code
>> paths.
>>
>> If you're going to write non-portable code anyway, then what's the point
>> of
>> the constexpr values? To static_assert and cause a compilation error?
>
>
> Yes. Or to `if constexpr` around the places where you rely on such
> behavior.
>
> Consider writing a type that implements a two's complement integer, with
> all bitshifting and so forth working in accord with platform expectations,
> but it'll be slower than actual hardware support. If the `constexpr`
> variable is `true`, then you know that you can use the default type `int`,
> and just use the default `int` operations. If not, then you have to build
> them based on unsigned integer operations and such.
>
> The goal there is not to write "non-portable code". The goal is to write
> code that performs as well as the platform allows, but without using a
> bunch of platform-specific `#ifdef`s and the like.
>
> We're not talking about "non-portable code". It *is* portable; just not
> as portable as C++ itself is. It'll run on Windows, Android, Linux, MacOSX,
> iOS, and many other platforms. You will run on the *majority* of C++
> platforms, but not on *all of them*.
>
> The reality is that a lot of people do write code that will work on all of
> those platforms, but cannot work on other oddball cases. I think it's a
> good idea to have the standard recognize this fact, that the majority of
> systems have one answer to many of the implementation-defined cases, and
> that users ought to be able to query if the current platform is one of them.
>
> That way, I can write code that will fail to compile if someone takes it
> to an oddball system, rather than simply having subtle errors.
>
Think of it as an expansion of `std::numeric_limits::is_iec539`. We can
detect if a particular platform supports IEEE-754-style floats. We're just
asking for similar queries for various other operations.
--
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/6558f232-a64e-41c0-86dc-51fb4401e430%40isocpp.org.
------=_Part_1174_2068864870.1470099191571
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, August 1, 2016 at 8:47:49 PM UTC-4, Nicol Bolas=
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">On Mon=
day, August 1, 2016 at 7:45:43 PM UTC-4, Thiago Macieira wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex">On segunda-feira, 1 de agosto de 2016 17:12:01 =
PDT Demi Obenour wrote:
<br>> That's why I much prefer to keep the existing wording, but to =
provide a
<br>> constexpr variable that you can `static_assert`/`if constexpr` on =
which, if
<br>> true, will guarantee you specific behavior. That's the most ef=
fective way
<br>> of standardizing behavior for the majority of platforms without cu=
tting off
<br>> platforms that do unusual things.>=20
<br>
<br>I have to question that. If you're writing code intended to be port=
able, then=20
<br>either you don't take advantage of those optimisations or you write=
code next=20
<br>to it as a fallback. For these low-level operations, the compiler will=
=20
<br>probably do what you wanted anyway, so there's no gain in having tw=
o code=20
<br>paths.
<br>
<br>If you're going to write non-portable code anyway, then what's =
the point of=20
<br>the constexpr values? To static_assert and cause a compilation error?</=
blockquote><div><br>Yes. Or to `if constexpr` around the places where you r=
ely on such behavior.<br><br>Consider writing a type that implements a two&=
#39;s complement integer, with all bitshifting and so forth working in acco=
rd with platform expectations, but it'll be slower than actual hardware=
support. If the `constexpr` variable is `true`, then you know that you can=
use the default type `int`, and just use the default `int` operations. If =
not, then you have to build them based on unsigned integer operations and s=
uch.</div><br>The goal there is not to write "non-portable code".=
The goal is to write code that performs as well as the platform allows, bu=
t without using a bunch of platform-specific `#ifdef`s and the like.<br><br=
>We're not talking about "non-portable code". It <i>is</i> po=
rtable; just not as portable as C++ itself is. It'll run on Windows, An=
droid, Linux, MacOSX, iOS, and many other platforms. You will run on the <i=
>majority</i> of C++ platforms, but not on <i>all of them</i>.<br><br>The r=
eality is that a lot of people do write code that will work on all of those=
platforms, but cannot work on other oddball cases. I think it's a good=
idea to have the standard recognize this fact, that the majority of system=
s have one answer to many of the implementation-defined cases, and that use=
rs ought to be able to query if the current platform is one of them.<br><br=
>That way, I can write code that will fail to compile if someone takes it t=
o an oddball system, rather than simply having subtle errors.<br></div></bl=
ockquote><div><br>Think of it as an expansion of `std::numeric_limits::is_i=
ec539`. We can detect if a particular platform supports IEEE-754-style floa=
ts. We're just asking for similar queries for various other operations.=
<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/6558f232-a64e-41c0-86dc-51fb4401e430%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6558f232-a64e-41c0-86dc-51fb4401e430=
%40isocpp.org</a>.<br />
------=_Part_1174_2068864870.1470099191571--
------=_Part_1173_177059502.1470099191571--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 01 Aug 2016 19:29:32 -0700
Raw View
On segunda-feira, 1 de agosto de 2016 17:47:49 PDT Nicol Bolas wrote:
> Yes. Or to `if constexpr` around the places where you rely on such behavior.
>
> Consider writing a type that implements a two's complement integer, with
> all bitshifting and so forth working in accord with platform expectations,
> but it'll be slower than actual hardware support. If the `constexpr`
> variable is `true`, then you know that you can use the default type `int`,
> and just use the default `int` operations. If not, then you have to build
> them based on unsigned integer operations and such.
My argument was that if you did write it using portable code using unsigned
integers, compilers today are smart enough to produce the most optimal code
that is identical to the signed integer two's complement on those machines.
But a quick test for signed integer overflow shows the current compilers don't
detect it. So I withdraw my argument.
> The goal there is not to write "non-portable code". The goal is to write
> code that performs as well as the platform allows, but without using a
> bunch of platform-specific `#ifdef`s and the like.
And just like I explained elsewhere in this thread, using memcpy is both
correct and the most efficient way of doing certain things. I was arguing that
relying on the "two's complementness" wouldn't produce better code than the
equivalent portable code.
Also note that not only must you check with if constexpr, you must also tell
the compiler that you're "abusing" that definition, such as by relying on the
overflow of signed integers. To do that, today, you have to use things like
__builtin_sadd_overflow and that doesn't require a constexpr if value.
I believe it would be more useful to define a number of primitive operations
that are guaranteed to operate like two's complement. On the modern machines
where that is the norm, they would be just like add, sub, and, or, xor, etc.
That's not to the exclusion of the constexpr value, but I would say are of
higher value.
> We're not talking about "non-portable code". It *is* portable; just not as
> portable as C++ itself is. It'll run on Windows, Android, Linux, MacOSX,
> iOS, and many other platforms. You will run on the *majority* of C++
> platforms, but not on *all of them*.
I understand what you're trying to say. The counter-example of my own argument
is from your other email:
> Think of it as an expansion of `std::numeric_limits::is_iec539`. We can
> detect if a particular platform supports IEEE-754-style floats. We're just
> asking for similar queries for various other operations.
I've done that because the compiler wasn't able to detect what I meant with
the "correct" code using math.h.
> The reality is that a lot of people do write code that will work on all of
> those platforms, but cannot work on other oddball cases. I think it's a
> good idea to have the standard recognize this fact, that the majority of
> systems have one answer to many of the implementation-defined cases, and
> that users ought to be able to query if the current platform is one of them.
>
> That way, I can write code that will fail to compile if someone takes it to
> an oddball system, rather than simply having subtle errors.
Indeed.
--
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/18894806.lYDv1AuBZK%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 1 Aug 2016 21:04:45 -0700 (PDT)
Raw View
------=_Part_1721_453153498.1470110685692
Content-Type: multipart/alternative;
boundary="----=_Part_1722_505935770.1470110685692"
------=_Part_1722_505935770.1470110685692
Content-Type: text/plain; charset=UTF-8
On Monday, August 1, 2016 at 10:29:36 PM UTC-4, Thiago Macieira wrote:
>
> On segunda-feira, 1 de agosto de 2016 17:47:49 PDT Nicol Bolas wrote:
> > Yes. Or to `if constexpr` around the places where you rely on such
> behavior.
> >
> > Consider writing a type that implements a two's complement integer, with
> > all bitshifting and so forth working in accord with platform
> expectations,
> > but it'll be slower than actual hardware support. If the `constexpr`
> > variable is `true`, then you know that you can use the default type
> `int`,
> > and just use the default `int` operations. If not, then you have to
> build
> > them based on unsigned integer operations and such.
>
> My argument was that if you did write it using portable code using
> unsigned
> integers, compilers today are smart enough to produce the most optimal
> code
> that is identical to the signed integer two's complement on those
> machines.
>
> But a quick test for signed integer overflow shows the current compilers
> don't
> detect it. So I withdraw my argument.
>
> > The goal there is not to write "non-portable code". The goal is to write
> > code that performs as well as the platform allows, but without using a
> > bunch of platform-specific `#ifdef`s and the like.
>
> And just like I explained elsewhere in this thread, using memcpy is both
> correct and the most efficient way of doing certain things. I was arguing
> that
> relying on the "two's complementness" wouldn't produce better code than
> the
> equivalent portable code.
>
> Also note that not only must you check with if constexpr, you must also
> tell
> the compiler that you're "abusing" that definition, such as by relying on
> the
> overflow of signed integers. To do that, today, you have to use things
> like
> __builtin_sadd_overflow and that doesn't require a constexpr if value.
>
By defining the constexpr variable, the compiler knows that you're relying
on it and is promising to provide it. After all, compilers aren't exactly
free to change such behavior willy-nilly, considering how much code already
relies on this kind of behavior.
We're talking about pretty stable stuff.
I believe it would be more useful to define a number of primitive
> operations
> that are guaranteed to operate like two's complement. On the modern
> machines
> where that is the norm, they would be just like add, sub, and, or, xor,
> etc.
> That's not to the exclusion of the constexpr value, but I would say are of
> higher value.
>
The problem with this solution is that, rather than standardizing existing
practice, you're creating a *new* standard that people would be expected to
use. We all know what happens when you introduce a new standard for
something that there's a current standard for: some will use it and some
will continue doing their own thing. Legacy code will remain untouched, and
thus live in implementation-defined land.
The goal of my solution is to make code that currently lives in
implementation-defined land well-defined. That you're not merely providing *some
way* to access this standard behavior, but that the current way people do
so *is that way*.
--
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/18bb4509-2679-4488-88bc-5c58e1fbd16c%40isocpp.org.
------=_Part_1722_505935770.1470110685692
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, August 1, 2016 at 10:29:36 PM UTC-4, Thiago Mac=
ieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On segunda-feira, =
1 de agosto de 2016 17:47:49 PDT Nicol Bolas wrote:
<br>> Yes. Or to `if constexpr` around the places where you rely on such=
behavior.
<br>>=20
<br>> Consider writing a type that implements a two's complement int=
eger, with
<br>> all bitshifting and so forth working in accord with platform expec=
tations,
<br>> but it'll be slower than actual hardware support. If the `cons=
texpr`
<br>> variable is `true`, then you know that you can use the default typ=
e `int`,
<br>> and just use the default `int` operations. If not, then you have t=
o build
<br>> them based on unsigned integer operations and such.
<br>
<br>My argument was that if you did write it using portable code using unsi=
gned=20
<br>integers, compilers today are smart enough to produce the most optimal =
code=20
<br>that is identical to the signed integer two's complement on those m=
achines.
<br>
<br>But a quick test for signed integer overflow shows the current compiler=
s don't=20
<br>detect it. So I withdraw my argument.
<br>
<br>> The goal there is not to write "non-portable code". The =
goal is to write
<br>> code that performs as well as the platform allows, but without usi=
ng a
<br>> bunch of platform-specific `#ifdef`s and the like.
<br>
<br>And just like I explained elsewhere in this thread, using memcpy is bot=
h=20
<br>correct and the most efficient way of doing certain things. I was argui=
ng that=20
<br>relying on the "two's complementness" wouldn't produc=
e better code than the=20
<br>equivalent portable code.
<br>
<br>Also note that not only must you check with if constexpr, you must also=
tell=20
<br>the compiler that you're "abusing" that definition, such =
as by relying on the=20
<br>overflow of signed integers. To do that, today, you have to use things =
like=20
<br>__builtin_sadd_overflow and that doesn't require a constexpr if val=
ue.<br></blockquote><div><br>By defining the constexpr variable, the compil=
er knows that you're relying on it and is promising to provide it. Afte=
r all, compilers aren't exactly free to change such behavior willy-nill=
y, considering how much code already relies on this kind of behavior.<br><b=
r>We're talking about pretty stable stuff.<br><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">
I believe it would be more useful to define a number of primitive operation=
s=20
<br>that are guaranteed to operate like two's complement. On the modern=
machines=20
<br>where that is the norm, they would be just like add, sub, and, or, xor,=
etc.=20
<br>That's not to the exclusion of the constexpr value, but I would say=
are of=20
<br>higher value.<br></blockquote><div><br>The problem with this solution i=
s that, rather than standardizing existing practice, you're creating a =
<i>new</i> standard that people would be expected to use. We all know what =
happens when you introduce a new standard for something that there's a =
current standard for: some will use it and some will continue doing their o=
wn thing. Legacy code will remain untouched, and thus live in implementatio=
n-defined land.<br><br>The goal of my solution is to make code that current=
ly lives in implementation-defined land well-defined. That you're not m=
erely providing <i>some way</i> to access this standard behavior, but that =
the current way people do so <i>is that way</i>.<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/18bb4509-2679-4488-88bc-5c58e1fbd16c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/18bb4509-2679-4488-88bc-5c58e1fbd16c=
%40isocpp.org</a>.<br />
------=_Part_1722_505935770.1470110685692--
------=_Part_1721_453153498.1470110685692--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 01 Aug 2016 22:00:46 -0700
Raw View
On segunda-feira, 1 de agosto de 2016 21:04:45 PDT Nicol Bolas wrote:
> > Also note that not only must you check with if constexpr, you must also
> > tell
> > the compiler that you're "abusing" that definition, such as by relying on
> > the
> > overflow of signed integers. To do that, today, you have to use things
> > like
> > __builtin_sadd_overflow and that doesn't require a constexpr if value.
>
> By defining the constexpr variable, the compiler knows that you're relying
> on it and is promising to provide it. After all, compilers aren't exactly
> free to change such behavior willy-nilly, considering how much code already
> relies on this kind of behavior.
That may not be enough. First, you may be asking for too much. You're asking
for the compiler to detect that in:
if constexpr (std::numeric_traits<int>::is_twos_complement)
result = i + 1 > i;
it should ignore the general C++ rule that signed overflow is UB and implement
a defined behaviour that only applies to two's complement signed numbers. How
would it know that that's what you meant? What other behaviours of signed
two's complement must it know? Which ones are meant and which ones are not?
How about tiny differences between how two's complement implement certain
functionality? Do we need a trait for every single operation?
Second, how far does that propagate? Would it propagate to inline functions
called from inside that check? How about code dependent on result?
> We're talking about pretty stable stuff.
>
> > I believe it would be more useful to define a number of primitive
> > operations
> > that are guaranteed to operate like two's complement. On the modern
> > machines
> > where that is the norm, they would be just like add, sub, and, or, xor,
> > etc.
> > That's not to the exclusion of the constexpr value, but I would say are of
> > higher value.
>
> The problem with this solution is that, rather than standardizing existing
> practice, you're creating a *new* standard that people would be expected to
> use. We all know what happens when you introduce a new standard for
> something that there's a current standard for: some will use it and some
> will continue doing their own thing. Legacy code will remain untouched, and
> thus live in implementation-defined land.
I still think a library solution is better for this, even if the
implementation (like type_trait's) requires compiler assistance to be
efficiently written.
We're not standardising standard practice because there isn't such a thing.
Code that is currently UB is not standard practice. The fact that it may be
working under GCC on x86 does not mean it currently works with Sun Studio on
SPARC.
Either way we go, it requires changes to existing code to tell the compiler
that the new behaviour is expected.
> The goal of my solution is to make code that currently lives in
> implementation-defined land well-defined. That you're not merely providing
> *some way* to access this standard behavior, but that the current way
> people do so *is that way*.
If it lives on implementation-defined land, it's already defined and doesn't
need changes. It's already working.
We're either talking about making that code portable or to make UB code have
defined behaviour. If you meant the latter, then what I said above applies:
it's not standard now.
If you meant the former, then we'd have to choose which implementation's
implementation-defined behaviour we'd select, in detriment to other
implementations' choices. But either way, code still needs to change.
--
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/2795183.cdIqbzPLr0%40tjmaciei-mobl1.
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Tue, 2 Aug 2016 00:48:44 -0700 (PDT)
Raw View
------=_Part_3575_99426831.1470124124212
Content-Type: multipart/alternative;
boundary="----=_Part_3576_435910929.1470124124212"
------=_Part_3576_435910929.1470124124212
Content-Type: text/plain; charset=UTF-8
On Tuesday, 2 August 2016 05:04:46 UTC+1, Nicol Bolas wrote:
>
> By defining the constexpr variable, the compiler knows that you're relying
> on it and is promising to provide it. After all, compilers aren't exactly
> free to change such behavior willy-nilly, considering how much code already
> relies on this kind of behavior.
>
> We're talking about pretty stable stuff.
>
Why would a compiler author want to make that promise? What's in it for
them, given that they can remain standard-compliant and retain greater
latitude in implementation by declining to define the constexpr variable?
--
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/d7f702e4-3a55-429d-870f-273dcd7c5b68%40isocpp.org.
------=_Part_3576_435910929.1470124124212
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, 2 August 2016 05:04:46 UTC+1, Nicol Bolas wro=
te:<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>By de=
fining the constexpr variable, the compiler knows that you're relying o=
n it and is promising to provide it. After all, compilers aren't exactl=
y free to change such behavior willy-nilly, considering how much code alrea=
dy relies on this kind of behavior.<br><br>We're talking about pretty s=
table stuff.<br></div></div></blockquote><div><br></div><div>Why would a co=
mpiler author want to make that promise? What's in it for them, given t=
hat they can remain standard-compliant and retain greater latitude in imple=
mentation by declining to define the constexpr variable?</div><div><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/d7f702e4-3a55-429d-870f-273dcd7c5b68%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d7f702e4-3a55-429d-870f-273dcd7c5b68=
%40isocpp.org</a>.<br />
------=_Part_3576_435910929.1470124124212--
------=_Part_3575_99426831.1470124124212--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 02 Aug 2016 07:50:55 -0700
Raw View
On ter=C3=A7a-feira, 2 de agosto de 2016 00:48:44 PDT Edward Catmur wrote:
> On Tuesday, 2 August 2016 05:04:46 UTC+1, Nicol Bolas wrote:
> > By defining the constexpr variable, the compiler knows that you're rely=
ing
> > on it and is promising to provide it. After all, compilers aren't exact=
ly
> > free to change such behavior willy-nilly, considering how much code
> > already
> > relies on this kind of behavior.
> >=20
> > We're talking about pretty stable stuff.
>=20
> Why would a compiler author want to make that promise? What's in it for
> them, given that they can remain standard-compliant and retain greater
> latitude in implementation by declining to define the constexpr variable?
Wait, were you (Nicol) suggesting constexpr variables that programmatically=
=20
describe the behaviour that the standard says is implementation-defined?
--=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/1717931.ZOid1VlC0W%40tjmaciei-mobl1.
.
Author: Myriachan <myriachan@gmail.com>
Date: Tue, 2 Aug 2016 12:31:54 -0700 (PDT)
Raw View
------=_Part_6974_2130269217.1470166314377
Content-Type: multipart/alternative;
boundary="----=_Part_6975_622602273.1470166314377"
------=_Part_6975_622602273.1470166314377
Content-Type: text/plain; charset=UTF-8
On Monday, August 1, 2016 at 5:53:11 PM UTC-7, Nicol Bolas wrote:
>
> On Monday, August 1, 2016 at 8:47:49 PM UTC-4, Nicol Bolas wrote:
>>
>>
>> That way, I can write code that will fail to compile if someone takes it
>> to an oddball system, rather than simply having subtle errors.
>>
>
> Think of it as an expansion of `std::numeric_limits::is_iec539`. We can
> detect if a particular platform supports IEEE-754-style floats. We're just
> asking for similar queries for various other operations.
>
We already have that: std::numeric_limits<T>::is_modulo. However,
is_modulo is currently not very well defined. I have a library defect
report on this somewhere.
Also, the major implementations (MSVC, GCC, Clang) make overflows
undefined, so either set is_modulo to false (GCC, Clang) or incorrectly set
is_modulo to true (MSVC). They should all be false.
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/76ff15c2-2654-4464-b0c1-8f79026349a9%40isocpp.org.
------=_Part_6975_622602273.1470166314377
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, August 1, 2016 at 5:53:11 PM UTC-7, Nicol Bolas=
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">On Mon=
day, August 1, 2016 at 8:47:49 PM UTC-4, Nicol Bolas wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><br>That way, I can write code tha=
t will fail to compile if someone takes it to an oddball system, rather tha=
n simply having subtle errors.<br></div></blockquote><div><br>Think of it a=
s an expansion of `std::numeric_limits::is_<wbr>iec539`. We can detect if a=
particular platform supports IEEE-754-style floats. We're just asking =
for similar queries for various other operations.<br></div></div></blockquo=
te><div><br>We already have that: std::numeric_limits<T>::is_modulo.=
=C2=A0 However, is_modulo is currently not very well defined.=C2=A0 I have =
a library defect report on this somewhere.<br><br>Also, the major implement=
ations (MSVC, GCC, Clang) make overflows undefined, so either set is_modulo=
to false (GCC, Clang) or incorrectly set is_modulo to true (MSVC).=C2=A0 T=
hey should all be false.<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/76ff15c2-2654-4464-b0c1-8f79026349a9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/76ff15c2-2654-4464-b0c1-8f79026349a9=
%40isocpp.org</a>.<br />
------=_Part_6975_622602273.1470166314377--
------=_Part_6974_2130269217.1470166314377--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 2 Aug 2016 18:21:25 -0700 (PDT)
Raw View
------=_Part_4635_1816286354.1470187285269
Content-Type: multipart/alternative;
boundary="----=_Part_4636_1223184766.1470187285270"
------=_Part_4636_1223184766.1470187285270
Content-Type: text/plain; charset=UTF-8
On Tuesday, August 2, 2016 at 1:00:55 AM UTC-4, Thiago Macieira wrote:
>
> On segunda-feira, 1 de agosto de 2016 21:04:45 PDT Nicol Bolas wrote:
> > > Also note that not only must you check with if constexpr, you must
> also
> > > tell
> > > the compiler that you're "abusing" that definition, such as by relying
> on
> > > the
> > > overflow of signed integers. To do that, today, you have to use things
> > > like
> > > __builtin_sadd_overflow and that doesn't require a constexpr if value.
> >
> > By defining the constexpr variable, the compiler knows that you're
> relying
> > on it and is promising to provide it. After all, compilers aren't
> exactly
> > free to change such behavior willy-nilly, considering how much code
> already
> > relies on this kind of behavior.
>
> That may not be enough. First, you may be asking for too much. You're
> asking
> for the compiler to detect that in:
>
> if constexpr (std::numeric_traits<int>::is_twos_complement)
> result = i + 1 > i;
>
> it should ignore the general C++ rule that signed overflow is UB and
> implement
> a defined behaviour that only applies to two's complement signed numbers.
You're misunderstanding the feature. The feature is that, if the compiler *already
implements* defined 2's complement behavior, then it sets that trait to
`true`.
The idea is that we take a survey of *existing* compilers/platforms and
find out what their actual behavior is, in a variety of areas. Then we take
the common subset of that and specify that, if that trait is true, then
that common subset of behavior is available.
If two's complement overflow behavior is not part of that common subset, so
be it. But just being able to detect that signed integers use two's
complement representations means that lots of things can become
well-defined. You can inter-convert between signed and unsigned integers
reasonably. The effects of performing bitwise operations is well defined.
And so forth.
Another possible common subset is the storage representation for multi-byte
values. Presently, while the value representation of an unsigned integer is
well defined, its byte representation is not. WE could define that an
implementation uses "endian storage", which means that, when interpreting
an integer as a `char*`, the first byte is either the high byte or the low
byte, the second being the next one, and so forth. We could even have a
constexpr variable saying which endian the platform uses. Combined with
knowing that a float is an IEEE-754 32-bit value, it suddenly becomes
well-defined behavior to manufacture a float value.
That's the kind of thing I'm talking about for the common subset: things
that are consistent between platforms, which are pretty much never going to
change for those platforms.
How
> would it know that that's what you meant? What other behaviours of signed
> two's complement must it know? Which ones are meant and which ones are
> not?
>
> How about tiny differences between how two's complement implement certain
> functionality? Do we need a trait for every single operation?
>
> Second, how far does that propagate? Would it propagate to inline
> functions
> called from inside that check? How about code dependent on result?
>
> > We're talking about pretty stable stuff.
> >
> > > I believe it would be more useful to define a number of primitive
> > > operations
> > > that are guaranteed to operate like two's complement. On the modern
> > > machines
> > > where that is the norm, they would be just like add, sub, and, or,
> xor,
> > > etc.
> > > That's not to the exclusion of the constexpr value, but I would say
> are of
> > > higher value.
> >
> > The problem with this solution is that, rather than standardizing
> existing
> > practice, you're creating a *new* standard that people would be expected
> to
> > use. We all know what happens when you introduce a new standard for
> > something that there's a current standard for: some will use it and some
> > will continue doing their own thing. Legacy code will remain untouched,
> and
> > thus live in implementation-defined land.
>
> I still think a library solution is better for this, even if the
> implementation (like type_trait's) requires compiler assistance to be
> efficiently written.
>
> We're not standardising standard practice because there isn't such a
> thing.
> Code that is currently UB is not standard practice. The fact that it may
> be
> working under GCC on x86 does not mean it currently works with Sun Studio
> on
> SPARC.
>
One could have said the same thing about the POD rules in C++98/03 vs. the
standard layout rules in C++11. That change existed primarily to
standardize existing practice among compilers. The spec developers saw that
compilers were *not* diverging in terms of layout for NSDMs simply due to
the presence of constructors and other member functions. The spec
developers saw that virtually every compiler would implement EBO in the
case where only one class had NSDMs.
So they decided to standardize this existing practice.
The only difference here is that it's not "virtually every compiler". But
it's also not something that compilers are required to support. If they
can't support a particular subset, they just set the constexpr variable to
`false`.
Either way we go, it requires changes to existing code to tell the compiler
> that the new behaviour is expected.
>
> > The goal of my solution is to make code that currently lives in
> > implementation-defined land well-defined. That you're not merely
> providing
> > *some way* to access this standard behavior, but that the current way
> > people do so *is that way*.
>
> If it lives on implementation-defined land, it's already defined and
> doesn't
> need changes. It's already working.
>
> We're either talking about making that code portable or to make UB code
> have
> defined behaviour. If you meant the latter, then what I said above
> applies:
> it's not standard now.
>
Many C++ practices are de-facto standards, even if they're not de-jure
standards. It's not unreasonable to promote some of them to de-jure status
if it can be done in a way that doesn't impact implementations that *cannot*
support them.
Wait, were you (Nicol) suggesting constexpr variables that programmatically
> describe the behaviour that the standard says is implementation-defined?
>
Essentially yes, though we shouldn't limit it to what is explicitly
implementation-defined. It's all about standardizing inter-compiler
behavior that only a few platforms don't implement.
--
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/e3dc8594-1efc-4147-bbb5-65f49aad1ad2%40isocpp.org.
------=_Part_4636_1223184766.1470187285270
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, August 2, 2016 at 1:00:55 AM UTC-4, Thiago Mac=
ieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On segunda-feira, =
1 de agosto de 2016 21:04:45 PDT Nicol Bolas wrote:
<br>> > Also note that not only must you check with if constexpr, you=
must also
<br>> > tell
<br>> > the compiler that you're "abusing" that definit=
ion, such as by relying on
<br>> > the
<br>> > overflow of signed integers. To do that, today, you have to u=
se things
<br>> > like
<br>> > __builtin_sadd_overflow and that doesn't require a conste=
xpr if value.
<br>>=20
<br>> By defining the constexpr variable, the compiler knows that you=
9;re relying
<br>> on it and is promising to provide it. After all, compilers aren=
9;t exactly
<br>> free to change such behavior willy-nilly, considering how much cod=
e already
<br>> relies on this kind of behavior.
<br>
<br>That may not be enough. First, you may be asking for too much. You'=
re asking=20
<br>for the compiler to detect that in:
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if constexpr (std::nume=
ric_traits<int>::is_<wbr>twos_complement)
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0result =3D i + 1 > i;
<br>
<br>it should ignore the general C++ rule that signed overflow is UB and im=
plement=20
<br>a defined behaviour that only applies to two's complement signed nu=
mbers.</blockquote><div><br>You're misunderstanding the feature. The fe=
ature is that, if the compiler <i>already implements</i> defined 2's co=
mplement behavior, then it sets that trait to `true`.<br><br>The idea is th=
at we take a survey of <i>existing</i> compilers/platforms and find out wha=
t their actual behavior is, in a variety of areas. Then we take the common =
subset of that and specify that, if that trait is true, then that common su=
bset of behavior is available.<br><br>If two's complement overflow beha=
vior is not part of that common subset, so be it. But just being able to de=
tect that signed integers use two's complement representations means th=
at lots of things can become well-defined. You can inter-convert between si=
gned and unsigned integers reasonably. The effects of performing bitwise op=
erations is well defined. And so forth.<br><br>Another possible common subs=
et is the storage representation for multi-byte values. Presently, while th=
e value representation of an unsigned integer is well defined, its byte rep=
resentation is not. WE could define that an implementation uses "endia=
n storage", which means that, when interpreting an integer as a `char*=
`, the first byte is either the high byte or the low byte, the second being=
the next one, and so forth. We could even have a constexpr variable saying=
which endian the platform uses. Combined with knowing that a float is an I=
EEE-754 32-bit value, it suddenly becomes well-defined behavior to manufact=
ure a float value.<br><br>That's the kind of thing I'm talking abou=
t for the common subset: things that are consistent between platforms, whic=
h are pretty much never going to change for those platforms.<br><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"> How=20
<br>would it know that that's what you meant? What other behaviours of =
signed=20
<br>two's complement must it know? Which ones are meant and which ones =
are not?
<br>
<br>How about tiny differences between how two's complement implement c=
ertain=20
<br>functionality? Do we need a trait for every single operation?
<br>
<br>Second, how far does that propagate? Would it propagate to inline funct=
ions=20
<br>called from inside that check? How about code dependent on result?
<br>
<br>> We're talking about pretty stable stuff.
<br>>=20
<br>> > I believe it would be more useful to define a number of primi=
tive
<br>> > operations
<br>> > that are guaranteed to operate like two's complement. On =
the modern
<br>> > machines
<br>> > where that is the norm, they would be just like add, sub, and=
, or, xor,
<br>> > etc.
<br>> > That's not to the exclusion of the constexpr value, but I=
would say are of
<br>> > higher value.
<br>>=20
<br>> The problem with this solution is that, rather than standardizing =
existing
<br>> practice, you're creating a *new* standard that people would b=
e expected to
<br>> use. We all know what happens when you introduce a new standard fo=
r
<br>> something that there's a current standard for: some will use i=
t and some
<br>> will continue doing their own thing. Legacy code will remain untou=
ched, and
<br>> thus live in implementation-defined land.
<br>
<br>I still think a library solution is better for this, even if the=20
<br>implementation (like type_trait's) requires compiler assistance to =
be=20
<br>efficiently written.
<br>
<br>We're not standardising standard practice because there isn't s=
uch a thing.=20
<br>Code that is currently UB is not standard practice. The fact that it ma=
y be=20
<br>working under GCC on x86 does not mean it currently works with Sun Stud=
io on=20
<br>SPARC.<br></blockquote><div><br>One could have said the same thing abou=
t the POD rules in C++98/03 vs. the standard layout rules in C++11. That ch=
ange existed primarily to standardize existing practice among compilers. Th=
e spec developers saw that compilers were *not* diverging in terms of layou=
t for NSDMs simply due to the presence of constructors and other member fun=
ctions. The spec developers saw that virtually every compiler would impleme=
nt EBO in the case where only one class had NSDMs.<br><br>So they decided t=
o standardize this existing practice.<br><br>The only difference here is th=
at it's not "virtually every compiler". But it's also not=
something that compilers are required to support. If they can't suppor=
t a particular subset, they just set the constexpr variable to `false`.<br>=
<br></div><div></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
Either way we go, it requires changes to existing code to tell the compiler=
=20
<br>that the new behaviour is expected.
<br>
<br>> The goal of my solution is to make code that currently lives in
<br>> implementation-defined land well-defined. That you're not mere=
ly providing
<br>> *some way* to access this standard behavior, but that the current =
way
<br>> people do so *is that way*.
<br>
<br>If it lives on implementation-defined land, it's already defined an=
d doesn't=20
<br>need changes. It's already working.
<br>
<br>We're either talking about making that code portable or to make UB =
code have=20
<br>defined behaviour. If you meant the latter, then what I said above appl=
ies:=20
<br>it's not standard now.<br></blockquote><div><br>Many C++ practices =
are de-facto standards, even if they're not de-jure standards. It's=
not unreasonable to promote some of them to de-jure status if it can be do=
ne in a way that doesn't impact implementations that <i>cannot</i> supp=
ort them.<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-lef=
t: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">=
Wait, were you (Nicol) suggesting constexpr variables that programmatically=
=20
<br>describe the behaviour that the standard says =C2=A0is implementation-d=
efined?
<br></blockquote><div><br>Essentially yes, though we shouldn't limit it=
to what is explicitly implementation-defined. It's all about standardi=
zing inter-compiler behavior that only a few platforms don't implement.=
<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/e3dc8594-1efc-4147-bbb5-65f49aad1ad2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e3dc8594-1efc-4147-bbb5-65f49aad1ad2=
%40isocpp.org</a>.<br />
------=_Part_4636_1223184766.1470187285270--
------=_Part_4635_1816286354.1470187285269--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 02 Aug 2016 20:05:50 -0700
Raw View
On ter=C3=A7a-feira, 2 de agosto de 2016 18:21:25 PDT Nicol Bolas wrote:
> You're misunderstanding the feature. The feature is that, if the compiler
> *already implements* defined 2's complement behavior, then it sets that
> trait to `true`.
You mean that it implements the behaviour even where the standard says the=
=20
behaviour is undefined?
If so, why do you think compiler writers will do this? What's their incenti=
ve?
> The idea is that we take a survey of *existing* compilers/platforms and
> find out what their actual behavior is, in a variety of areas. Then we ta=
ke
> the common subset of that and specify that, if that trait is true, then
> that common subset of behavior is available.
I expect this is what we're going to find:
* UBs are often treated as an impossible condition and optimised out when=
=20
detected. In cases where the compiler doesn't detect it, the behaviour is=
=20
probably unpredictable or, at best, machine-dependent (the case of shifting=
by=20
more the width of the type).
* if you ask the compiler authors about UBs that they don't currently catch=
,=20
they'll answer that they would like to catch and optimise. That has been th=
e=20
current trend for the last 10 years of compiler improvements (since strict=
=20
aliasing and strict overflows in GCC).
* IBs are most often common across compilers in a given processor architect=
ure
> If two's complement overflow behavior is not part of that common subset, =
so
> be it. But just being able to detect that signed integers use two's
> complement representations means that lots of things can become
> well-defined. You can inter-convert between signed and unsigned integers
> reasonably. The effects of performing bitwise operations is well defined.
> And so forth.
True, but this is not a property of two's complement representation, but th=
at=20
the compiler implements the conversion by not changing the bit pattern. A=
=20
compiler could implement it differently and disallow certain negative value=
s.=20
It's just extremely unlikely since that's inefficient (hence my point above=
=20
about the IBs).
Like Melissa said, we have "is_modulo" but that is neither useful nor prope=
rly=20
implemented today. We should have a proper variable indicating which of the=
=20
three storage types permitted by the C standard signed integers use, plus o=
ne=20
for each of the implementation-defined behaviours (e.g., whether conversion=
=20
from signed to unsigned and vice-versa preserves the bit pattern).
> Another possible common subset is the storage representation for multi-by=
te
> values. Presently, while the value representation of an unsigned integer =
is
> well defined, its byte representation is not. WE could define that an
> implementation uses "endian storage", which means that, when interpreting
> an integer as a `char*`, the first byte is either the high byte or the lo=
w
> byte, the second being the next one, and so forth. We could even have a
> constexpr variable saying which endian the platform uses. Combined with
> knowing that a float is an IEEE-754 32-bit value, it suddenly becomes
> well-defined behavior to manufacture a float value.
You mean having a way to detect big endian or little endian? That's quite=
=20
important and almost all compilers implement macros for that, even though=
=20
they're not standardised in C or C++. I support this.
I'm actually surprised that __BYTE_ORDER__ is in neither standard.
> > We're not standardising standard practice because there isn't such a
> > thing.
> > Code that is currently UB is not standard practice. The fact that it ma=
y
> > be
> > working under GCC on x86 does not mean it currently works with Sun Stud=
io
> > on
> > SPARC.
>=20
> One could have said the same thing about the POD rules in C++98/03 vs. th=
e
> standard layout rules in C++11. That change existed primarily to
> standardize existing practice among compilers. The spec developers saw th=
at
> compilers were *not* diverging in terms of layout for NSDMs simply due to
> the presence of constructors and other member functions. The spec
> developers saw that virtually every compiler would implement EBO in the
> case where only one class had NSDMs.
Standardising existing practice is fine. I agree that certain IB is likely=
=20
standard practice because almost all modern processors use two's complement=
=20
integers and virtually all compilers implement conversions by not changing =
the=20
bit pattern.
That does not hold for UBs. So even if you do know that signed integers are=
=20
two's complement, you're still not allowed to rely on signed integer overfl=
ow.
> > Wait, were you (Nicol) suggesting constexpr variables that=20
> > programmatically describe the behaviour that the standard says is
> > implementation-defined?
>=20
> Essentially yes, though we shouldn't limit it to what is explicitly
> implementation-defined. It's all about standardizing inter-compiler
> behavior that only a few platforms don't implement.
I support you on IB. I don't think you'll get much traction on UB with eith=
er=20
the committee or the compiler writers.
--=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/2230983.9DZ8gg9NtW%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 3 Aug 2016 08:27:16 -0700 (PDT)
Raw View
------=_Part_616_425560428.1470238037086
Content-Type: multipart/alternative;
boundary="----=_Part_617_559036335.1470238037086"
------=_Part_617_559036335.1470238037086
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, August 2, 2016 at 11:05:54 PM UTC-4, Thiago Macieira wrote:
>
> On ter=C3=A7a-feira, 2 de agosto de 2016 18:21:25 PDT Nicol Bolas wrote:=
=20
> > You're misunderstanding the feature. The feature is that, if the=20
> compiler=20
> > *already implements* defined 2's complement behavior, then it sets that=
=20
> > trait to `true`.=20
>
> You mean that it implements the behaviour even where the standard says th=
e=20
> behaviour is undefined?=20
>
> If so, why do you think compiler writers will do this? What's their=20
> incentive?
>
Overflow behavior is defined by the underlying hardware. Well... is there=
=20
convergence in hardware towards one particular solution? That is, do most=
=20
two's complement hardware wrap or flush? How do most two's complement chips=
=20
handle bitshifting by more than the size of the register?
If there is consensus on these questions, we should have a variable letting=
=20
us know that the platform supports the consensus behavior. If there is no=
=20
consensus, so be it.
> If two's complement overflow behavior is not part of that common subset,=
=20
> so=20
> > be it. But just being able to detect that signed integers use two's=20
> > complement representations means that lots of things can become=20
> > well-defined. You can inter-convert between signed and unsigned integer=
s=20
> > reasonably. The effects of performing bitwise operations is well=20
> defined.=20
> > And so forth.=20
>
> True, but this is not a property of two's complement representation, but=
=20
> that=20
> the compiler implements the conversion by not changing the bit pattern. A=
=20
> compiler could implement it differently and disallow certain negative=20
> values.=20
> It's just extremely unlikely since that's inefficient (hence my point=20
> above=20
> about the IBs).=20
>
> Like Melissa said, we have "is_modulo" but that is neither useful nor=20
> properly=20
> implemented today. We should have a proper variable indicating which of=
=20
> the=20
> three storage types permitted by the C standard signed integers use, plus=
=20
> one=20
> for each of the implementation-defined behaviours (e.g., whether=20
> conversion=20
> from signed to unsigned and vice-versa preserves the bit pattern).
>
I don't like the idea of having a bunch of tests for the particular integer=
=20
formats. I don't want to see a sequence of `if constexpr` statements when=
=20
doing certain integer math. Most of the world's processors picked two's=20
complement. So most code that relies on such a format relies on two's=20
complement.
=20
> > Another possible common subset is the storage representation for=20
> multi-byte=20
> > values. Presently, while the value representation of an unsigned intege=
r=20
> is=20
> > well defined, its byte representation is not. WE could define that an=
=20
> > implementation uses "endian storage", which means that, when=20
> interpreting=20
> > an integer as a `char*`, the first byte is either the high byte or the=
=20
> low=20
> > byte, the second being the next one, and so forth. We could even have a=
=20
> > constexpr variable saying which endian the platform uses. Combined with=
=20
> > knowing that a float is an IEEE-754 32-bit value, it suddenly becomes=
=20
> > well-defined behavior to manufacture a float value.=20
>
> You mean having a way to detect big endian or little endian? That's quite=
=20
> important and almost all compilers implement macros for that, even though=
=20
> they're not standardised in C or C++. I support this.
>
That would have to be a three-value boolean. Because the standard doesn't=
=20
require big endian or little endian storage; a platform could be middle=20
endian or some other nonsense.
I'm actually surprised that __BYTE_ORDER__ is in neither standard.=20
>
> > > We're not standardising standard practice because there isn't such a=
=20
> > > thing.=20
> > > Code that is currently UB is not standard practice. The fact that it=
=20
> may=20
> > > be=20
> > > working under GCC on x86 does not mean it currently works with Sun=20
> Studio=20
> > > on=20
> > > SPARC.=20
> >=20
> > One could have said the same thing about the POD rules in C++98/03 vs.=
=20
> the=20
> > standard layout rules in C++11. That change existed primarily to=20
> > standardize existing practice among compilers. The spec developers saw=
=20
> that=20
> > compilers were *not* diverging in terms of layout for NSDMs simply due=
=20
> to=20
> > the presence of constructors and other member functions. The spec=20
> > developers saw that virtually every compiler would implement EBO in the=
=20
> > case where only one class had NSDMs.=20
>
> Standardising existing practice is fine. I agree that certain IB is likel=
y=20
> standard practice because almost all modern processors use two's=20
> complement=20
> integers and virtually all compilers implement conversions by not changin=
g=20
> the=20
> bit pattern.=20
>
> That does not hold for UBs. So even if you do know that signed integers=
=20
> are=20
> two's complement, you're still not allowed to rely on signed integer=20
> overflow.
>
Programmers aren't stopped by what a piece of paper says they are "allowed=
=20
to" do.
Also, we're not talking about UB like what happens if you access an integer=
=20
as a float or something. We're talking about UB like how the underlying=20
hardware handles signed integer overflows.
--=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/20d7a0eb-ab88-4088-ba0e-da487c6352a7%40isocpp.or=
g.
------=_Part_617_559036335.1470238037086
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, August 2, 2016 at 11:05:54 PM UTC-4, Thiago Ma=
cieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On ter=C3=A7a-fei=
ra, 2 de agosto de 2016 18:21:25 PDT Nicol Bolas wrote:
<br>> You're misunderstanding the feature. The feature is that, if t=
he compiler
<br>> *already implements* defined 2's complement behavior, then it =
sets that
<br>> trait to `true`.
<br>
<br>You mean that it implements the behaviour even where the standard says =
the=20
<br>behaviour is undefined?
<br>
<br>If so, why do you think compiler writers will do this? What's their=
incentive?<br></blockquote><div><br>Overflow behavior is defined by the un=
derlying hardware. Well... is there convergence in hardware towards one par=
ticular solution? That is, do most two's complement hardware wrap or fl=
ush? How do most two's complement chips handle bitshifting by more than=
the size of the register?<br><br>If there is consensus on these questions,=
we should have a variable letting us know that the platform supports the c=
onsensus behavior. If there is no consensus, so be it.<br><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">
> If two's complement overflow behavior is not part of that common s=
ubset, so
<br>> be it. But just being able to detect that signed integers use two&=
#39;s
<br>> complement representations means that lots of things can become
<br>> well-defined. You can inter-convert between signed and unsigned in=
tegers
<br>> reasonably. The effects of performing bitwise operations is well d=
efined.
<br>> And so forth.
<br>
<br>True, but this is not a property of two's complement representation=
, but that=20
<br>the compiler implements the conversion by not changing the bit pattern.=
A=20
<br>compiler could implement it differently and disallow certain negative v=
alues.=20
<br>It's just extremely unlikely since that's inefficient (hence my=
point above=20
<br>about the IBs).
<br>
<br>Like Melissa said, we have "is_modulo" but that is neither us=
eful nor properly=20
<br>implemented today. We should have a proper variable indicating which of=
the=20
<br>three storage types permitted by the C standard signed integers use, pl=
us one=20
<br>for each of the implementation-defined behaviours (e.g., whether conver=
sion=20
<br>from signed to unsigned and vice-versa preserves the bit pattern).<br><=
/blockquote><div><br>I don't like the idea of having a bunch of tests f=
or the particular integer formats. I don't want to see a sequence of `i=
f constexpr` statements when doing certain integer math. Most of the world&=
#39;s processors picked two's complement. So most code that relies on s=
uch a format relies on two's complement.<br>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">
> Another possible common subset is the storage representation for multi=
-byte
<br>> values. Presently, while the value representation of an unsigned i=
nteger is
<br>> well defined, its byte representation is not. WE could define that=
an
<br>> implementation uses "endian storage", which means that, =
when interpreting
<br>> an integer as a `char*`, the first byte is either the high byte or=
the low
<br>> byte, the second being the next one, and so forth. We could even h=
ave a
<br>> constexpr variable saying which endian the platform uses. Combined=
with
<br>> knowing that a float is an IEEE-754 32-bit value, it suddenly beco=
mes
<br>> well-defined behavior to manufacture a float value.
<br>
<br>You mean having a way to detect big endian or little endian? That's=
quite=20
<br>important and almost all compilers implement macros for that, even thou=
gh=20
<br>they're not standardised in C or C++. I support this.<br></blockquo=
te><div><br>That would have to be a three-value boolean. Because the standa=
rd doesn't require big endian or little endian storage; a platform coul=
d be middle endian or some other nonsense.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
I'm actually surprised that __BYTE_ORDER__ is in neither standard.
<br>
<br>> > We're not standardising standard practice because there i=
sn't such a
<br>> > thing.
<br>> > Code that is currently UB is not standard practice. The fact =
that it may
<br>> > be
<br>> > working under GCC on x86 does not mean it currently works wit=
h Sun Studio
<br>> > on
<br>> > SPARC.
<br>>=20
<br>> One could have said the same thing about the POD rules in C++98/03=
vs. the
<br>> standard layout rules in C++11. That change existed primarily to
<br>> standardize existing practice among compilers. The spec developers=
saw that
<br>> compilers were *not* diverging in terms of layout for NSDMs simply=
due to
<br>> the presence of constructors and other member functions. The spec
<br>> developers saw that virtually every compiler would implement EBO i=
n the
<br>> case where only one class had NSDMs.
<br>
<br>Standardising existing practice is fine. I agree that certain IB is lik=
ely=20
<br>standard practice because almost all modern processors use two's co=
mplement=20
<br>integers and virtually all compilers implement conversions by not chang=
ing the=20
<br>bit pattern.
<br>
<br>That does not hold for UBs. So even if you do know that signed integers=
are=20
<br>two's complement, you're still not allowed to rely on signed in=
teger overflow.<br></blockquote><div><br>Programmers aren't stopped by =
what a piece of paper says they are "allowed to" do.<br><br>Also,=
we're not talking about UB like what happens if you access an integer =
as a float or something. We're talking about UB like how the underlying=
hardware handles signed integer overflows.</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/20d7a0eb-ab88-4088-ba0e-da487c6352a7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/20d7a0eb-ab88-4088-ba0e-da487c6352a7=
%40isocpp.org</a>.<br />
------=_Part_617_559036335.1470238037086--
------=_Part_616_425560428.1470238037086--
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 3 Aug 2016 20:28:53 +0100
Raw View
--94eb2c0544b8069c3305392fd8b6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Aug 3, 2016 at 4:27 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, August 2, 2016 at 11:05:54 PM UTC-4, Thiago Macieira wrote:
>>
>> On ter=C3=A7a-feira, 2 de agosto de 2016 18:21:25 PDT Nicol Bolas wrote:
>> > You're misunderstanding the feature. The feature is that, if the
>> compiler
>> > *already implements* defined 2's complement behavior, then it sets tha=
t
>> > trait to `true`.
>>
>> You mean that it implements the behaviour even where the standard says
>> the
>> behaviour is undefined?
>>
>> If so, why do you think compiler writers will do this? What's their
>> incentive?
>>
>
> Overflow behavior is defined by the underlying hardware. Well... is there
> convergence in hardware towards one particular solution? That is, do most
> two's complement hardware wrap or flush? How do most two's complement chi=
ps
> handle bitshifting by more than the size of the register?
>
> If there is consensus on these questions, we should have a variable
> letting us know that the platform supports the consensus behavior. If the=
re
> is no consensus, so be it.
>
That doesn't answer the question. Suppose there is indeed a consensus
behavior that can easily be implemented on the majority of platforms. Why
would any compiler vendor admit to supporting that behavior? If they claim
not to support it, they can use whatever instruction sequence they like
that falls within the standard (e.g. lea, fma as opposed to mul/add, or
vector instructions) where that is more efficient than the
consensus-behaving instruction sequence; meanwhile, the optimizer can
back-propagate constraints and the sanitizer can insert traps. If they
admit to supporting it, they have to use a restricted instruction set and
make additional assumptions about the program behavior that the user may
not have intended.
Standardising existing practice is fine. I agree that certain IB is likely
>>
> standard practice because almost all modern processors use two's
>> complement
>> integers and virtually all compilers implement conversions by not
>> changing the
>> bit pattern.
>>
>> That does not hold for UBs. So even if you do know that signed integers
>> are
>> two's complement, you're still not allowed to rely on signed integer
>> overflow.
>>
>
> Programmers aren't stopped by what a piece of paper says they are "allowe=
d
> to" do.
>
That's why we have ubsan and -Werror.
> Also, we're not talking about UB like what happens if you access an
> integer as a float or something. We're talking about UB like how the
> underlying hardware handles signed integer overflows.
>
> The undefined behavior of signed overflow makes no reference to the
behavior of underlying hardware, if there even is a single such behavior.
The historical reason for making signed overflow UB may have been hardware
divergence, but even if hardware has since converged there are good reasons
for retaining it.
--=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/CAJnLdOYSjcm3Xmo_7T15Q4-iWuzeKmR841qTdiLQCdB9QqP=
ZSQ%40mail.gmail.com.
--94eb2c0544b8069c3305392fd8b6
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 W=
ed, Aug 3, 2016 at 4:27 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></sp=
an> 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">On Tuesday, A=
ugust 2, 2016 at 11:05:54 PM UTC-4, Thiago Macieira wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">On ter=C3=A7a-feira, 2 de agosto de 2016 18:21:25 PD=
T Nicol Bolas wrote:
<br>> You're misunderstanding the feature. The feature is that, if t=
he compiler
<br>> *already implements* defined 2's complement behavior, then it =
sets that
<br>> trait to `true`.
<br>
<br>You mean that it implements the behaviour even where the standard says =
the=20
<br>behaviour is undefined?
<br>
<br>If so, why do you think compiler writers will do this? What's their=
incentive?<br></blockquote><div><br>Overflow behavior is defined by the un=
derlying hardware. Well... is there convergence in hardware towards one par=
ticular solution? That is, do most two's complement hardware wrap or fl=
ush? How do most two's complement chips handle bitshifting by more than=
the size of the register?<br><br>If there is consensus on these questions,=
we should have a variable letting us know that the platform supports the c=
onsensus behavior. If there is no consensus, so be it.<br></div></div></blo=
ckquote><div><br></div><div>That doesn't answer the question. Suppose t=
here is indeed a consensus behavior that can easily be implemented on the m=
ajority of platforms. Why would any compiler vendor admit to supporting tha=
t behavior? If they claim not to support it, they can use whatever instruct=
ion sequence they like that falls within the standard (e.g. lea, fma as opp=
osed to mul/add, or vector instructions) where that is more efficient than =
the consensus-behaving instruction sequence; meanwhile, the optimizer can b=
ack-propagate constraints and the sanitizer can insert traps. If they admit=
to supporting it, they have to use a restricted instruction set and make a=
dditional assumptions about the program behavior that the user may not have=
intended.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Standardising existi=
ng practice is fine. I agree that certain IB is likely=C2=A0<br></blockquot=
e><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">standard practice because almost =
all modern processors use two's complement=20
<br>integers and virtually all compilers implement conversions by not chang=
ing the=20
<br>bit pattern.
<br>
<br>That does not hold for UBs. So even if you do know that signed integers=
are=20
<br>two's complement, you're still not allowed to rely on signed in=
teger overflow.<br></blockquote><div><br>Programmers aren't stopped by =
what a piece of paper says they are "allowed to" do.<br></div></d=
iv></blockquote><div><br></div><div>That's why we have ubsan and -Werro=
r.</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"><d=
iv>Also, we're not talking about UB like what happens if you access an =
integer as a float or something. We're talking about UB like how the un=
derlying hardware handles signed integer overflows.</div></div><span class=
=3D"HOEnZb"><font color=3D"#888888">
<p></p></font></span></blockquote></div>The undefined behavior of signed ov=
erflow makes no reference to the behavior of underlying hardware, if there =
even is a single such behavior. The historical reason for making signed ove=
rflow UB may have been hardware divergence, but even if hardware has since =
converged there are good reasons for retaining it.</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/CAJnLdOYSjcm3Xmo_7T15Q4-iWuzeKmR841qT=
diLQCdB9QqPZSQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOYSjcm3Xmo_=
7T15Q4-iWuzeKmR841qTdiLQCdB9QqPZSQ%40mail.gmail.com</a>.<br />
--94eb2c0544b8069c3305392fd8b6--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 3 Aug 2016 12:52:19 -0700 (PDT)
Raw View
------=_Part_28_456849280.1470253939488
Content-Type: multipart/alternative;
boundary="----=_Part_29_248076447.1470253939488"
------=_Part_29_248076447.1470253939488
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, August 3, 2016 at 3:28:55 PM UTC-4, Edward Catmur wrote:
>
> On Wed, Aug 3, 2016 at 4:27 PM, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> wrote:
>
>> On Tuesday, August 2, 2016 at 11:05:54 PM UTC-4, Thiago Macieira wrote:
>>>
>>> On ter=C3=A7a-feira, 2 de agosto de 2016 18:21:25 PDT Nicol Bolas wrote=
:=20
>>> > You're misunderstanding the feature. The feature is that, if the=20
>>> compiler=20
>>> > *already implements* defined 2's complement behavior, then it sets=20
>>> that=20
>>> > trait to `true`.=20
>>>
>>> You mean that it implements the behaviour even where the standard says=
=20
>>> the=20
>>> behaviour is undefined?=20
>>>
>>> If so, why do you think compiler writers will do this? What's their=20
>>> incentive?
>>>
>>
>> Overflow behavior is defined by the underlying hardware. Well... is ther=
e=20
>> convergence in hardware towards one particular solution? That is, do mos=
t=20
>> two's complement hardware wrap or flush? How do most two's complement ch=
ips=20
>> handle bitshifting by more than the size of the register?
>>
>> If there is consensus on these questions, we should have a variable=20
>> letting us know that the platform supports the consensus behavior. If th=
ere=20
>> is no consensus, so be it.
>>
>
> That doesn't answer the question. Suppose there is indeed a consensus=20
> behavior that can easily be implemented on the majority of platforms.
>
I didn't say "can easily be implemented". I meant what they *actually do*,=
=20
not what they could be made to do. If there's no consensus on that=20
(especially if it changes from expression to expression), so be it.
The goal is not to change compiler *behavior*. The goal is not to force=20
compilers in a smaller box. The goal is to make the box the standard=20
defines more in line with the box that a large set of platforms actually=20
provide, so that users who rely on that reality can do so in a=20
standard-conforming way.
If integer overflow isn't able to be in that box, then it isn't that that=
=20
box. But we should omit it not because the standard makes it UB; it should=
=20
be omitted because it's not part of that box of actual current consensus=20
behavior.
--=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/a07070d8-e31a-47a8-9640-62611f828cb4%40isocpp.or=
g.
------=_Part_29_248076447.1470253939488
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, August 3, 2016 at 3:28:55 PM UTC-4, Edward C=
atmur wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><div class=3D"gmail_quote">On Wed, Aug 3, 2016 at 4:27 PM, Nicol Bolas =
<span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"F57A9ElaBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
9;javascript:';return true;" onclick=3D"this.href=3D'javascript:=
9;;return true;">jmck...@gmail.com</a>></span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">On Tuesday, August 2, 2016 at 11:05:54 PM =
UTC-4, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On ter=
=C3=A7a-feira, 2 de agosto de 2016 18:21:25 PDT Nicol Bolas wrote:
<br>> You're misunderstanding the feature. The feature is that, if t=
he compiler
<br>> *already implements* defined 2's complement behavior, then it =
sets that
<br>> trait to `true`.
<br>
<br>You mean that it implements the behaviour even where the standard says =
the=20
<br>behaviour is undefined?
<br>
<br>If so, why do you think compiler writers will do this? What's their=
incentive?<br></blockquote><div><br>Overflow behavior is defined by the un=
derlying hardware. Well... is there convergence in hardware towards one par=
ticular solution? That is, do most two's complement hardware wrap or fl=
ush? How do most two's complement chips handle bitshifting by more than=
the size of the register?<br><br>If there is consensus on these questions,=
we should have a variable letting us know that the platform supports the c=
onsensus behavior. If there is no consensus, so be it.<br></div></div></blo=
ckquote><div><br></div><div>That doesn't answer the question. Suppose t=
here is indeed a consensus behavior that can easily be implemented on the m=
ajority of platforms.</div></div></div></div></blockquote><div><br>I didn&#=
39;t say "can easily be implemented". I meant what they <i>actual=
ly do</i>, not what they could be made to do. If there's no consensus o=
n that (especially if it changes from expression to expression), so be it.<=
br><br>The goal is not to change compiler <i>behavior</i>. The goal is not =
to force compilers in a smaller box. The goal is to make the box the standa=
rd defines more in line with the box that a large set of platforms actually=
provide, so that users who rely on that reality can do so in a standard-co=
nforming way.<br><br>If integer overflow isn't able to be in that box, =
then it isn't that that box. But we should omit it not because the stan=
dard makes it UB; it should be omitted because it's not part of that bo=
x of actual current consensus behavior.<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/a07070d8-e31a-47a8-9640-62611f828cb4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a07070d8-e31a-47a8-9640-62611f828cb4=
%40isocpp.org</a>.<br />
------=_Part_29_248076447.1470253939488--
------=_Part_28_456849280.1470253939488--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Wed, 3 Aug 2016 22:29:34 +0200
Raw View
I do not remember if this have been up before but would a "wrapping" modifi=
er
that could be applied to a signed integer type be useful?
This would allow code that depends on wrapping behaviour to request it
explicitly and let the rest of the world keep using the old behaviour.
/MF
On Wed, Aug 03, 2016 at 12:52:19PM -0700, Nicol Bolas wrote:
> On Wednesday, August 3, 2016 at 3:28:55 PM UTC-4, Edward Catmur wrote:
> >
> > On Wed, Aug 3, 2016 at 4:27 PM, Nicol Bolas <jmck...@gmail.com=20
> > <javascript:>> wrote:
> >
> >> On Tuesday, August 2, 2016 at 11:05:54 PM UTC-4, Thiago Macieira wrote=
:
> >>>
> >>> On ter=C3=A7a-feira, 2 de agosto de 2016 18:21:25 PDT Nicol Bolas wro=
te:=20
> >>> > You're misunderstanding the feature. The feature is that, if the=20
> >>> compiler=20
> >>> > *already implements* defined 2's complement behavior, then it sets=
=20
> >>> that=20
> >>> > trait to `true`.=20
> >>>
> >>> You mean that it implements the behaviour even where the standard say=
s=20
> >>> the=20
> >>> behaviour is undefined?=20
> >>>
> >>> If so, why do you think compiler writers will do this? What's their=
=20
> >>> incentive?
> >>>
> >>
> >> Overflow behavior is defined by the underlying hardware. Well... is th=
ere=20
> >> convergence in hardware towards one particular solution? That is, do m=
ost=20
> >> two's complement hardware wrap or flush? How do most two's complement =
chips=20
> >> handle bitshifting by more than the size of the register?
> >>
> >> If there is consensus on these questions, we should have a variable=20
> >> letting us know that the platform supports the consensus behavior. If =
there=20
> >> is no consensus, so be it.
> >>
> >
> > That doesn't answer the question. Suppose there is indeed a consensus=
=20
> > behavior that can easily be implemented on the majority of platforms.
> >
>=20
> I didn't say "can easily be implemented". I meant what they *actually do*=
,=20
> not what they could be made to do. If there's no consensus on that=20
> (especially if it changes from expression to expression), so be it.
>=20
> The goal is not to change compiler *behavior*. The goal is not to force=
=20
> compilers in a smaller box. The goal is to make the box the standard=20
> defines more in line with the box that a large set of platforms actually=
=20
> provide, so that users who rely on that reality can do so in a=20
> standard-conforming way.
>=20
> If integer overflow isn't able to be in that box, then it isn't that that=
=20
> box. But we should omit it not because the standard makes it UB; it shoul=
d=20
> be omitted because it's not part of that box of actual current consensus=
=20
> behavior.
>=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.
> 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/isoc=
pp.org/d/msgid/std-proposals/a07070d8-e31a-47a8-9640-62611f828cb4%40isocpp.=
org.
--=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/20160803202934.GA2572%40noemi.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 03 Aug 2016 13:48:36 -0700
Raw View
On quarta-feira, 3 de agosto de 2016 12:52:19 PDT Nicol Bolas wrote:
> I didn't say "can easily be implemented". I meant what they *actually do*,
> not what they could be made to do. If there's no consensus on that
> (especially if it changes from expression to expression), so be it.
And therein lies the problem: I don't believe what compilers do in UB to be
common practice. The fact that the underlying hardware has a single
instruction for ADD, whether signed or unsigned, is irrelevant if the compiler
catches it.
This is an example with GCC. Since it implemented strict overflow checks, it
doesn't matter that x86 handles it with a "graceful" overflow and even has a
flag bit to indicate the fact. The application simply can't rely on it because
the compiler will delete the check if it sees it.
I do think that IB is common practice though, in a given architecture.
> The goal is not to change compiler *behavior*. The goal is not to force
> compilers in a smaller box. The goal is to make the box the standard
> defines more in line with the box that a large set of platforms actually
> provide, so that users who rely on that reality can do so in a
> standard-conforming way.
I don't think there's will to do that.
> If integer overflow isn't able to be in that box, then it isn't that that
> box. But we should omit it not because the standard makes it UB; it should
> be omitted because it's not part of that box of actual current consensus
> behavior.
Fair enough. I think you can exclude all UB from the box then.
Start with the IBs and figure out what traits you need to define so that
applications can start to rely on it.
--
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/50822350.EuVPnWmst9%40tjmaciei-mobl1.
.
Author: Mikhail Maltsev <maltsevm@gmail.com>
Date: Thu, 4 Aug 2016 00:30:52 +0300
Raw View
On 03.08.2016 6:05, Thiago Macieira wrote:
> On ter=C3=A7a-feira, 2 de agosto de 2016 18:21:25 PDT Nicol Bolas wrote:
>> You're misunderstanding the feature. The feature is that, if the compile=
r
>> *already implements* defined 2's complement behavior, then it sets that
>> trait to `true`.
>
> You mean that it implements the behaviour even where the standard says th=
e
> behaviour is undefined?
>
> If so, why do you think compiler writers will do this? What's their incen=
tive?
>
Why not? Some compilers (GCC, Clang) already implement well-defined signed=
=20
overflow as an extension (with -fwrapv command-line flag). There are some=
=20
codebases (e.g. CPython) which use this option.
--=20
Mikhail Maltsev
--=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/4369d4eb-08cd-c9f5-4dd0-1847a0331f81%40gmail.com=
..
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 4 Aug 2016 00:40:20 +0100
Raw View
--001a113d00a649d2f00539335bd1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 3 Aug 2016 8:52 p.m., "Nicol Bolas" <jmckesson@gmail.com> wrote:
>
> On Wednesday, August 3, 2016 at 3:28:55 PM UTC-4, Edward Catmur wrote:
>>
>> On Wed, Aug 3, 2016 at 4:27 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>> On Tuesday, August 2, 2016 at 11:05:54 PM UTC-4, Thiago Macieira wrote:
>>>>
>>>> On ter=C3=A7a-feira, 2 de agosto de 2016 18:21:25 PDT Nicol Bolas wrot=
e:
>>>> > You're misunderstanding the feature. The feature is that, if the
compiler
>>>> > *already implements* defined 2's complement behavior, then it sets
that
>>>> > trait to `true`.
>>>>
>>>> You mean that it implements the behaviour even where the standard says
the
>>>> behaviour is undefined?
>>>>
>>>> If so, why do you think compiler writers will do this? What's their
incentive?
>>>
>>>
>>> Overflow behavior is defined by the underlying hardware. Well... is
there convergence in hardware towards one particular solution? That is, do
most two's complement hardware wrap or flush? How do most two's complement
chips handle bitshifting by more than the size of the register?
>>>
>>> If there is consensus on these questions, we should have a variable
letting us know that the platform supports the consensus behavior. If there
is no consensus, so be it.
>>
>>
>> That doesn't answer the question. Suppose there is indeed a consensus
behavior that can easily be implemented on the majority of platforms.
>
>
> I didn't say "can easily be implemented". I meant what they actually do,
not what they could be made to do. If there's no consensus on that
(especially if it changes from expression to expression), so be it.
>
> The goal is not to change compiler behavior. The goal is not to force
compilers in a smaller box. The goal is to make the box the standard
defines more in line with the box that a large set of platforms actually
provide, so that users who rely on that reality can do so in a
standard-conforming way.
Ah, OK. But as Melissa points out above, three major compilers (gcc, MSVC,
clang) exploit signed overflow UB. I'm pretty sure that out of range bit
shift is the same.
Is there any point to this proposed trait, then, except to detect whether
special modes (fwrapv) have been enabled (thanks Mikhail for pointing that
out)? Or is that valuable enough?
I'm mildly sceptical, in that I wouldn't use it and I'd have thought that
anyone writing code to use it would prefer to just write fully portable
code. But I suppose it could have its place in certain code bases and
organizations.
--=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/CAJnLdOa%3DcAquPtC4vhX84hwSAyZ58PKXmXafXQWFwe6LG=
V%2Bu6w%40mail.gmail.com.
--001a113d00a649d2f00539335bd1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On 3 Aug 2016 8:52 p.m., "Nicol Bolas" <<a href=
=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>> wrote:<br>
><br>
> On Wednesday, August 3, 2016 at 3:28:55 PM UTC-4, Edward Catmur wrote:=
<br>
>><br>
>> On Wed, Aug 3, 2016 at 4:27 PM, Nicol Bolas <<a href=3D"mailto:=
jmck...@gmail.com">jmck...@gmail.com</a>> wrote:<br>
>>><br>
>>> On Tuesday, August 2, 2016 at 11:05:54 PM UTC-4, Thiago Maciei=
ra wrote:<br>
>>>><br>
>>>> On ter=C3=A7a-feira, 2 de agosto de 2016 18:21:25 PDT Nico=
l Bolas wrote: <br>
>>>> > You're misunderstanding the feature. The feature =
is that, if the compiler <br>
>>>> > *already implements* defined 2's complement behav=
ior, then it sets that <br>
>>>> > trait to `true`. <br>
>>>><br>
>>>> You mean that it implements the behaviour even where the s=
tandard says the <br>
>>>> behaviour is undefined? <br>
>>>><br>
>>>> If so, why do you think compiler writers will do this? Wha=
t's their incentive?<br>
>>><br>
>>><br>
>>> Overflow behavior is defined by the underlying hardware. Well.=
... is there convergence in hardware towards one particular solution? That i=
s, do most two's complement hardware wrap or flush? How do most two'=
;s complement chips handle bitshifting by more than the size of the registe=
r?<br>
>>><br>
>>> If there is consensus on these questions, we should have a var=
iable letting us know that the platform supports the consensus behavior. If=
there is no consensus, so be it.<br>
>><br>
>><br>
>> That doesn't answer the question. Suppose there is indeed a co=
nsensus behavior that can easily be implemented on the majority of platform=
s.<br>
><br>
><br>
> I didn't say "can easily be implemented". I meant what t=
hey actually do, not what they could be made to do. If there's no conse=
nsus on that (especially if it changes from expression to expression), so b=
e it.<br>
><br>
> The goal is not to change compiler behavior. The goal is not to force =
compilers in a smaller box. The goal is to make the box the standard define=
s more in line with the box that a large set of platforms actually provide,=
so that users who rely on that reality can do so in a standard-conforming =
way.</p>
<p dir=3D"ltr">Ah, OK. But as Melissa points out above, three major compile=
rs (gcc, MSVC, clang) exploit signed overflow UB. I'm pretty sure that =
out of range bit shift is the same.</p>
<p dir=3D"ltr">Is there any point to this proposed trait, then, except to d=
etect whether special modes (fwrapv) have been enabled (thanks Mikhail for =
pointing that out)? Or is that valuable enough?</p>
<p dir=3D"ltr">I'm mildly sceptical, in that I wouldn't use it and =
I'd have thought that anyone writing code to use it would prefer to jus=
t write fully portable code. But I suppose it could have its place in certa=
in code bases and organizations. </p>
<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/CAJnLdOa%3DcAquPtC4vhX84hwSAyZ58PKXmX=
afXQWFwe6LGV%2Bu6w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOa%3DcA=
quPtC4vhX84hwSAyZ58PKXmXafXQWFwe6LGV%2Bu6w%40mail.gmail.com</a>.<br />
--001a113d00a649d2f00539335bd1--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 03 Aug 2016 18:25:56 -0700
Raw View
On quinta-feira, 4 de agosto de 2016 00:30:52 PDT Mikhail Maltsev wrote:
> Why not? Some compilers (GCC, Clang) already implement well-defined signed
> overflow as an extension (with -fwrapv command-line flag). There are some
> codebases (e.g. CPython) which use this option.
Because of the very reason that it requires a compiler switch. If you know
that the compiler can only do it with a switch, then you know what compiler it
is and you're in control of the buildsystem. At that point, you don't need a
constexpr value in a standard header, you can define your own or a macro.
--
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/10194191.ArFrL7Zlx9%40tjmaciei-mobl1.
.
Author: Demi Obenour <demiobenour@gmail.com>
Date: Thu, 4 Aug 2016 14:21:34 -0400
Raw View
--94eb2c123c7429876b05394305f9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
One reason for a pragma is that in many cases, wrapping is required
project-wide.
On Aug 3, 2016 4:29 PM, "Magnus Fromreide" <magfr@lysator.liu.se> wrote:
> I do not remember if this have been up before but would a "wrapping"
> modifier
> that could be applied to a signed integer type be useful?
>
> This would allow code that depends on wrapping behaviour to request it
> explicitly and let the rest of the world keep using the old behaviour.
>
> /MF
>
> On Wed, Aug 03, 2016 at 12:52:19PM -0700, Nicol Bolas wrote:
> > On Wednesday, August 3, 2016 at 3:28:55 PM UTC-4, Edward Catmur wrote:
> > >
> > > On Wed, Aug 3, 2016 at 4:27 PM, Nicol Bolas <jmck...@gmail.com
> > > <javascript:>> wrote:
> > >
> > >> On Tuesday, August 2, 2016 at 11:05:54 PM UTC-4, Thiago Macieira
> wrote:
> > >>>
> > >>> On ter=C3=A7a-feira, 2 de agosto de 2016 18:21:25 PDT Nicol Bolas w=
rote:
> > >>> > You're misunderstanding the feature. The feature is that, if the
> > >>> compiler
> > >>> > *already implements* defined 2's complement behavior, then it set=
s
> > >>> that
> > >>> > trait to `true`.
> > >>>
> > >>> You mean that it implements the behaviour even where the standard
> says
> > >>> the
> > >>> behaviour is undefined?
> > >>>
> > >>> If so, why do you think compiler writers will do this? What's their
> > >>> incentive?
> > >>>
> > >>
> > >> Overflow behavior is defined by the underlying hardware. Well... is
> there
> > >> convergence in hardware towards one particular solution? That is, do
> most
> > >> two's complement hardware wrap or flush? How do most two's complemen=
t
> chips
> > >> handle bitshifting by more than the size of the register?
> > >>
> > >> If there is consensus on these questions, we should have a variable
> > >> letting us know that the platform supports the consensus behavior. I=
f
> there
> > >> is no consensus, so be it.
> > >>
> > >
> > > That doesn't answer the question. Suppose there is indeed a consensus
> > > behavior that can easily be implemented on the majority of platforms.
> > >
> >
> > I didn't say "can easily be implemented". I meant what they *actually
> do*,
> > not what they could be made to do. If there's no consensus on that
> > (especially if it changes from expression to expression), so be it.
> >
> > The goal is not to change compiler *behavior*. The goal is not to force
> > compilers in a smaller box. The goal is to make the box the standard
> > defines more in line with the box that a large set of platforms actuall=
y
> > provide, so that users who rely on that reality can do so in a
> > standard-conforming way.
> >
> > If integer overflow isn't able to be in that box, then it isn't that th=
at
> > box. But we should omit it not because the standard makes it UB; it
> should
> > be omitted because it's not part of that box of actual current consensu=
s
> > behavior.
> >
> > --
> > 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/a07070d8-e31a-47a8-
> 9640-62611f828cb4%40isocpp.org.
>
> --
> 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/
> isocpp.org/d/topic/std-proposals/Ifq39OuA-vU/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/
> isocpp.org/d/msgid/std-proposals/20160803202934.GA2572%40noemi.
>
--=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/CAJEMUN-x2nvLUVCyb3fkQjDWMzx6S%3Dni6bwkxKYFPegx7=
Q-Wpg%40mail.gmail.com.
--94eb2c123c7429876b05394305f9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">One reason for a pragma is that in many cases, wrapping is r=
equired project-wide.</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Aug 3, 2016 4:=
29 PM, "Magnus Fromreide" <<a href=3D"mailto:magfr@lysator.liu=
..se">magfr@lysator.liu.se</a>> wrote:<br type=3D"attribution"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">I do not remember if this have been up before but woul=
d a "wrapping" modifier<br>
that could be applied to a signed integer type be useful?<br>
<br>
This would allow code that depends on wrapping behaviour to request it<br>
explicitly and let the rest of the world keep using the old behaviour.<br>
<br>
/MF<br>
<br>
On Wed, Aug 03, 2016 at 12:52:19PM -0700, Nicol Bolas wrote:<br>
> On Wednesday, August 3, 2016 at 3:28:55 PM UTC-4, Edward Catmur wrote:=
<br>
> ><br>
> > On Wed, Aug 3, 2016 at 4:27 PM, Nicol Bolas <<a href=3D"mailto=
:jmck...@gmail.com">jmck...@gmail.com</a><br>
> > <javascript:>> wrote:<br>
> ><br>
> >> On Tuesday, August 2, 2016 at 11:05:54 PM UTC-4, Thiago Macie=
ira wrote:<br>
> >>><br>
> >>> On ter=C3=A7a-feira, 2 de agosto de 2016 18:21:25 PDT Nic=
ol Bolas wrote:<br>
> >>> > You're misunderstanding the feature. The feature=
is that, if the<br>
> >>> compiler<br>
> >>> > *already implements* defined 2's complement beha=
vior, then it sets<br>
> >>> that<br>
> >>> > trait to `true`.<br>
> >>><br>
> >>> You mean that it implements the behaviour even where the =
standard says<br>
> >>> the<br>
> >>> behaviour is undefined?<br>
> >>><br>
> >>> If so, why do you think compiler writers will do this? Wh=
at's their<br>
> >>> incentive?<br>
> >>><br>
> >><br>
> >> Overflow behavior is defined by the underlying hardware. Well=
.... is there<br>
> >> convergence in hardware towards one particular solution? That=
is, do most<br>
> >> two's complement hardware wrap or flush? How do most two&=
#39;s complement chips<br>
> >> handle bitshifting by more than the size of the register?<br>
> >><br>
> >> If there is consensus on these questions, we should have a va=
riable<br>
> >> letting us know that the platform supports the consensus beha=
vior. If there<br>
> >> is no consensus, so be it.<br>
> >><br>
> ><br>
> > That doesn't answer the question. Suppose there is indeed a c=
onsensus<br>
> > behavior that can easily be implemented on the majority of platfo=
rms.<br>
> ><br>
><br>
> I didn't say "can easily be implemented". I meant what t=
hey *actually do*,<br>
> not what they could be made to do. If there's no consensus on that=
<br>
> (especially if it changes from expression to expression), so be it.<br=
>
><br>
> The goal is not to change compiler *behavior*. The goal is not to forc=
e<br>
> compilers in a smaller box. The goal is to make the box the standard<b=
r>
> defines more in line with the box that a large set of platforms actual=
ly<br>
> provide, so that users who rely on that reality can do so in a<br>
> standard-conforming way.<br>
><br>
> If integer overflow isn't able to be in that box, then it isn'=
t that that<br>
> box. But we should omit it not because the standard makes it UB; it sh=
ould<br>
> be omitted because it's not part of that box of actual current con=
sensus<br>
> behavior.<br>
><br>
> --<br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/a07070d8-e31a-47a8-9640-62611f82=
8cb4%40isocpp.org" rel=3D"noreferrer" target=3D"_blank">https://groups.goog=
le.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/a07070d8-e31a-47a8-<wbr=
>9640-62611f828cb4%40isocpp.org</a><wbr>.<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/Ifq39OuA-vU/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/topic/s=
td-<wbr>proposals/Ifq39OuA-vU/<wbr>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">std-proposals+unsubscrib=
e@<wbr>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/20160803202934.GA2572%40noemi" rel=3D=
"noreferrer" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/=
d/msgid/std-<wbr>proposals/20160803202934.<wbr>GA2572%40noemi</a>.<br>
</blockquote></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/CAJEMUN-x2nvLUVCyb3fkQjDWMzx6S%3Dni6b=
wkxKYFPegx7Q-Wpg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJEMUN-x2nvLUV=
Cyb3fkQjDWMzx6S%3Dni6bwkxKYFPegx7Q-Wpg%40mail.gmail.com</a>.<br />
--94eb2c123c7429876b05394305f9--
.
Author: Demi Obenour <demiobenour@gmail.com>
Date: Thu, 4 Aug 2016 14:23:21 -0400
Raw View
--001a1144a74888770d0539430b0e
Content-Type: text/plain; charset=UTF-8
My point is that there should be a standardized way to turn on wrapping
overflow.
On Aug 3, 2016 9:26 PM, "Thiago Macieira" <thiago@macieira.org> wrote:
> On quinta-feira, 4 de agosto de 2016 00:30:52 PDT Mikhail Maltsev wrote:
> > Why not? Some compilers (GCC, Clang) already implement well-defined
> signed
> > overflow as an extension (with -fwrapv command-line flag). There are some
> > codebases (e.g. CPython) which use this option.
>
> Because of the very reason that it requires a compiler switch. If you know
> that the compiler can only do it with a switch, then you know what
> compiler it
> is and you're in control of the buildsystem. At that point, you don't need
> a
> constexpr value in a standard header, you can define your own or a macro.
>
> --
> 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 a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/Ifq39OuA-vU/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/
> isocpp.org/d/msgid/std-proposals/10194191.ArFrL7Zlx9%40tjmaciei-mobl1.
>
--
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/CAJEMUN9T90gwjKHvHoGFWxxBepZb3g4b6ra6eSjbSh%2BLiXzgGg%40mail.gmail.com.
--001a1144a74888770d0539430b0e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">My point is that there should be a standardized way to turn =
on wrapping overflow.</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Aug 3, 2016 9:=
26 PM, "Thiago Macieira" <<a href=3D"mailto:thiago@macieira.or=
g">thiago@macieira.org</a>> wrote:<br type=3D"attribution"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">On quinta-feira, 4 de agosto de 2016 00:30:52 PDT Mikhail=
Maltsev wrote:<br>
> Why not? Some compilers (GCC, Clang) already implement well-defined si=
gned<br>
> overflow as an extension (with -fwrapv command-line flag). There are s=
ome<br>
> codebases (e.g. CPython) which use this option.<br>
<br>
Because of the very reason that it requires a compiler switch. If you know<=
br>
that the compiler can only do it with a switch, then you know what compiler=
it<br>
is and you're in control of the buildsystem. At that point, you don'=
;t need a<br>
constexpr value in a standard header, you can define your own or a macro.<b=
r>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<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/Ifq39OuA-vU/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/topic/s=
td-<wbr>proposals/Ifq39OuA-vU/<wbr>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">std-proposals+unsubscrib=
e@<wbr>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/10194191.ArFrL7Zlx9%40tjmaciei-mobl1"=
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<wbr>isoc=
pp.org/d/msgid/std-<wbr>proposals/10194191.ArFrL7Zlx9%<wbr>40tjmaciei-mobl1=
</a>.<br>
</blockquote></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/CAJEMUN9T90gwjKHvHoGFWxxBepZb3g4b6ra6=
eSjbSh%2BLiXzgGg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJEMUN9T90gwjK=
HvHoGFWxxBepZb3g4b6ra6eSjbSh%2BLiXzgGg%40mail.gmail.com</a>.<br />
--001a1144a74888770d0539430b0e--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 04 Aug 2016 11:36:36 -0700
Raw View
On quinta-feira, 4 de agosto de 2016 14:23:21 PDT Demi Obenour wrote:
> My point is that there should be a standardized way to turn on wrapping
> overflow.
Agreed. That can be a library solution.
--
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/4821380.bLPnSKZ23O%40tjmaciei-mobl1.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 4 Aug 2016 13:36:18 -0500
Raw View
--001a113e31c431cb630539433c96
Content-Type: text/plain; charset=UTF-8
On 4 August 2016 at 13:21, Demi Obenour <demiobenour@gmail.com> wrote:
> One reason for a pragma is that in many cases, wrapping is required
> project-wide.
>
Including in third-party libraries you don't have source to? How will that
work?
--
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%2BMCOGU6AzERY%2B2_sLq5MtQYsdSAaQ_0Zt-wmmWX%2BSjj4g%40mail.gmail.com.
--001a113e31c431cb630539433c96
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 4 August 2016 at 13:21, Demi Obenour <span dir=3D"ltr"><<a href=3D"ma=
ilto:demiobenour@gmail.com" target=3D"_blank">demiobenour@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"><p dir=3D"ltr">One reason =
for a pragma is that in many cases, wrapping is required project-wide.</p><=
/blockquote></div>Including in third-party libraries you don't have sou=
rce to?=C2=A0 How will that work?<br>-- <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:ne=
vin@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%2BMCOGU6AzERY%2B2_sLq5MtQYsdSA=
aQ_0Zt-wmmWX%2BSjj4g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMC=
OGU6AzERY%2B2_sLq5MtQYsdSAaQ_0Zt-wmmWX%2BSjj4g%40mail.gmail.com</a>.<br />
--001a113e31c431cb630539433c96--
.
Author: Demi Obenour <demiobenour@gmail.com>
Date: Thu, 11 Aug 2016 19:32:58 -0400
Raw View
--94eb2c11ba20a9905a0539d42f85
Content-Type: text/plain; charset=UTF-8
Sorry. I am referring to the entirety of the "maintenance unit" (usually a
single repository).
On Aug 4, 2016 2:37 PM, "Nevin Liber" <nevin@eviloverlord.com> wrote:
>
> On 4 August 2016 at 13:21, Demi Obenour <demiobenour@gmail.com> wrote:
>
>> One reason for a pragma is that in many cases, wrapping is required
>> project-wide.
>>
> Including in third-party libraries you don't have source to? How will
> that work?
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
>
> --
> 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/
> isocpp.org/d/topic/std-proposals/Ifq39OuA-vU/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/
> isocpp.org/d/msgid/std-proposals/CAGg_6%2BMCOGU6AzERY%2B2_
> sLq5MtQYsdSAaQ_0Zt-wmmWX%2BSjj4g%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMCOGU6AzERY%2B2_sLq5MtQYsdSAaQ_0Zt-wmmWX%2BSjj4g%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAJEMUN_K0yWFs6GBqRyj4GQ-RPcBLBn01%2BFonFcBZSSMVQQUbg%40mail.gmail.com.
--94eb2c11ba20a9905a0539d42f85
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Sorry.=C2=A0 I am referring to the entirety of the "mai=
ntenance unit" (usually a single repository).</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Aug 4, 2016 2:=
37 PM, "Nevin Liber" <<a href=3D"mailto:nevin@eviloverlord.com=
">nevin@eviloverlord.com</a>> wrote:<br type=3D"attribution"><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><br><div cl=
ass=3D"gmail_quote">On 4 August 2016 at 13:21, Demi Obenour <span dir=3D"lt=
r"><<a href=3D"mailto:demiobenour@gmail.com" target=3D"_blank">demiobeno=
ur@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=
=3D"ltr">One reason for a pragma is that in many cases, wrapping is require=
d project-wide.</p></blockquote></div>Including in third-party libraries yo=
u don't have source to?=C2=A0 How will that work?<br>-- <br><div data-s=
martmail=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><wbr>> =C2=
=A0<a href=3D"tel:%2B1-847-691-1404" value=3D"+18476911404" target=3D"_blan=
k">+1-847-691-1404</a></div></div></div></div></div>
</div></div>
<p></p>
-- <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/Ifq39OuA-vU/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/I=
fq39OuA-vU/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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>
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%2BMCOGU6AzERY%2B2_sLq5MtQYsdSA=
aQ_0Zt-wmmWX%2BSjj4g%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%<wbr>2BMCOGU6AzERY%2B2_<wbr>sLq5MtQYsdSAaQ_0Zt-=
wmmWX%<wbr>2BSjj4g%40mail.gmail.com</a>.<br>
</blockquote></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/CAJEMUN_K0yWFs6GBqRyj4GQ-RPcBLBn01%2B=
FonFcBZSSMVQQUbg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJEMUN_K0yWFs6=
GBqRyj4GQ-RPcBLBn01%2BFonFcBZSSMVQQUbg%40mail.gmail.com</a>.<br />
--94eb2c11ba20a9905a0539d42f85--
.