------=_Part_78_83392188.1418342862966
Content-Type: multipart/alternative;
 boundary="----=_Part_79_2057158531.1418342862972"

------=_Part_79_2057158531.1418342862972
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think that integer overflow and signed shifts should be=20
implementation-defined instead of undefined.

Signed overflow should be defined to an implementation-defined value=20
(consistently), or cause a trap.

Division by zero and (INT_MIN / -1) when -INT_MIN > INT_MAX would remain=20
undefined.

Signed shifting should be defined as equivalent to multiplication or=20
division (rounding toward -=E2=88=9E instead of 0) by a power of 2.  Overfl=
ows=20
would be treated the same as other arithmetic.  Exceeding the shift count=
=20
would return an implementation-defined value or trap like with overflows.

This definition would cover the important things, and bring sanity to the=
=20
current rules.

Melissa

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_79_2057158531.1418342862972
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think that integer overflow and signed shifts should be =
implementation-defined instead of undefined.<br><br>Signed overflow should =
be defined to an implementation-defined value (consistently), or cause a tr=
ap.<br><br>Division by zero and (INT_MIN / -1) when -INT_MIN &gt; INT_MAX w=
ould remain undefined.<br><br>Signed shifting should be defined as equivale=
nt to multiplication or division (rounding toward -=E2=88=9E instead of 0) =
by a power of 2.&nbsp; Overflows would be treated the same as other arithme=
tic.&nbsp; Exceeding the shift count would return an implementation-defined=
 value or trap like with overflows.<br><br>This definition would cover the =
important things, and bring sanity to the current rules.<br><br>Melissa<br>=
</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_79_2057158531.1418342862972--
------=_Part_78_83392188.1418342862966--

.

--Apple-Mail-F77CA170-6D52-4A80-9BB4-76CBC48AEEC3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi

Il giorno 12/dic/2014, alle ore 01:07, Myriachan <myriachan@gmail.com> ha s=
critto:
>=20
> I think that integer overflow and signed shifts should be implementation-=
defined instead of undefined.

That would be nice, but...

>=20
> Signed overflow should be defined to an implementation-defined value (con=
sistently), or cause a trap.

....if you could always have an implementation-defined result, I would agree=
, but are there cases when overflow traps and the hardware can't be efficie=
ntly turned to be silent? In this case, how would you define "to trap" in t=
he standard? I think it is why it is currently undefined instead of impleme=
ntation defined.=20

>=20
> Division by zero and (INT_MIN / -1) when -INT_MIN > INT_MAX would remain =
undefined.
>=20
> Signed shifting should be defined as equivalent to multiplication or divi=
sion (rounding toward -=E2=88=9E instead of 0) by a power of 2.  Overflows =
would be treated the same as other arithmetic.  Exceeding the shift count w=
ould return an implementation-defined value or trap like with overflows.
>=20
> This definition would cover the important things, and bring sanity to the=
 current rules.
>=20
> Melissa
>=20

Regards,
Nicola

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail-F77CA170-6D52-4A80-9BB4-76CBC48AEEC3
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>Hi</div><div><br></div><div>Il gio=
rno 12/dic/2014, alle ore 01:07, Myriachan &lt;<a href=3D"mailto:myriachan@=
gmail.com">myriachan@gmail.com</a>&gt; ha scritto:</div><div><br></div><blo=
ckquote type=3D"cite"><div><div dir=3D"ltr">I think that integer overflow a=
nd signed shifts should be implementation-defined instead of undefined.<br>=
</div></div></blockquote><div><br></div><div>That would be nice, but...</di=
v><br><blockquote type=3D"cite"><div><div dir=3D"ltr"><br>Signed overflow s=
hould be defined to an implementation-defined value (consistently), or caus=
e a trap.<br></div></div></blockquote><div><br></div><div>...if you could a=
lways have an implementation-defined result, I would agree, but are there c=
ases when overflow traps and the hardware can't be efficiently turned to be=
 silent? In this case, how would you define "to trap" in the standard? I th=
ink it is why it is currently undefined instead of implementation defined.&=
nbsp;</div><br><blockquote type=3D"cite"><div><div dir=3D"ltr"><br>Division=
 by zero and (INT_MIN / -1) when -INT_MIN &gt; INT_MAX would remain undefin=
ed.<br><br>Signed shifting should be defined as equivalent to multiplicatio=
n or division (rounding toward -=E2=88=9E instead of 0) by a power of 2.&nb=
sp; Overflows would be treated the same as other arithmetic.&nbsp; Exceedin=
g the shift count would return an implementation-defined value or trap like=
 with overflows.<br><br></div></div></blockquote><blockquote type=3D"cite">=
<div><div dir=3D"ltr">This definition would cover the important things, and=
 bring sanity to the current rules.<br><br>Melissa<br></div>

<p></p><br>
</div></blockquote><br><div>Regards,</div><div>Nicola</div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail-F77CA170-6D52-4A80-9BB4-76CBC48AEEC3--

.

------=_Part_86_2131851671.1418345686713
Content-Type: multipart/alternative;
 boundary="----=_Part_87_1413867949.1418345686713"

------=_Part_87_1413867949.1418345686713
Content-Type: text/plain; charset=UTF-8

On Thursday, December 11, 2014 4:33:15 PM UTC-8, Nicola Gigante wrote:
>
> Hi
>
> Il giorno 12/dic/2014, alle ore 01:07, Myriachan <myri...@gmail.com
> <javascript:>> ha scritto:
>
> I think that integer overflow and signed shifts should be
> implementation-defined instead of undefined.
>
>
> That would be nice, but...
>
>
> Signed overflow should be defined to an implementation-defined value
> (consistently), or cause a trap.
>
>
> ...if you could always have an implementation-defined result, I would
> agree, but are there cases when overflow traps and the hardware can't be
> efficiently turned to be silent? In this case, how would you define "to
> trap" in the standard? I think it is why it is currently undefined instead
> of implementation defined.
>
>
That is true, but the Standard already uses the term "trap" with arithmetic
operations without defining it.  For example, std::numeric_limits<T>::traps.

One way to handle this is to define things so that the currently-defined
overflow cases do one of the following by implementation choice:

1. result in an arbitrary, but consistent value;
2. throw an exception;
3. raise a C signal (presumably SIGFPE);
4. or cause immediate abnormal program termination, whose detailed meaning
is implementation-defined.

In Windows, for example, integer overflow in +, -, * and << is case (1),
while (INT_MIN / -1) and x / 0 result in case (2).  (Yes, in Windows,
division by zero can be caught with C++ catch (...).)  POSIX systems on x86
tend to (1) and (3) respectively, while POSIX on PowerPC tends to always be
(1).  MIPS machines are (1), but due to the ease of such implementation,
often have a compiler option to change to (3).

I personally think that (1) should be more detailed for non-division: on
implementations choosing two's-complement representation, (1) would be
required to act modulo 2^bitsize.

The whole point of this is to stop the BS that compilers pull like delete
sections of code.  It turns overflow into a "it either works or it doesn't"
design, rather than allowing arbitrary behavior.

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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_87_1413867949.1418345686713
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, December 11, 2014 4:33:15 PM UTC-8, Nicola Gi=
gante 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"auto">=
<div>Hi</div><div><br></div><div>Il giorno 12/dic/2014, alle ore 01:07, Myr=
iachan &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"nLigF1B9_tkJ" onmousedown=3D"this.href=3D'javascript:';return true;" on=
click=3D"this.href=3D'javascript:';return true;">myri...@gmail.com</a>&gt; =
ha scritto:</div><div><br></div><blockquote type=3D"cite"><div><div dir=3D"=
ltr">I think that integer overflow and signed shifts should be implementati=
on-defined instead of undefined.<br></div></div></blockquote><div><br></div=
><div>That would be nice, but...</div><br><blockquote type=3D"cite"><div><d=
iv dir=3D"ltr"><br>Signed overflow should be defined to an implementation-d=
efined value (consistently), or cause a trap.<br></div></div></blockquote><=
div><br></div><div>...if you could always have an implementation-defined re=
sult, I would agree, but are there cases when overflow traps and the hardwa=
re can't be efficiently turned to be silent? In this case, how would you de=
fine "to trap" in the standard? I think it is why it is currently undefined=
 instead of implementation defined.&nbsp;</div><br></div></blockquote><div>=
<br>That is true, but the Standard already uses the term "trap" with arithm=
etic operations without defining it.&nbsp; For example, <span style=3D"font=
-family: courier new,monospace;">std::numeric_limits&lt;T&gt;::traps</span>=
..<br><br>One way to handle this is to define things so that the currently-d=
efined overflow cases do one of the following by implementation choice:<br>=
<br>1. result in an arbitrary, but consistent value;<br>2. throw an excepti=
on;<br>3. raise a C signal (presumably SIGFPE);<br>4. or cause immediate ab=
normal program termination, whose detailed meaning is implementation-define=
d.<br><br>In Windows, for example, integer overflow in <span style=3D"font-=
family: courier new,monospace;">+</span>, <span style=3D"font-family: couri=
er new,monospace;">-</span>, <span style=3D"font-family: courier new,monosp=
ace;">*</span> and <span style=3D"font-family: courier new,monospace;">&lt;=
&lt;</span> is case (1), while <span style=3D"font-family: courier new,mono=
space;">(INT_MIN / -1)</span> and <span style=3D"font-family: courier new,m=
onospace;">x / 0</span> result in case (2).&nbsp; (Yes, in Windows, divisio=
n by zero can be caught with C++ <span style=3D"font-family: courier new,mo=
nospace;">catch (...)</span>.)&nbsp; POSIX systems on x86 tend to (1) and (=
3) respectively, while POSIX on PowerPC tends to always be (1).&nbsp; MIPS =
machines are (1), but due to the ease of such implementation, often have a =
compiler option to change to (3).<br><br>I personally think that (1) should=
 be more detailed for non-division: on implementations choosing two's-compl=
ement representation, (1) would be required to act modulo 2^bitsize.<br><br=
>The whole point of this is to stop the BS that compilers pull like delete =
sections of code.&nbsp; It turns overflow into a "it either works or it doe=
sn't" design, rather than allowing arbitrary behavior.<br><br>Melissa<br></=
div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_87_1413867949.1418345686713--
------=_Part_86_2131851671.1418345686713--

.

On Dec 11, 2014, at 7:54 PM, Myriachan <myriachan@gmail.com> wrote:

> The whole point of this is to stop the BS that compilers pull like delete=
 sections of code.  It turns overflow into a "it either works or it doesn't=
" design, rather than allowing arbitrary behavior.

+10^6 (couldn=E2=80=99t agree more)

Howard

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--Apple-Mail=_C6DF8C63-A1F9-4633-B2E5-9C521140433B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2014=E2=80=9312=E2=80=9312, at 8:54 AM, Myriachan <myriachan@gmail.com=
> wrote:
>=20
> The whole point of this is to stop the BS that compilers pull like delete=
 sections of code.=20


It would be friendlier to give a warning when such an optimization occurs, =
and we=E2=80=99re at an awkward stage where sanitizers aren=E2=80=99t as wi=
despread as they should be. But, if vendors have decided to do this, I don=
=E2=80=99t think that the standard should require them to permanently remov=
e the capability. It=E2=80=99s been contentious, but they=E2=80=99ve alread=
y chosen their own paths with respect to ample customer feedback. I don=E2=
=80=99t know the market shares, but GCC has a liberal interpretation of UB,=
 I think Clang does, and that=E2=80=99s consensus for a lot of C++-land alr=
eady.

A library of functions with =E2=80=9Ccontained=E2=80=9D arithmetic would ha=
ve much less impact. We already even have the classes in <functional>. Simp=
ly say that if the behavior of the encapsulated operation is undefined, the=
 behavior of the function is implementation-defined.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_C6DF8C63-A1F9-4633-B2E5-9C521140433B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2014=E2=80=9312=
=E2=80=9312, at 8:54 AM, Myriachan &lt;<a href=3D"mailto:myriachan@gmail.co=
m" class=3D"">myriachan@gmail.com</a>&gt; wrote:</div></blockquote><blockqu=
ote type=3D"cite" class=3D""><div class=3D""><br class=3D""></div></blockqu=
ote><blockquote type=3D"cite" class=3D""><div class=3D"">The whole point of=
 this is to stop the BS that compilers pull like delete sections of code.&n=
bsp;</div></blockquote></div><div class=3D""><div><div><br class=3D""></div=
><div>It would be friendlier to give a warning when such an optimization oc=
curs, and we=E2=80=99re at an awkward stage where sanitizers aren=E2=80=99t=
 as widespread as they should be. But, if vendors have decided to do this, =
I don=E2=80=99t think that the standard should require them to permanently =
remove the capability. It=E2=80=99s been contentious, but they=E2=80=99ve a=
lready chosen their own paths with respect to ample customer feedback. I do=
n=E2=80=99t know the market shares, but GCC has a liberal interpretation of=
 UB, I think Clang does, and that=E2=80=99s consensus for a lot of C++-land=
 already.</div><div><br class=3D""></div><div>A library of functions with =
=E2=80=9Ccontained=E2=80=9D arithmetic would have much less impact. We alre=
ady even have the classes in <font face=3D"Courier" class=3D"">&lt;function=
al&gt;</font>. Simply say that if the behavior of the encapsulated operatio=
n is undefined, the behavior of the function is implementation-defined.</di=
v></div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_C6DF8C63-A1F9-4633-B2E5-9C521140433B--

.

On Thursday 11 December 2014 16:07:42 Myriachan wrote:
> I think that integer overflow and signed shifts should be
> implementation-defined instead of undefined.

This pessimises the following code:

 if (i + 1 > i)

For a given integer i. Now the compiler can assume that it doesn't overflow, so
the check can be eliminated. With your suggestion, the compiler can't assume
that, so it will need to execute the check.

The example above is contrived, but it can happen after the optimiser inlines
a lot of code. I know that because GCC has a warning for exactly that case and
it triggers in Qt code:

qstring.h:991:7: warning: assuming signed overflow does not occur when assuming
that (X - c) > X is always false [-Wstrict-overflow]
     { if (i >= s.size()) s.expand(i); else s.detach();
       ^

It happens when you do:

 container.append(data);
 container.append(more_data);

because the append() functions will do:

 if (size() + data.length() > capacity())
  resize(size() + data.length());

After the first appending, probably size() == capacity(). If the signed integer
overflow is undefined, the compiler can optimise the test for overflow away and
simply call resize().

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_513_1875584168.1418391226153
Content-Type: multipart/alternative;
 boundary="----=_Part_514_30657263.1418391226154"

------=_Part_514_30657263.1418391226154
Content-Type: text/plain; charset=UTF-8

On Friday, December 12, 2014 1:54:46 AM UTC+1, Myriachan wrote:
>
> In Windows, for example, integer overflow in +, -, * and << is case (1),
> while (INT_MIN / -1) and x / 0 result in case (2).
>

What Windows? x86 / x64? Itanium? PPC? ARM?
Should code depend on signed overflows?
Wouldn't it stop sanitizers from detecting bugs where signed stuff does but
shouldn't overflow?

Can all current and feature archs implement this without cost?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_514_30657263.1418391226154
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, December 12, 2014 1:54:46 AM UTC+1, Myriachan w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>In =
Windows, for example, integer overflow in <span style=3D"font-family:courie=
r new,monospace">+</span>, <span style=3D"font-family:courier new,monospace=
">-</span>, <span style=3D"font-family:courier new,monospace">*</span> and =
<span style=3D"font-family:courier new,monospace">&lt;&lt;</span> is case (=
1), while <span style=3D"font-family:courier new,monospace">(INT_MIN / -1)<=
/span> and <span style=3D"font-family:courier new,monospace">x / 0</span> r=
esult in case (2).<br></div></div></blockquote><div><br></div><div>What Win=
dows? x86 / x64? Itanium? PPC? ARM?</div><div>Should code depend on signed =
overflows?</div><div>Wouldn't it stop sanitizers from detecting bugs where =
signed stuff does but shouldn't overflow?</div><div><br></div><div>Can all =
current and feature archs implement this without cost?</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_514_30657263.1418391226154--
------=_Part_513_1875584168.1418391226153--

.

On Dec 11, 2014, at 11:18 PM, Thiago Macieira <thiago@macieira.org> wrote:

> This pessimises the following code:
>
>  if (i + 1 > i)
>
> For a given integer i. Now the compiler can assume that it doesn't overflow, so
> the check can be eliminated. With your suggestion, the compiler can't assume
> that, so it will need to execute the check.

It seems incredibly fragile to me that all of this is dependent upon whether i is int or unsigned.  If we were designing a language with a clean sheet of paper today, there is absolutely no way anyone would agree to such a schism.

Howard

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Fri, Dec 12, 2014 at 5:06 PM, Howard Hinnant
<howard.hinnant@gmail.com> wrote:
> On Dec 11, 2014, at 11:18 PM, Thiago Macieira <thiago@macieira.org> wrote:
>
>> This pessimises the following code:
>>
>>       if (i + 1 > i)
>>
>> For a given integer i. Now the compiler can assume that it doesn't overflow, so
>> the check can be eliminated. With your suggestion, the compiler can't assume
>> that, so it will need to execute the check.
>
> It seems incredibly fragile to me that all of this is dependent upon whether i is int or unsigned.  If we were designing a language with a clean sheet of paper today, there is absolutely no way anyone would agree to such a schism.

Why not? :p
Would such a language allow or disallow overflow? What do D, Java and C# do?
How often is signed overflow a bug and how often is it not?


--
Olaf

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Friday 12 December 2014 11:06:32 Howard Hinnant wrote:
> On Dec 11, 2014, at 11:18 PM, Thiago Macieira <thiago@macieira.org> wrote:
> > This pessimises the following code:
> >  if (i + 1 > i)
> >
> > For a given integer i. Now the compiler can assume that it doesn't
> > overflow, so the check can be eliminated. With your suggestion, the
> > compiler can't assume that, so it will need to execute the check.
>
> It seems incredibly fragile to me that all of this is dependent upon whether
> i is int or unsigned.  If we were designing a language with a clean sheet
> of paper today, there is absolutely no way anyone would agree to such a
> schism.

If I were to guess why this is so, I'd say that originally the compiler was
supposed to assume that it never overflowed under any circumstance. However,
since all unsigned had predictable overflow behaviour because there is only one
way to store them, it became interesting to use the overflow to check for
overflow (i.e., make it not undefined).

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_714_1197007023.1418414926646
Content-Type: multipart/alternative;
 boundary="----=_Part_715_470230465.1418414926646"

------=_Part_715_470230465.1418414926646
Content-Type: text/plain; charset=UTF-8

On Friday, December 12, 2014 8:08:52 AM UTC-8, Olaf van der Spek wrote:
>
> > It seems incredibly fragile to me that all of this is dependent upon
> whether i is int or unsigned.  If we were designing a language with a clean
> sheet of paper today, there is absolutely no way anyone would agree to such
> a schism.
>
> Why not? :p
> Would such a language allow or disallow overflow? What do D, Java and C#
> do?
> How often is signed overflow a bug and how often is it not?
>
>
D, Java and C# all wrap mod (1<<bitsize), and assume a two's-complement
implementation.  The very recent language Swift has two sets of arithmetic
operators: one set traps on overflow, and the other set wraps (even though
Objective-C considers it undefined instead).

On Thursday, December 11, 2014 8:18:24 PM UTC-8, Thiago Macieira wrote:On
Thursday 11 December 2014 16:07:42 Myriachan wrote:

> > I think that integer overflow and signed shifts should be
> > implementation-defined instead of undefined.
>
> This pessimises the following code:
>
>         if (i + 1 > i)
>
> For a given integer i. Now the compiler can assume that it doesn't
> overflow, so
> the check can be eliminated. With your suggestion, the compiler can't
> assume
> that, so it will need to execute the check.
>
> The example above is contrived, but it can happen after the optimiser
> inlines
> a lot of code. I know that because GCC has a warning for exactly that case
> and
> it triggers in Qt code:
>
> qstring.h:991:7: warning: assuming signed overflow does not occur when
> assuming
> that (X - c) > X is always false [-Wstrict-overflow]
>      { if (i >= s.size()) s.expand(i); else s.detach();
>        ^
>
> It happens when you do:
>
>         container.append(data)
>>
>> ;
>>         container.append(more_data);
>>
>> because the append() functions will do:
>>
>>         if (size() + data.length() > capacity())
>>                 resize(size() + data.length());
>>
>> After the first appending, probably size() == capacity(). If the signed
>> integer
>> overflow is undefined, the compiler can optimise the test for overflow
>> away and
>> simply call resize().
>>
>
I have several points about this:

1. Why is a container using a signed integer for size?
2. I argue that these cases are a minor optimization.
3. The container is unsafe, anyway: what happens when you actually do
overflow it?  Even if ptrdiff_t is the signed type, platforms exist where
more data can exist than ptrdiff_t or size_t can represent.

I feel that the optimizations reduce CPU time by less than the CPU time
consumed by a worm courtesy of the Mafia that was able to get in because of
a programmer not realizing that the compiler is going to delete a security
check.

As another reason to deprecate the undefinedness, there is the problem that
the integer promotion rules can result in signed overflow even when you're
working with unsigned integers.  This is often unexpected and
platform-specific, making it quite dangerous.  I usually give this example
when talking about signed overflow:

http://pastebin.com/nLzRGHr0

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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_715_470230465.1418414926646
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, December 12, 2014 8:08:52 AM UTC-8, Olaf van de=
r Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; It seems inc=
redibly fragile to me that all of this is dependent upon whether i is int o=
r unsigned. &nbsp;If we were designing a language with a clean sheet of pap=
er today, there is absolutely no way anyone would agree to such a schism.
<br>
<br>Why not? :p
<br>Would such a language allow or disallow overflow? What do D, Java and C=
# do?
<br>How often is signed overflow a bug and how often is it not?
<br>
<br></blockquote><div><br>D, Java and C# all wrap mod (1&lt;&lt;bitsize), a=
nd assume a two's-complement implementation.&nbsp; The very recent language=
 Swift has two sets of arithmetic operators: one set traps on overflow, and=
 the other set wraps (even though Objective-C considers it undefined instea=
d).<br><br>On Thursday, December 11, 2014 8:18:24 PM UTC-8, Thiago Macieira=
 wrote:On Thursday 11 December 2014 16:07:42 Myriachan wrote:
<br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid =
rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">&gt; I think =
that integer overflow and signed shifts should be
<br>&gt; implementation-defined instead of undefined.
<br>
<br>This pessimises the following code:
<br>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if (i + 1 &gt; i)
<br>
<br>For a given integer i. Now the compiler can assume that it doesn't over=
flow, so=20
<br>the check can be eliminated. With your suggestion, the compiler can't a=
ssume=20
<br>that, so it will need to execute the check.
<br>
<br>The example above is contrived, but it can happen after the optimiser i=
nlines=20
<br>a lot of code. I know that because GCC has a warning for exactly that c=
ase and=20
<br>it triggers in Qt code:
<br>
<br>qstring.h:991:7: warning: assuming signed overflow does not occur when =
assuming=20
<br>that (X - c) &gt; X is always false [-Wstrict-overflow]
<br>&nbsp; &nbsp; &nbsp;{ if (i &gt;=3D s.size()) s.expand(i); else s.detac=
h();
<br>&nbsp; &nbsp; &nbsp; &nbsp;^
<br>
<br>It happens when you do:
<br>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;container.append(data)<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><wbr>;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;container.append(more_<=
wbr>data);
<br>
<br>because the append() functions will do:
<br>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if (size() + data.lengt=
h() &gt; capacity())
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;resize(size() + data.length());
<br>
<br>After the first appending, probably size() =3D=3D capacity(). If the si=
gned integer=20
<br>overflow is undefined, the compiler can optimise the test for overflow =
away and=20
<br>simply call resize().
<br>
</blockquote></blockquote><br>I have several points about this:<br><br>1. W=
hy is a container using a signed integer for size?<br>2. I argue that these=
 cases are a minor optimization.<br>3. The container is unsafe, anyway: wha=
t happens when you actually do overflow it?&nbsp; Even if <span style=3D"fo=
nt-family: courier new,monospace;">ptrdiff_t</span> is the signed type, pla=
tforms exist where more data can exist than <span style=3D"font-family: cou=
rier new,monospace;">ptrdiff_t</span> or <span style=3D"font-family: courie=
r new,monospace;">size_t</span> can represent.<br><br>I feel that the optim=
izations reduce CPU time by less than the CPU time consumed by a worm court=
esy of the Mafia that was able to get in because of a programmer not realiz=
ing that the compiler is going to delete a security check.<br><br>As anothe=
r reason to deprecate the undefinedness, there is the problem that the inte=
ger promotion rules can result in signed overflow even when you're working =
with unsigned integers.&nbsp; This is often unexpected and platform-specifi=
c, making it quite dangerous.&nbsp; I usually give this example when talkin=
g about signed overflow:<br><br>http://pastebin.com/nLzRGHr0<br><br>Melissa=
<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_715_470230465.1418414926646--
------=_Part_714_1197007023.1418414926646--

.

------=_Part_942_1322086740.1418422685957
Content-Type: multipart/alternative;
 boundary="----=_Part_943_298543671.1418422685957"

------=_Part_943_298543671.1418422685957
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Quoting C++ ISO standard (latest draft) from 5. Expressions:

4 If during the evaluation of an expression, the result is not=20
> mathematically de=EF=AC=81ned or not in the range of representable values=
 for its=20
> type, the behavior is unde=EF=AC=81ned. [Note: most existing implementati=
ons of C++=20
> ignore integer over=EF=AC=82ows. Treatment of division by zero, forming a=
 remainder=20
> using a zero divisor, and all =EF=AC=82oating point exceptions vary among=
 machines,=20
> and is usually adjustable by a library function. =E2=80=94end note]=20


Why the behavior should be unde=EF=AC=81ned instead of being well-known lik=
e for=20
example throwing some kind of exceptions. This is a way more logical - so=
=20
platform-independent safe code could be written in C++. About the OP post,=
=20
it is already implementation-defined (it's the same as undefined).

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_943_298543671.1418422685957
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Quoting C++ ISO standard (latest draft) from 5. Expression=
s:<div><br></div><div><blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 2=
04); border-left-style: solid; padding-left: 1ex;">4 If during the evaluati=
on of an expression, the result is not mathematically de=EF=AC=81ned or not=
 in the range of representable values for its type, the behavior is unde=EF=
=AC=81ned. [Note: most existing implementations of C++ ignore integer over=
=EF=AC=82ows. Treatment of division by zero, forming a remainder using a ze=
ro divisor, and all =EF=AC=82oating point exceptions vary among machines, a=
nd is usually adjustable by a library function. =E2=80=94end note]&nbsp;</b=
lockquote><div><br></div><div>Why the behavior should be unde=EF=AC=81ned&n=
bsp;instead of being well-known like for example throwing some kind of exce=
ptions. This is a way more logical - so platform-independent safe code coul=
d be written in C++. About the OP post, it is already implementation-define=
d (it's the same as undefined).</div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_943_298543671.1418422685957--
------=_Part_942_1322086740.1418422685957--

.

On Friday 12 December 2014 14:18:05 sasho648 wrote:
> Quoting C++ ISO standard (latest draft) from 5. Expressions:
>=20
> 4 If during the evaluation of an expression, the result is not
>=20
> > mathematically de=EF=AC=81ned or not in the range of representable valu=
es for its
> > type, the behavior is unde=EF=AC=81ned. [Note: most existing implementa=
tions of
> > C++
> > ignore integer over=EF=AC=82ows. Treatment of division by zero, forming=
 a
> > remainder
> > using a zero divisor, and all =EF=AC=82oating point exceptions vary amo=
ng
> > machines,
> > and is usually adjustable by a library function. =E2=80=94end note]
>=20
> Why the behavior should be unde=EF=AC=81ned instead of being well-known l=
ike for
> example throwing some kind of exceptions. This is a way more logical - so
> platform-independent safe code could be written in C++. About the OP post=
,
> it is already implementation-defined (it's the same as undefined).

It is really undefined, see my email where I explain a situation that the=
=20
optimiser relies on it being undefined. My email also explains why making i=
t=20
defined (with any behaviour) would introduce code where today none is requi=
red.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_771_1292316040.1418425022989
Content-Type: multipart/alternative;
 boundary="----=_Part_772_306078522.1418425022990"

------=_Part_772_306078522.1418425022990
Content-Type: text/plain; charset=UTF-8

What about adding a new modifier to integer types instead of changing
current behavior.  When you don't want overflow to occur you can use a
saturated type modifier.

// Instead of these
int x;
unsigned int y;
// We use these C++ types with a modifier
saturated int x;
saturated unsigned int y;


The exact keyword and exact method of trapping/capturing overflow on
operations could be debated but it could be made C compatible as well as
C++...

But this could also be done with a separate class as well....


// saturated template class
template <typename _T>
class saturated
{
private:
    bool _overflow;
public:
    //...
    bool overflow() { return _overflow; };
    _T & operation_add(_T &a, _T &b); // Returns true on overflow...
};

// Or...
bool saturated_overflow = false;  // Could make this a global so there is
no added size... Make it a class to capture/restore state between blocks of
code...

// Global version...
template <typename _T>
class saturated
{
private:
    _T _value;
public:
    //...
    // All operation functions capture overflow status and set the global
flag.
};

Well, that leaves a lot to the imagination I guess... Exact implementation
could be debatable.


--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_772_306078522.1418425022990
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">What about adding a new modifier to integer types instead =
of changing current behavior. &nbsp;When you don't want overflow to occur y=
ou can use a saturated type modifier.<div><br></div><div class=3D"prettypri=
nt" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; b=
ackground-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">// Instead of these</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">unsigned</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> y</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #800;" class=3D"styled-by=
-prettify">// We use these C++ types with a modifier</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>saturated </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>saturated </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">unsigned</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> y</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span></div></code></div><div><br></div><div><br></div><div>The exact k=
eyword and exact method of trapping/capturing overflow on operations could =
be debated but it could be made C compatible as well as C++... &nbsp;</div>=
<div><br></div><div>But this could also be done with a separate class as we=
ll....</div><div><br></div><div class=3D"prettyprint" style=3D"border: 1px =
solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250,=
 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">// saturated template class=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">template</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> _T</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> saturated<br></span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">private</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>bool</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> _ove=
rflow</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">public</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">//...</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> overflow</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"col=
or: #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"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> _overflow</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbs=
p; _T </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> operatio=
n_add</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">_T </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">a</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> _T </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">b</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// Ret=
urns true on overflow...</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
 Or...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">bool</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> saturated_overf=
low </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">false</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> &nbsp;</span><span style=3D"color: =
#800;" class=3D"styled-by-prettify">// Could make this a global so there is=
 no added size... Make it a class to capture/restore state between blocks o=
f code</span><span style=3D"color: #800;" class=3D"styled-by-prettify">...<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></s=
pan><span style=3D"color: #800;" class=3D"styled-by-prettify">// Global ver=
sion...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #008;" class=3D"styled-by-prettify">template<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> _T</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> saturated<br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">private</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>&nbsp; &nbsp; _T _value</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">public</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp;=
 &nbsp; </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
....</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; &nbsp; </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>// All operation functions capture overflow status and set the global flag=
..</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span></div></=
code></div><div>Well, that leaves a lot to the imagination I guess... Exact=
 implementation could be debatable.</div><div><br></div><div><br></div></di=
v>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_772_306078522.1418425022990--
------=_Part_771_1292316040.1418425022989--

.

On Dec 12, 2014, at 5:18 PM, sasho648 <sasho648@mail.bg> wrote:

> About the OP post, it is already implementation-defined (it's the same as=
 undefined).

This is a common and deadly (possibly literally) misunderstanding, which Th=
iago alludes to here:

On Dec 11, 2014, at 11:18 PM, Thiago Macieira <thiago@macieira.org> wrote:

> This pessimises the following code:
>=20
>  if (i + 1 > i)
>=20
> For a given integer i. Now the compiler can assume that it doesn't overfl=
ow, so=20
> the check can be eliminated. With your suggestion, the compiler can't ass=
ume=20
> that, so it will need to execute the check.

This is often purposefully coded more like:

       if (i + 1 < i)
       {
           // oops, we=E2=80=99ve overflowed!
           // deal with it!
           // ...
       }

If i has unsigned type, this is well-formed and portable code.  unsigned ar=
ithmetic is required to be modulo 2^n (wraps on overflow).

Today the standard says that if i has signed type, the behavior is undefine=
d.  If it were instead implementation defined, an implementation would like=
ly define it to do whatever the hardware does.  On 2=E2=80=99s complement m=
achines, it wraps, and gives the expected behavior.  And 2=E2=80=99s comple=
ment architecture is ubiquitous enough that this code is effectively "suffi=
ciently portable."

However since the compiler says that this has undefined behavior, this give=
s permission for the compiler to reason:

   * undefined behavior can never happen.
   * So i + 1 can never be less than i.
   * So I can rewrite this snippet as:

       if (false)
       {
           // oops, we=E2=80=99ve overflowed!
           // deal with it!
           // ...
       }

   *  And subsequently further optimize it as:

      <this line intentionally left blank>

I.e. There are actual cases in the wild where because the committee classif=
ies signed integral overflow as undefined behavior, real compilers (like gc=
c and clang) will actually *remove* code from the program that would otherw=
ise catch an overflow condition.  This removal may happen only when optimiz=
ations are set high enough.  Or perhaps only when you upgrade to compiler v=
ersion number next.

There is likely to eventually be a deadly and/or costly accident caused by =
this standards bug.  I hope not.  But the odds are not nearly low enough, a=
nd growing with time.

There are two camps in this debate:

One camp says:

*  We need the performance!  We can educate our way out of this.

The other camp says:

*  Performance is very important.  It is second to one.  Correctness is mor=
e important.  The current system is so error prone we can not reliably educ=
ate our way out of it.

Disclaimer: I am firmly in the second camp.

Howard

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_1067_501178893.1418426370243
Content-Type: multipart/alternative;
 boundary="----=_Part_1068_882791117.1418426370243"

------=_Part_1068_882791117.1418426370243
Content-Type: text/plain; charset=UTF-8

Me too. I know that such checks would require more code (at least in x86)
but we are heading into the future where perhaps better ISA will be created
which would treat integer overflow as exception and no additional code
would need to be added. Better accurate results than performance with wrong
ones.

About the difference between undefined-behavior and implementation defined
one. The implementation can decide not to define the behavior and thus
count it as an undefined-one, can't 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1068_882791117.1418426370243
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Me too. I know that such checks would require more code (a=
t least in x86) but we are heading into the future where perhaps better ISA=
 will be created which would treat integer overflow as exception and no add=
itional code would need to be added. Better accurate results than performan=
ce with wrong ones.<div><br></div><div>About the difference between undefin=
ed-behavior and implementation defined one. The implementation can decide n=
ot to define the behavior and thus count it as an undefined-one, can't it?<=
/div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1068_882791117.1418426370243--
------=_Part_1067_501178893.1418426370243--

.

--001a1132e75ac42693050a0d21fb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 12 December 2014 at 17:01, Howard Hinnant <howard.hinnant@gmail.com>
wrote:

> Today the standard says that if i has signed type, the behavior is
> undefined.  If it were instead implementation defined, an implementation
> would likely define it to do whatever the hardware does.  On 2=E2=80=99s =
complement
> machines, it wraps, and gives the expected behavior.  And 2=E2=80=99s com=
plement
> architecture is ubiquitous enough that this code is effectively
> "sufficiently portable."
>

But sufficiently portable !=3D less buggy.


> There is likely to eventually be a deadly and/or costly accident caused b=
y
> this standards bug.  I hope not.  But the odds are not nearly low enough,
> and growing with time.
>
> There are two camps in this debate:
>
> One camp says:
>
> *  We need the performance!  We can educate our way out of this.
>
> The other camp says:
>
> *  Performance is very important.  It is second to one.  Correctness is
> more important.  The current system is so error prone we can not reliably
> educate our way out of it.
>

Like Howard, I'm in the second camp as well.

However, I don't see how a positive integer wrapping into a negative number
avoids the deadly and/or costly accident.  While neither option is ideal,
I'd rather have sanitizers that can check for this sort of thing than have
have to forego them because someone might be relying on that wrapping
behavior.


C arithmetic is deceptively hard.  If we really want safety, we either (a)
have to revamp all the rules or (b) propose a safe_int set of classes for
the standard.

FYI: one discussion I've had on just how tricky C arithmetic is can be
found at <https://plus.google.com/u/0/+JonKalb/posts/DfMWdBKHHvJ>.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a1132e75ac42693050a0d21fb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 12 December 2014 at 17:01, Howard Hinnant <span dir=3D"=
ltr">&lt;<a href=3D"mailto:howard.hinnant@gmail.com" target=3D"_blank">howa=
rd.hinnant@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;padding-left:1ex">Today the standard says that if i=
 has signed type, the behavior is undefined.=C2=A0 If it were instead imple=
mentation defined, an implementation would likely define it to do whatever =
the hardware does.=C2=A0 On 2=E2=80=99s complement machines, it wraps, and =
gives the expected behavior.=C2=A0 And 2=E2=80=99s complement architecture =
is ubiquitous enough that this code is effectively &quot;sufficiently porta=
ble.&quot;<br></blockquote><div><br></div><div>But sufficiently portable !=
=3D less buggy.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex">There is likely to e=
ventually be a deadly and/or costly accident caused by this standards bug.=
=C2=A0 I hope not.=C2=A0 But the odds are not nearly low enough, and growin=
g with time.<br>
<br>
There are two camps in this debate:<br>
<br>
One camp says:<br>
<br>
*=C2=A0 We need the performance!=C2=A0 We can educate our way out of this.<=
br>
<br>
The other camp says:<br>
<br>
*=C2=A0 Performance is very important.=C2=A0 It is second to one.=C2=A0 Cor=
rectness is more important.=C2=A0 The current system is so error prone we c=
an not reliably educate our way out of it.<br></blockquote><div><br></div><=
div>Like Howard, I&#39;m in the second camp as well.=C2=A0</div><div><br></=
div><div>However, I don&#39;t see how a positive integer wrapping into a ne=
gative number avoids the deadly and/or costly accident.=C2=A0 While neither=
 option is ideal, I&#39;d rather have sanitizers that can check for this so=
rt of thing than have have to forego them because someone might be relying =
on that wrapping behavior.</div><div><br></div><div><br></div><div>C arithm=
etic is deceptively hard.=C2=A0 If we really want safety, we either (a) hav=
e to revamp all the rules or (b) propose a safe_int set of classes for the =
standard.</div><div><br></div><div>FYI: one discussion I&#39;ve had on just=
 how tricky C arithmetic is can be found at &lt;<a href=3D"https://plus.goo=
gle.com/u/0/+JonKalb/posts/DfMWdBKHHvJ" target=3D"_blank">https://plus.goog=
le.com/u/0/+JonKalb/posts/DfMWdBKHHvJ</a>&gt;.</div></div>-- <br><div>=C2=
=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@evi=
loverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 <a hr=
ef=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=3D"_blank">(8=
47) 691-1404</a></div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1132e75ac42693050a0d21fb--

.

On Friday 12 December 2014 15:19:30 sasho648 wrote:
> Me too. I know that such checks would require more code (at least in x86)
> but we are heading into the future where perhaps better ISA will be created
> which would treat integer overflow as exception and no additional code
> would need to be added. Better accurate results than performance with wrong
> ones.

So let's wait for those machines. Maybe we can discuss this again in 2030.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

My bottom line is that the compiler should not be able to remove *your* cod=
e from *your* program unless it can truly do so as an optimization.

An optimization is a transform that has no visible side effects other than =
performance.

An optimization *is not* a transform that has side effects for which some c=
ommittee said:  you are not allowed to look at these side effects!

When compilers started doing the latter, assembly coding started looking sa=
fer again.  Assemblers really are not allowed to generate machine language =
different from what your assembly dictates.  C and C++ compilers are curren=
tly allowed to generate code different from what your C and C++ code dictat=
es (when there is potential undefined behavior involved).

Howard

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 13 December 2014 at 01:29, Howard Hinnant <howard.hinnant@gmail.com> wrote:
> My bottom line is that the compiler should not be able to remove *your* code from *your* program unless it can truly do so as an optimization.
>
> An optimization is a transform that has no visible side effects other than performance.
>
> An optimization *is not* a transform that has side effects for which some committee said:  you are not allowed to look at these side effects!


Strongly agreed. I expect some optimizer-authors might not agree, but
I think we should
be stricter about such optimizations. I believe there are many cases
where removal-optimizations
can be catastrophically worse than running slightly-incorrect code.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

So a compiler shouldn't perform RVO for a return value when it cannot
see the dtor???

On 12/12/14, Howard Hinnant <howard.hinnant@gmail.com> wrote:
> My bottom line is that the compiler should not be able to remove *your* code
> from *your* program unless it can truly do so as an optimization.
>
> An optimization is a transform that has no visible side effects other than
> performance.
>
> An optimization *is not* a transform that has side effects for which some
> committee said:  you are not allowed to look at these side effects!
>
> When compilers started doing the latter, assembly coding started looking
> safer again.  Assemblers really are not allowed to generate machine language
> different from what your assembly dictates.  C and C++ compilers are
> currently allowed to generate code different from what your C and C++ code
> dictates (when there is potential undefined behavior involved).
>
> Howard
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a11c1c3a4305da8050a0dadf1
Content-Type: text/plain; charset=UTF-8

On 12 December 2014 at 17:29, Howard Hinnant <howard.hinnant@gmail.com>
wrote:

> An optimization is a transform that has no visible side effects other than
> performance.
>

So, would you support an (extreme) example where ints were effectively
replaced with atomic<int>s (unless the compiler can deduce that a given
variable can only be seen on one thread)?  After all, most users expect
that writes to any fundamental data type are atomic and reflected on all
threads.

As for the signed int wrapping bug, places I have worked have been burned
by it at least two times.  It was UB according to the standard, it wrapped
in practice, and in both cases it was buggy.

Other than sanitizers, I see no practical difference between UB and defined
behavior with insane error-prone semantics.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c1c3a4305da8050a0dadf1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 12 December 2014 at 17:29, Howard Hinnant <span dir=3D"=
ltr">&lt;<a href=3D"mailto:howard.hinnant@gmail.com" target=3D"_blank">howa=
rd.hinnant@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">An optimization is =
a transform that has no visible side effects other than performance.<br></b=
lockquote><div><br></div><div>So, would you support an (extreme) example wh=
ere ints were effectively replaced with atomic&lt;int&gt;s (unless the comp=
iler can deduce that a given variable can only be seen on one thread)?=C2=
=A0 After all, most users expect that writes to any fundamental data type a=
re atomic and reflected on all threads.</div><div><br></div><div>As for the=
 signed int wrapping bug, places I have worked have been burned by it at le=
ast two times.=C2=A0 It was UB according to the standard, it wrapped in pra=
ctice, and in both cases it was buggy.</div><div><br></div><div>Other than =
sanitizers, I see no practical difference between UB and defined behavior w=
ith insane error-prone semantics.</div><div>--=C2=A0<br></div></div><div cl=
ass=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:=
<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverl=
ord.com</a>&gt;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c1c3a4305da8050a0dadf1--

.

On Friday 12 December 2014 18:29:13 Howard Hinnant wrote:
> My bottom line is that the compiler should not be able to remove *your* code
> from *your* program unless it can truly do so as an optimization.

Except that removing the code might be exactly what was intended. See the
example I gave: I know my code doesn't overflow, therefore I want the compiler
to obey me and not write any extra checks to emit code that will never get
run.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Perhaps the language would be better if we made overflow on unsigned integral types undefined behavior too?  At least then we would not get wildly different run time behavior between:

    if (i + 1 < i)  // translates to if (false)

and

    if (u + 1 < u)  // translates to if (u + 1 < u)

Howard

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Fri, Dec 12, 2014 at 9:08 PM, Myriachan <myriachan@gmail.com> wrote:
>> How often is signed overflow a bug and how often is it not?
>>
>
> D, Java and C# all wrap mod (1<<bitsize), and assume a two's-complement
> implementation.  The very recent language Swift has two sets of arithmetic
> operators: one set traps on overflow, and the other set wraps (even though
> Objective-C considers it undefined instead).

You forgot the most important question: "How often is signed overflow
a bug and how often is it not?"

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 13 December 2014 at 02:28, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Fri, Dec 12, 2014 at 9:08 PM, Myriachan <myriachan@gmail.com> wrote:
>>> How often is signed overflow a bug and how often is it not?
>>>
>>
>> D, Java and C# all wrap mod (1<<bitsize), and assume a two's-complement
>> implementation.  The very recent language Swift has two sets of arithmetic
>> operators: one set traps on overflow, and the other set wraps (even though
>> Objective-C considers it undefined instead).
>
> You forgot the most important question: "How often is signed overflow
> a bug and how often is it not?"


First of all, I don't know. Some follow-up questions:
1) is code removal under the auspices of undefined behavior a
reasonable response
to the potential bugs?
2) on what hardware does a signed integer overflow actually 'launch a
missile'? It
seems to me that an implementation doing these optimizations can certainly turn
a 'non-launch' into a 'launch'.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--Apple-Mail=_3C944F51-7B30-442F-ABD9-77F3F73A8E49
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2014=E2=80=9312=E2=80=9313, at 7:01 AM, Howard Hinnant <howard.hinnant=
@gmail.com> wrote:
>=20
> The other camp says:
>=20
> *  Performance is very important.  It is second to one.  Correctness is m=
ore important.  The current system is so error prone we can not reliably ed=
ucate our way out of it.
>=20
> Disclaimer: I am firmly in the second camp.

If you make overflow well-formed, then the tools can=E2=80=99t flag it and =
the user will never have a correct program.

Assigning meaning to nonsense programs is a poor way to obtain =E2=80=9Ccor=
rectness.=E2=80=9D

Implementations need finer tuning to flag issues like what Myriachan descri=
bes, but the question of what programs are fundamentally meaningful or mean=
ingless already has a reasonable resolution.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_3C944F51-7B30-442F-ABD9-77F3F73A8E49
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2014=E2=80=9312=
=E2=80=9313, at 7:01 AM, Howard Hinnant &lt;<a href=3D"mailto:howard.hinnan=
t@gmail.com" class=3D"">howard.hinnant@gmail.com</a>&gt; wrote:</div><br cl=
ass=3D"Apple-interchange-newline"><div class=3D""><span style=3D"font-famil=
y: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; fo=
nt-weight: normal; letter-spacing: normal; line-height: normal; orphans: au=
to; text-align: start; text-indent: 0px; text-transform: none; white-space:=
 normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; f=
loat: none; display: inline !important;" class=3D"">The other camp says:</s=
pan><br style=3D"font-family: Helvetica; font-size: 12px; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: auto; text-align: start; text-indent: 0px; text-tr=
ansform: none; white-space: normal; widows: auto; word-spacing: 0px; -webki=
t-text-stroke-width: 0px;" class=3D""><br style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: nor=
mal; letter-spacing: normal; line-height: normal; orphans: auto; text-align=
: start; text-indent: 0px; text-transform: none; white-space: normal; widow=
s: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><sp=
an style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fo=
nt-variant: normal; font-weight: normal; letter-spacing: normal; line-heigh=
t: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfo=
rm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tex=
t-stroke-width: 0px; float: none; display: inline !important;" class=3D"">*=
 &nbsp;Performance is very important. &nbsp;It is second to one. &nbsp;Corr=
ectness is more important. &nbsp;The current system is so error prone we ca=
n not reliably educate our way out of it.</span><br style=3D"font-family: H=
elvetica; font-size: 12px; font-style: normal; font-variant: normal; font-w=
eight: normal; letter-spacing: normal; line-height: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: nor=
mal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" clas=
s=3D""><br style=3D"font-family: Helvetica; font-size: 12px; font-style: no=
rmal; font-variant: normal; font-weight: normal; letter-spacing: normal; li=
ne-height: normal; orphans: auto; text-align: start; text-indent: 0px; text=
-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -we=
bkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: Helvet=
ica; font-size: 12px; font-style: normal; font-variant: normal; font-weight=
: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-=
align: start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: non=
e; display: inline !important;" class=3D"">Disclaimer: I am firmly in the s=
econd camp.</span><br style=3D"font-family: Helvetica; font-size: 12px; fon=
t-style: normal; font-variant: normal; font-weight: normal; letter-spacing:=
 normal; line-height: normal; orphans: auto; text-align: start; text-indent=
: 0px; text-transform: none; white-space: normal; widows: auto; word-spacin=
g: 0px; -webkit-text-stroke-width: 0px;" class=3D""></div></blockquote></di=
v><br class=3D""><div class=3D"">If you make overflow well-formed, then the=
 tools can=E2=80=99t flag it and the user will <i class=3D"">never</i> have=
 a correct program.</div><div class=3D""><br class=3D""></div><div class=3D=
"">Assigning meaning to nonsense programs is a poor way to obtain =E2=80=9C=
correctness.=E2=80=9D</div><div class=3D""><br class=3D""></div><div class=
=3D"">Implementations need finer tuning to flag issues like what Myriachan =
describes, but the question of what programs are fundamentally meaningful o=
r meaningless already has a reasonable resolution.</div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_3C944F51-7B30-442F-ABD9-77F3F73A8E49--

.

On Dec 12, 2014, at 9:04 PM, David Krauss <potswa@gmail.com> wrote:

> If you make overflow well-formed, then the tools can=E2=80=99t flag it an=
d the user will never have a correct program.
>=20
> Assigning meaning to nonsense programs is a poor way to obtain =E2=80=9Cc=
orrectness.=E2=80=9D

Nowhere has anyone suggested making signed overflow well-formed.  The propo=
sal Melissa made at the beginning of this thread is to make it implementati=
on defined.  If I have implied otherwise, I apologize for that.

Howard

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 13 December 2014 at 04:29, Howard Hinnant <howard.hinnant@gmail.com> wro=
te:
> On Dec 12, 2014, at 9:04 PM, David Krauss <potswa@gmail.com> wrote:
>
>> If you make overflow well-formed, then the tools can=E2=80=99t flag it a=
nd the user will never have a correct program.
>>
>> Assigning meaning to nonsense programs is a poor way to obtain =E2=80=9C=
correctness.=E2=80=9D
>
> Nowhere has anyone suggested making signed overflow well-formed.  The pro=
posal Melissa made at the beginning of this thread is to make it implementa=
tion defined.  If I have implied otherwise, I apologize for that.

Even so, there's a vast difference between "tools can't flag it" and
"tools that promise they
will not flag it if it's not UB".

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

I'm not following this thread so sorry if I'm saying something unrelated.
But, I think that ensuring that int overflow causes wrap-around is useful t=
o implement wrap-around arithmetic (which is useful). Even more useful woul=
d be to be able to set the behavior (wrap-around or saturation) via some fe=
nv.h-like facility, but that could be costly to implement in some platforms=
..
-----Original Message-----
From: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 13 Dec 2014 13:55:35=20
To: <std-proposals@isocpp.org>
Reply-To: std-proposals@isocpp.org
Subject: Re: [std-proposals] Re: Make integer overflow implementation-defin=
ed

On 13 December 2014 at 04:29, Howard Hinnant <howard.hinnant@gmail.com> wro=
te:
> On Dec 12, 2014, at 9:04 PM, David Krauss <potswa@gmail.com> wrote:
>
>> If you make overflow well-formed, then the tools can=E2=80=99t flag it a=
nd the user will never have a correct program.
>>
>> Assigning meaning to nonsense programs is a poor way to obtain =E2=80=9C=
correctness.=E2=80=9D
>
> Nowhere has anyone suggested making signed overflow well-formed.  The pro=
posal Melissa made at the beginning of this thread is to make it implementa=
tion defined.  If I have implied otherwise, I apologize for that.

Even so, there's a vast difference between "tools can't flag it" and
"tools that promise they
will not flag it if it's not UB".

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_1486_899979593.1418491508069
Content-Type: multipart/alternative;
 boundary="----=_Part_1487_1229693730.1418491508070"

------=_Part_1487_1229693730.1418491508070
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Or simply add function that could do it to standard, e.g.:
int mul_w(int i, int j); //warp around
int mul_s(int i, int j); //saturate
int mul_e(int i, int j); //throw exception / signal alternative return bool=
=20
and value is return in ref arg
This could be next used to create "warp int" class by users.


On Saturday, December 13, 2014 5:42:59 PM UTC+1, dgutson wrote:
>
> I'm not following this thread so sorry if I'm saying something unrelated.=
=20
> But, I think that ensuring that int overflow causes wrap-around is useful=
=20
> to implement wrap-around arithmetic (which is useful). Even more useful=
=20
> would be to be able to set the behavior (wrap-around or saturation) via=
=20
> some fenv.h-like facility, but that could be costly to implement in some=
=20
> platforms.=20
> -----Original Message-----=20
> From: Ville Voutilainen <ville.vo...@gmail.com <javascript:>>=20
> Date: Sat, 13 Dec 2014 13:55:35=20
> To: <std-pr...@isocpp.org <javascript:>>=20
> Reply-To: std-pr...@isocpp.org <javascript:>=20
> Subject: Re: [std-proposals] Re: Make integer overflow=20
> implementation-defined=20
>
> On 13 December 2014 at 04:29, Howard Hinnant <howard....@gmail.com=20
> <javascript:>> wrote:=20
> > On Dec 12, 2014, at 9:04 PM, David Krauss <pot...@gmail.com=20
> <javascript:>> wrote:=20
> >=20
> >> If you make overflow well-formed, then the tools can=E2=80=99t flag it=
 and the=20
> user will never have a correct program.=20
> >>=20
> >> Assigning meaning to nonsense programs is a poor way to obtain=20
> =E2=80=9Ccorrectness.=E2=80=9D=20
> >=20
> > Nowhere has anyone suggested making signed overflow well-formed.  The=
=20
> proposal Melissa made at the beginning of this thread is to make it=20
> implementation defined.  If I have implied otherwise, I apologize for tha=
t.=20
>
> Even so, there's a vast difference between "tools can't flag it" and=20
> "tools that promise they=20
> will not flag it if it's not UB".=20
>
> --=20
>
> ---=20
> You received this message because you are subscribed to the Google Groups=
=20
> "ISO C++ Standard - Future Proposals" group.=20
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to std-proposal...@isocpp.org <javascript:>.=20
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.=
=20
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.=20
>

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_1487_1229693730.1418491508070
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Or simply add function that could do it to standard, e.g.:=
<br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250=
); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px=
; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpret=
typrint"><span style=3D"color: #008;" class=3D"styled-by-prettify">int</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> mul_w</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> i</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> j</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #800;" class=3D"styled-by-prettify">//warp around</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> mul_s</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> j</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">//saturate</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> mul_e</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> i</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> j</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;=
" class=3D"styled-by-prettify">//throw exception / signal alternative retur=
n bool and value is return in ref arg</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span></div></code></div>This could be next=
 used to create "warp int" class by users.<br><br><br>On Saturday, December=
 13, 2014 5:42:59 PM UTC+1, dgutson wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">I'm not following this thread so sorry if I'm saying something =
unrelated.
<br>But, I think that ensuring that int overflow causes wrap-around is usef=
ul to implement wrap-around arithmetic (which is useful). Even more useful =
would be to be able to set the behavior (wrap-around or saturation) via som=
e fenv.h-like facility, but that could be costly to implement in some platf=
orms.
<br>-----Original Message-----
<br>From: Ville Voutilainen &lt;<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"tl89nb6Y8GMJ" onmousedown=3D"this.href=3D'javascrip=
t:';return true;" onclick=3D"this.href=3D'javascript:';return true;">ville.=
vo...@gmail.com</a>&gt;
<br>Date: Sat, 13 Dec 2014 13:55:35=20
<br>To: &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"tl89nb6Y8GMJ" onmousedown=3D"this.href=3D'javascript:';return true;" on=
click=3D"this.href=3D'javascript:';return true;">std-pr...@isocpp.org</a>&g=
t;
<br>Reply-To: <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"tl89nb6Y8GMJ" onmousedown=3D"this.href=3D'javascript:';return true;" =
onclick=3D"this.href=3D'javascript:';return true;">std-pr...@isocpp.org</a>
<br>Subject: Re: [std-proposals] Re: Make integer overflow implementation-d=
efined
<br>
<br>On 13 December 2014 at 04:29, Howard Hinnant &lt;<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"tl89nb6Y8GMJ" onmousedown=3D"t=
his.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;return true;">howard....@gmail.com</a>&gt; wrote:
<br>&gt; On Dec 12, 2014, at 9:04 PM, David Krauss &lt;<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"tl89nb6Y8GMJ" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript=
:';return true;">pot...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt;&gt; If you make overflow well-formed, then the tools can=E2=80=99t=
 flag it and the user will never have a correct program.
<br>&gt;&gt;
<br>&gt;&gt; Assigning meaning to nonsense programs is a poor way to obtain=
 =E2=80=9Ccorrectness.=E2=80=9D
<br>&gt;
<br>&gt; Nowhere has anyone suggested making signed overflow well-formed. &=
nbsp;The proposal Melissa made at the beginning of this thread is to make i=
t implementation defined. &nbsp;If I have implied otherwise, I apologize fo=
r that.
<br>
<br>Even so, there's a vast difference between "tools can't flag it" and
<br>"tools that promise they
<br>will not flag it if it's not UB".
<br>
<br>--=20
<br>
<br>---=20
<br>You received this message because you are subscribed to the Google Grou=
ps "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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"tl89nb6Y8GMJ" onmousedown=3D"this.href=3D'javascript:';return true;" on=
click=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocp=
p.org</a>.
<br>To post to this group, send email to <a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"tl89nb6Y8GMJ" onmousedown=3D"this.href=3D'=
javascript:';return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-pr...@isocpp.org</a>.
<br>Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/gr=
oup/std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://gr=
oups.google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D=
"this.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';r=
eturn true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>prop=
osals/</a>.
<br></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1487_1229693730.1418491508070--
------=_Part_1486_899979593.1418491508069--

.

--part4971-boundary-1797827591-1760763810
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

My point is: what to do with existing int operations, rather than how to im=
plement new library features.
-----Original Message-----
From: inkwizytoryankes@gmail.com
Date: Sat, 13 Dec 2014 09:25:08=20
To: <std-proposals@isocpp.org>
Cc: <danielgutson@gmail.com>
Subject: Re: [std-proposals] Re: Make integer overflow
 implementation-defined

Or simply add function that could do it to standard, e.g.:
int mul_w(int i, int j); //warp around
int mul_s(int i, int j); //saturate
int mul_e(int i, int j); //throw exception / signal alternative return bool=
=20
and value is return in ref arg
This could be next used to create "warp int" class by users.


On Saturday, December 13, 2014 5:42:59 PM UTC+1, dgutson wrote:
>
> I'm not following this thread so sorry if I'm saying something unrelated.=
=20
> But, I think that ensuring that int overflow causes wrap-around is useful=
=20
> to implement wrap-around arithmetic (which is useful). Even more useful=
=20
> would be to be able to set the behavior (wrap-around or saturation) via=
=20
> some fenv.h-like facility, but that could be costly to implement in some=
=20
> platforms.=20
> -----Original Message-----=20
> From: Ville Voutilainen <ville.vo...@gmail.com <javascript:>>=20
> Date: Sat, 13 Dec 2014 13:55:35=20
> To: <std-pr...@isocpp.org <javascript:>>=20
> Reply-To: std-pr...@isocpp.org <javascript:>=20
> Subject: Re: [std-proposals] Re: Make integer overflow=20
> implementation-defined=20
>
> On 13 December 2014 at 04:29, Howard Hinnant <howard....@gmail.com=20
> <javascript:>> wrote:=20
> > On Dec 12, 2014, at 9:04 PM, David Krauss <pot...@gmail.com=20
> <javascript:>> wrote:=20
> >=20
> >> If you make overflow well-formed, then the tools can=E2=80=99t flag it=
 and the=20
> user will never have a correct program.=20
> >>=20
> >> Assigning meaning to nonsense programs is a poor way to obtain=20
> =E2=80=9Ccorrectness.=E2=80=9D=20
> >=20
> > Nowhere has anyone suggested making signed overflow well-formed.  The=
=20
> proposal Melissa made at the beginning of this thread is to make it=20
> implementation defined.  If I have implied otherwise, I apologize for tha=
t.=20
>
> Even so, there's a vast difference between "tools can't flag it" and=20
> "tools that promise they=20
> will not flag it if it's not UB".=20
>
> --=20
>
> ---=20
> You received this message because you are subscribed to the Google Groups=
=20
> "ISO C++ Standard - Future Proposals" group.=20
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to std-proposal...@isocpp.org <javascript:>.=20
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.=
=20
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.=20
>

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--part4971-boundary-1797827591-1760763810
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><html><head><=
meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type"></h=
ead><body>My point is: what to do with existing int operations, rather than=
 how to implement new library features.<hr/><div><b>From: </b> inkwizytorya=
nkes@gmail.com
</div><div><b>Date: </b>Sat, 13 Dec 2014 09:25:08 -0800 (PST)</div><div><b>=
To: </b>&lt;std-proposals@isocpp.org&gt;</div><div><b>Cc: </b>&lt;danielgut=
son@gmail.com&gt;</div><div><b>Subject: </b>Re: [std-proposals] Re: Make in=
teger overflow
 implementation-defined</div><div><br/></div><div dir=3D"ltr">Or simply add=
 function that could do it to standard, e.g.:<br><div class=3D"prettyprint"=
 style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187,=
 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> mul_w</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> i</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> j</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" cl=
ass=3D"styled-by-prettify">//warp around</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> mul_s</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> i<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> j</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"style=
d-by-prettify">//saturate</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> mul_e</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> i</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> j</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">/=
/throw exception / signal alternative return bool and value is return in re=
f arg</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span></div></code></div>This could be next used to create "warp int" class=
 by users.<br><br><br>On Saturday, December 13, 2014 5:42:59 PM UTC+1, dgut=
son wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I'm not following th=
is thread so sorry if I'm saying something unrelated.
<br>But, I think that ensuring that int overflow causes wrap-around is usef=
ul to implement wrap-around arithmetic (which is useful). Even more useful =
would be to be able to set the behavior (wrap-around or saturation) via som=
e fenv.h-like facility, but that could be costly to implement in some platf=
orms.
<br>-----Original Message-----
<br>From: Ville Voutilainen &lt;<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"tl89nb6Y8GMJ" onmousedown=3D"this.href=3D'javascrip=
t:';return true;" onclick=3D"this.href=3D'javascript:';return true;">ville.=
vo...@gmail.com</a>&gt;
<br>Date: Sat, 13 Dec 2014 13:55:35=20
<br>To: &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"tl89nb6Y8GMJ" onmousedown=3D"this.href=3D'javascript:';return true;" on=
click=3D"this.href=3D'javascript:';return true;">std-pr...@isocpp.org</a>&g=
t;
<br>Reply-To: <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"tl89nb6Y8GMJ" onmousedown=3D"this.href=3D'javascript:';return true;" =
onclick=3D"this.href=3D'javascript:';return true;">std-pr...@isocpp.org</a>
<br>Subject: Re: [std-proposals] Re: Make integer overflow implementation-d=
efined
<br>
<br>On 13 December 2014 at 04:29, Howard Hinnant &lt;<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"tl89nb6Y8GMJ" onmousedown=3D"t=
his.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;return true;">howard....@gmail.com</a>&gt; wrote:
<br>&gt; On Dec 12, 2014, at 9:04 PM, David Krauss &lt;<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"tl89nb6Y8GMJ" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript=
:';return true;">pot...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt;&gt; If you make overflow well-formed, then the tools can=E2=80=99t=
 flag it and the user will never have a correct program.
<br>&gt;&gt;
<br>&gt;&gt; Assigning meaning to nonsense programs is a poor way to obtain=
 =E2=80=9Ccorrectness.=E2=80=9D
<br>&gt;
<br>&gt; Nowhere has anyone suggested making signed overflow well-formed. &=
nbsp;The proposal Melissa made at the beginning of this thread is to make i=
t implementation defined. &nbsp;If I have implied otherwise, I apologize fo=
r that.
<br>
<br>Even so, there's a vast difference between "tools can't flag it" and
<br>"tools that promise they
<br>will not flag it if it's not UB".
<br>
<br>--=20
<br>
<br>---=20
<br>You received this message because you are subscribed to the Google Grou=
ps "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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"tl89nb6Y8GMJ" onmousedown=3D"this.href=3D'javascript:';return true;" on=
click=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocp=
p.org</a>.
<br>To post to this group, send email to <a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"tl89nb6Y8GMJ" onmousedown=3D"this.href=3D'=
javascript:';return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-pr...@isocpp.org</a>.
<br>Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/gr=
oup/std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://gr=
oups.google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D=
"this.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';r=
eturn true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>prop=
osals/</a>.
<br></blockquote></div>
</body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--part4971-boundary-1797827591-1760763810--


.

On Saturday 13 December 2014 17:34:39 Daniel Gutson wrote:
> My point is: what to do with existing int operations, rather than how to
> implement new library features.

Leave them as-is. Changing them 40 years after the fact could produce
unexpected effects, as would doing it without the C language doing the same.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Sure, I was just proposing alternatives to what the subject of the thread suggests (since I do not agree with it).
-----Original Message-----
From: Thiago Macieira <thiago@macieira.org>
Date: Sat, 13 Dec 2014 10:59:25
To: <std-proposals@isocpp.org>
Reply-To: std-proposals@isocpp.org
Subject: Re: [std-proposals] Re: Make integer overflow implementation-defined

On Saturday 13 December 2014 17:34:39 Daniel Gutson wrote:
> My point is: what to do with existing int operations, rather than how to
> implement new library features.

Leave them as-is. Changing them 40 years after the fact could produce
unexpected effects, as would doing it without the C language doing the same.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_492_1982094778.1418511446484
Content-Type: multipart/alternative;
 boundary="----=_Part_493_1300601582.1418511446484"

------=_Part_493_1300601582.1418511446484
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le samedi 13 d=C3=A9cembre 2014 00:25:45 UTC+1, Thiago Macieira a =C3=A9cri=
t :
>
> On Friday 12 December 2014 15:19:30 sasho648 wrote:=20
> > Me too. I know that such checks would require more code (at least in=20
> x86)=20
> > but we are heading into the future where perhaps better ISA will be=20
> created=20
> > which would treat integer overflow as exception and no additional code=
=20
> > would need to be added. Better accurate results than performance with=
=20
> wrong=20
> > ones.=20
>
> So let's wait for those machines. Maybe we can discuss this again in 2030=
..=20
>

No need to wait, MIPS has had a trapping add instruction forever; IIRC, C=
=20
and C++
compilers have never used it, even for int.

Yours,

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_493_1300601582.1418511446484
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Le samedi 13 d=C3=A9cembre 2014 00:25:45 UTC+1, Thiago Mac=
ieira a =C3=A9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fr=
iday 12 December 2014 15:19:30 sasho648 wrote:
<br>&gt; Me too. I know that such checks would require more code (at least =
in x86)=20
<br>&gt; but we are heading into the future where perhaps better ISA will b=
e created=20
<br>&gt; which would treat integer overflow as exception and no additional =
code
<br>&gt; would need to be added. Better accurate results than performance w=
ith wrong
<br>&gt; ones.
<br>
<br>So let's wait for those machines. Maybe we can discuss this again in 20=
30.
<br></blockquote><div><br>No need to wait, MIPS has had a trapping add inst=
ruction forever; IIRC, C and C++<br>compilers have never used it, even for =
int.<br><br>Yours,<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_493_1300601582.1418511446484--
------=_Part_492_1982094778.1418511446484--

.

------=_Part_1873_1075440593.1418669682803
Content-Type: multipart/alternative;
 boundary="----=_Part_1874_1707673399.1418669682803"

------=_Part_1874_1707673399.1418669682803
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, December 13, 2014 3:55:37 AM UTC-8, Ville Voutilainen wrote:
>
> On 13 December 2014 at 04:29, Howard Hinnant <howard....@gmail.com=20
> <javascript:>> wrote:=20
> > On Dec 12, 2014, at 9:04 PM, David Krauss <pot...@gmail.com=20
> <javascript:>> wrote:=20
> >=20
> >> If you make overflow well-formed, then the tools can=E2=80=99t flag it=
 and the=20
> user will never have a correct program.=20
> >>=20
> >> Assigning meaning to nonsense programs is a poor way to obtain=20
> =E2=80=9Ccorrectness.=E2=80=9D=20
> >=20
> > Nowhere has anyone suggested making signed overflow well-formed.  The=
=20
> proposal Melissa made at the beginning of this thread is to make it=20
> implementation defined.  If I have implied otherwise, I apologize for tha=
t.=20
>
> Even so, there's a vast difference between "tools can't flag it" and=20
> "tools that promise they=20
> will not flag it if it's not UB".=20
>

Yes.  Tools will exist regardless of whether the operations are=20
defined--there are sanitizers for C/C++ that will help you find unsigned=20
integer overflows, even though those are well-defined.

C# allows you to set overflows to trap instead of wrap, even though the=20
default is to wrap in a well-defined manner.  (C# also has keywords to=20
declare overflow as trapping or wrapping in certain blocks of code or=20
expressions.)  I don't know what tools Java has, but I know that it wraps=
=20
on overflow.

My view is more extreme than others, but I feel as though this is all about=
=20
making the behavior match programmer expectation.  So many of us were=20
taught about how two's complement works, and what happens on overflow. =20
This is especially true given how it works in other languages--they're=20
almost all "trap" or "wrap" semantics.  Even among professional C/C++=20
programmers, anecdotally it doesn't seem as though knowledge that signed=20
overflow is undefined is widespread.  I see frequently see code that takes=
=20
advantage of expectations that are actually false if strict enforcement is=
=20
in play.

Melissa

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_1874_1707673399.1418669682803
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, December 13, 2014 3:55:37 AM UTC-8, Ville Vou=
tilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 13 December =
2014 at 04:29, Howard Hinnant &lt;<a href=3D"javascript:" target=3D"_blank"=
 gdf-obfuscated-mailto=3D"4VhANLpRZEoJ" onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return true;">howa=
rd....@gmail.com</a>&gt; wrote:
<br>&gt; On Dec 12, 2014, at 9:04 PM, David Krauss &lt;<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"4VhANLpRZEoJ" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript=
:';return true;">pot...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt;&gt; If you make overflow well-formed, then the tools can=E2=80=99t=
 flag it and the user will never have a correct program.
<br>&gt;&gt;
<br>&gt;&gt; Assigning meaning to nonsense programs is a poor way to obtain=
 =E2=80=9Ccorrectness.=E2=80=9D
<br>&gt;
<br>&gt; Nowhere has anyone suggested making signed overflow well-formed. &=
nbsp;The proposal Melissa made at the beginning of this thread is to make i=
t implementation defined. &nbsp;If I have implied otherwise, I apologize fo=
r that.
<br>
<br>Even so, there's a vast difference between "tools can't flag it" and
<br>"tools that promise they
<br>will not flag it if it's not UB".
<br></blockquote><div><br>Yes.&nbsp; Tools will exist regardless of whether=
 the operations are defined--there are sanitizers for C/C++ that will help =
you find unsigned integer overflows, even though those are well-defined.<br=
><br>C# allows you to set overflows to trap instead of wrap, even though th=
e default is to wrap in a well-defined manner.&nbsp; (C# also has keywords =
to declare overflow as trapping or wrapping in certain blocks of code or ex=
pressions.)&nbsp; I don't know what tools Java has, but I know that it wrap=
s on overflow.<br><br>My view is more extreme than others, but I feel as th=
ough this is all about making the behavior match programmer expectation.&nb=
sp; So many of us were taught about how two's complement works, and what ha=
ppens on overflow.&nbsp; This is especially true given how it works in othe=
r languages--they're almost all "trap" or "wrap" semantics.&nbsp; Even amon=
g professional C/C++ programmers, anecdotally it doesn't seem as though kno=
wledge that signed overflow is undefined is widespread.&nbsp; I see frequen=
tly see code that takes advantage of expectations that are actually false i=
f strict enforcement is in play.<br><br>Melissa<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1874_1707673399.1418669682803--
------=_Part_1873_1075440593.1418669682803--

.

On 2014-12-15 19:54, Myriachan wrote:
> On Saturday, December 13, 2014 3:55:37 AM UTC-8, Ville Voutilainen wrote:
>
>     On 13 December 2014 at 04:29, Howard Hinnant <howard....@gmail.com
>     <javascript:>> wrote:
>      > On Dec 12, 2014, at 9:04 PM, David Krauss <pot...@gmail.com
>     <javascript:>> wrote:
>      >
>      >> If you make overflow well-formed, then the tools can=E2=80=99t fl=
ag it
>     and the user will never have a correct program.
>      >>
>      >> Assigning meaning to nonsense programs is a poor way to obtain
>     =E2=80=9Ccorrectness.=E2=80=9D
>      >
>      > Nowhere has anyone suggested making signed overflow well-formed.
>       The proposal Melissa made at the beginning of this thread is to
>     make it implementation defined.  If I have implied otherwise, I
>     apologize for that.
>
>     Even so, there's a vast difference between "tools can't flag it" and
>     "tools that promise they
>     will not flag it if it's not UB".
>
>
> Yes.  Tools will exist regardless of whether the operations are
> defined--there are sanitizers for C/C++ that will help you find unsigned
> integer overflows, even though those are well-defined.
>
> C# allows you to set overflows to trap instead of wrap, even though the
> default is to wrap in a well-defined manner.  (C# also has keywords to
> declare overflow as trapping or wrapping in certain blocks of code or
> expressions.)  I don't know what tools Java has, but I know that it
> wraps on overflow.
>
> My view is more extreme than others, but I feel as though this is all
> about making the behavior match programmer expectation.  So many of us
> were taught about how two's complement works, and what happens on
> overflow.  This is especially true given how it works in other
> languages--they're almost all "trap" or "wrap" semantics.  Even among
> professional C/C++ programmers, anecdotally it doesn't seem as though
> knowledge that signed overflow is undefined is widespread.  I see
> frequently see code that takes advantage of expectations that are
> actually false if strict enforcement is in play.
>

C# can assume "Everything is a PC", which C++ hasn't done so far.=20
Implementability has been seen as more important than making low level=20
features fixed.

A lot of things would be easier for the majority if we assume not only a=20
defined overflow behavior, but also set the character set to ASCII,=20
assume int to be 32 bits and require IEEE floating point. Again, some=20
important minorities would not like that. (Presumably the same minority=20
that didn't appreciate the removal of trigraphs).

Java has the "advantage" of only running on its own platform (the Java=20
VM). To run this efficiently on an IBM mainframe, you need to have=20
dedicated Java processors configured. C++, on the other hand, can run=20
natively.


Bo Persson


--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_287_441326700.1418675083930
Content-Type: multipart/alternative;
 boundary="----=_Part_288_2116813809.1418675083930"

------=_Part_288_2116813809.1418675083930
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Monday, December 15, 2014 12:03:49 PM UTC-8, Bo Persson wrote:
>
> On 2014-12-15 19:54, Myriachan wrote:=20
> > On Saturday, December 13, 2014 3:55:37 AM UTC-8, Ville Voutilainen=20
> wrote:=20
> >=20
> >     On 13 December 2014 at 04:29, Howard Hinnant <howard....@gmail.com=
=20
> >     <javascript:>> wrote:=20
> >      > On Dec 12, 2014, at 9:04 PM, David Krauss <pot...@gmail.com=20
> >     <javascript:>> wrote:=20
> >      >=20
> >      >> If you make overflow well-formed, then the tools can=E2=80=99t =
flag it=20
> >     and the user will never have a correct program.=20
> >      >>=20
> >      >> Assigning meaning to nonsense programs is a poor way to obtain=
=20
> >     =E2=80=9Ccorrectness.=E2=80=9D=20
> >      >=20
> >      > Nowhere has anyone suggested making signed overflow well-formed.=
=20
> >       The proposal Melissa made at the beginning of this thread is to=
=20
> >     make it implementation defined.  If I have implied otherwise, I=20
> >     apologize for that.=20
> >=20
> >     Even so, there's a vast difference between "tools can't flag it" an=
d=20
> >     "tools that promise they=20
> >     will not flag it if it's not UB".=20
> >=20
> >=20
> > Yes.  Tools will exist regardless of whether the operations are=20
> > defined--there are sanitizers for C/C++ that will help you find unsigne=
d=20
> > integer overflows, even though those are well-defined.=20
> >=20
> > C# allows you to set overflows to trap instead of wrap, even though the=
=20
> > default is to wrap in a well-defined manner.  (C# also has keywords to=
=20
> > declare overflow as trapping or wrapping in certain blocks of code or=
=20
> > expressions.)  I don't know what tools Java has, but I know that it=20
> > wraps on overflow.=20
> >=20
> > My view is more extreme than others, but I feel as though this is all=
=20
> > about making the behavior match programmer expectation.  So many of us=
=20
> > were taught about how two's complement works, and what happens on=20
> > overflow.  This is especially true given how it works in other=20
> > languages--they're almost all "trap" or "wrap" semantics.  Even among=
=20
> > professional C/C++ programmers, anecdotally it doesn't seem as though=
=20
> > knowledge that signed overflow is undefined is widespread.  I see=20
> > frequently see code that takes advantage of expectations that are=20
> > actually false if strict enforcement is in play.=20
> >=20
>
> C# can assume "Everything is a PC", which C++ hasn't done so far.=20
> Implementability has been seen as more important than making low level=20
> features fixed.=20
>
> A lot of things would be easier for the majority if we assume not only a=
=20
> defined overflow behavior, but also set the character set to ASCII,=20
> assume int to be 32 bits and require IEEE floating point. Again, some=20
> important minorities would not like that. (Presumably the same minority=
=20
> that didn't appreciate the removal of trigraphs).=20
>
> Java has the "advantage" of only running on its own platform (the Java=20
> VM). To run this efficiently on an IBM mainframe, you need to have=20
> dedicated Java processors configured. C++, on the other hand, can run=20
> natively.=20
> =20


The Standard could define whatever it likes; not that I suggest this, but=
=20
there is nothing that says int must match a particular processor register=
=20
format.  One's-complement machines can implement a language with only=20
two's-complement integers--it'd just be slow.  Implementations already have=
=20
to support unsigned integers, which in C/C++ have identical semantics to=20
(wrapping) two's-complement signed integers with the exception of sign=20
extension, right shifting, comparison and division.  I'm not suggesting to=
=20
require two's complement on all machines, but it is possible.

My suggestion is more along the lines of ensuring that values get sent down=
=20
to the processor and handled however they are by the machine.  I think=20
almost all machines would be covered by a policy of saying that signed=20
integer overflow were implementation-defined to trap, wrap or saturate.

I see this as analogous to how ('Z' - 'A') is implementation-defined=20
because of non-ASCII character sets.  This expression is=20
implementation-defined rather than undefined (*).  If we were to take the=
=20
same philosophy that signed integers currently use, ('Z' - 'A') on an ASCII=
=20
system would be undefined behavior instead of 25.

(*) Unless ('Z' - 'A') is an overflow or underflow!  This is taking things=
=20
to an extreme, though, since no such character set exists.

Melissa

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_288_2116813809.1418675083930
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, December 15, 2014 12:03:49 PM UTC-8, Bo Persson=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2014-12-15 19:54, My=
riachan wrote:
<br>&gt; On Saturday, December 13, 2014 3:55:37 AM UTC-8, Ville Voutilainen=
 wrote:
<br>&gt;
<br>&gt; &nbsp; &nbsp; On 13 December 2014 at 04:29, Howard Hinnant &lt;<a>=
howard....@gmail.com</a>
<br>&gt; &nbsp; &nbsp; &lt;javascript:&gt;&gt; wrote:
<br>&gt; &nbsp; &nbsp; &nbsp;&gt; On Dec 12, 2014, at 9:04 PM, David Krauss=
 &lt;<a>pot...@gmail.com</a>
<br>&gt; &nbsp; &nbsp; &lt;javascript:&gt;&gt; wrote:
<br>&gt; &nbsp; &nbsp; &nbsp;&gt;
<br>&gt; &nbsp; &nbsp; &nbsp;&gt;&gt; If you make overflow well-formed, the=
n the tools can=E2=80=99t flag it
<br>&gt; &nbsp; &nbsp; and the user will never have a correct program.
<br>&gt; &nbsp; &nbsp; &nbsp;&gt;&gt;
<br>&gt; &nbsp; &nbsp; &nbsp;&gt;&gt; Assigning meaning to nonsense program=
s is a poor way to obtain
<br>&gt; &nbsp; &nbsp; =E2=80=9Ccorrectness.=E2=80=9D
<br>&gt; &nbsp; &nbsp; &nbsp;&gt;
<br>&gt; &nbsp; &nbsp; &nbsp;&gt; Nowhere has anyone suggested making signe=
d overflow well-formed.
<br>&gt; &nbsp; &nbsp; &nbsp; The proposal Melissa made at the beginning of=
 this thread is to
<br>&gt; &nbsp; &nbsp; make it implementation defined. &nbsp;If I have impl=
ied otherwise, I
<br>&gt; &nbsp; &nbsp; apologize for that.
<br>&gt;
<br>&gt; &nbsp; &nbsp; Even so, there's a vast difference between "tools ca=
n't flag it" and
<br>&gt; &nbsp; &nbsp; "tools that promise they
<br>&gt; &nbsp; &nbsp; will not flag it if it's not UB".
<br>&gt;
<br>&gt;
<br>&gt; Yes. &nbsp;Tools will exist regardless of whether the operations a=
re
<br>&gt; defined--there are sanitizers for C/C++ that will help you find un=
signed
<br>&gt; integer overflows, even though those are well-defined.
<br>&gt;
<br>&gt; C# allows you to set overflows to trap instead of wrap, even thoug=
h the
<br>&gt; default is to wrap in a well-defined manner. &nbsp;(C# also has ke=
ywords to
<br>&gt; declare overflow as trapping or wrapping in certain blocks of code=
 or
<br>&gt; expressions.) &nbsp;I don't know what tools Java has, but I know t=
hat it
<br>&gt; wraps on overflow.
<br>&gt;
<br>&gt; My view is more extreme than others, but I feel as though this is =
all
<br>&gt; about making the behavior match programmer expectation. &nbsp;So m=
any of us
<br>&gt; were taught about how two's complement works, and what happens on
<br>&gt; overflow. &nbsp;This is especially true given how it works in othe=
r
<br>&gt; languages--they're almost all "trap" or "wrap" semantics. &nbsp;Ev=
en among
<br>&gt; professional C/C++ programmers, anecdotally it doesn't seem as tho=
ugh
<br>&gt; knowledge that signed overflow is undefined is widespread. &nbsp;I=
 see
<br>&gt; frequently see code that takes advantage of expectations that are
<br>&gt; actually false if strict enforcement is in play.
<br>&gt;
<br>
<br>C# can assume "Everything is a PC", which C++ hasn't done so far.=20
<br>Implementability has been seen as more important than making low level=
=20
<br>features fixed.
<br>
<br>A lot of things would be easier for the majority if we assume not only =
a=20
<br>defined overflow behavior, but also set the character set to ASCII,=20
<br>assume int to be 32 bits and require IEEE floating point. Again, some=
=20
<br>important minorities would not like that. (Presumably the same minority=
=20
<br>that didn't appreciate the removal of trigraphs).
<br>
<br>Java has the "advantage" of only running on its own platform (the Java=
=20
<br>VM). To run this efficiently on an IBM mainframe, you need to have=20
<br>dedicated Java processors configured. C++, on the other hand, can run=
=20
<br>natively.
<br>
&nbsp;</blockquote><div><br>The Standard could define whatever it likes; no=
t that I suggest this, but there is nothing that says <span style=3D"font-f=
amily: courier new,monospace;">int</span>
 must match a particular processor register format.&nbsp; One's-complement =
machines can=20
implement a language with only two's-complement integers--it'd just be=20
slow.&nbsp; Implementations already have to support unsigned integers, whic=
h in C/C++ have identical semantics to (wrapping) two's-complement signed i=
ntegers with the exception of sign extension, right shifting, comparison an=
d division.&nbsp; I'm not suggesting to require two's complement on all mac=
hines, but it is possible.<br><br>My suggestion is more along the lines of =
ensuring that values get sent down to the processor and handled however the=
y are by the machine.&nbsp; I think almost all machines would be covered by=
 a policy of saying that signed integer overflow were implementation-define=
d to trap, wrap or saturate.<br><br>I see this as analogous to how <span st=
yle=3D"font-family: courier new,monospace;">('Z' - 'A')</span> is implement=
ation-defined because of non-ASCII character sets.&nbsp; This expression is=
 implementation-defined rather than undefined (*).&nbsp; If we were to take=
 the same philosophy that signed integers currently use, <span style=3D"fon=
t-family: courier new,monospace;">('Z' - 'A')</span> on an ASCII system wou=
ld be undefined behavior instead of <span style=3D"font-family: courier new=
,monospace;">25</span>.<br><br>(*) Unless <span style=3D"font-family: couri=
er new,monospace;">('Z' - 'A')</span> is an overflow or underflow!&nbsp; Th=
is is taking things to an extreme, though, since no such character set exis=
ts.<br><br>Melissa<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_288_2116813809.1418675083930--
------=_Part_287_441326700.1418675083930--

.

--20cf30223f438ac347050a47c237
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 15, 2014 at 10:54 AM, Myriachan <myriachan@gmail.com> wrote:

> On Saturday, December 13, 2014 3:55:37 AM UTC-8, Ville Voutilainen wrote:
>>
>> On 13 December 2014 at 04:29, Howard Hinnant <howard....@gmail.com>
>> wrote:
>> > On Dec 12, 2014, at 9:04 PM, David Krauss <pot...@gmail.com> wrote:
>> >
>> >> If you make overflow well-formed, then the tools can=E2=80=99t flag i=
t and the
>> user will never have a correct program.
>> >>
>> >> Assigning meaning to nonsense programs is a poor way to obtain
>> =E2=80=9Ccorrectness.=E2=80=9D
>> >
>> > Nowhere has anyone suggested making signed overflow well-formed.  The
>> proposal Melissa made at the beginning of this thread is to make it
>> implementation defined.  If I have implied otherwise, I apologize for th=
at.
>>
>> Even so, there's a vast difference between "tools can't flag it" and
>> "tools that promise they
>> will not flag it if it's not UB".
>>
>
> Yes.  Tools will exist regardless of whether the operations are
> defined--there are sanitizers for C/C++ that will help you find unsigned
> integer overflows, even though those are well-defined.
>

These are not widely used and are not particularly useful, because their
false positive rate is extremely high. In contrast, the false positive rate
of the sanitizers that catch undefined behavior is effectively zero (their
reports always indicate a bug, either in the code under test or
occasionally in the sanitizer itself...).

My view is more extreme than others, but I feel as though this is all about
> making the behavior match programmer expectation.  So many of us were
> taught about how two's complement works, and what happens on overflow.
> This is especially true given how it works in other languages--they're
> almost all "trap" or "wrap" semantics.  Even among professional C/C++
> programmers, anecdotally it doesn't seem as though knowledge that signed
> overflow is undefined is widespread.  I see frequently see code that take=
s
> advantage of expectations that are actually false if strict enforcement i=
s
> in play.
>

In my experience, code that expects two's complement on overflow is
*vastly* less common than code that does not expect overflow to occur.
Defining the semantics as reduction mod 2^n on overflow does a lot of harm,
because it would make the signed overflow sanitizers as useless as the
unsigned overflow sanitizers are today, and introduces an indirect
performance penalty for all optimizing systems that use the lack of signed
overflow as a basis for optimization. Defining the semantics as
trap-on-overflow introduces a direct performance penalty on some systems
(due to the lack of direct hardware support for trap on overflow), in
addition to the indirect performance penalty. Performance remains one of
the major selling points for C++, so mandating either of these options
seems like a losing proposition.

We could give implementations a choice: pick between "trap on overflow",
"wrap on overflow", and "UB on overflow" (and document your choice, and
provide a mechanism to switch between these choices). But note that this is
both already permitted by the standard (trapping and wrapping are
permissible results in the face of UB) and is already widespread current
practice (observe the -ftrapv and -fwrapv flags, and the UB sanitizers).
Note also that implementors largely take their guidance as to how to behave
in the presence of UB from their customers; optimizations on the basis of
UB are added because customers ask for faster code and are prepared to deal
with the associated costs. Finally, note that very little code is built and
shipped with -ftrapv or -fwrapv enabled, suggesting that few users are
aware of the issue and these flags and actually want defined semantics in
these cases.

Perhaps the only thing missing here is the ability to selectively enable
trapping or wrapping semantics for a particular region of code, so that
library authors don't need to tell their customers "turn on -fwrapv because
we assume two's complement arithmetic in our header files". That ability
could be provided by the language, but it could also be provided in a
(possibly standard) library component.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--20cf30223f438ac347050a47c237
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 M=
on, Dec 15, 2014 at 10:54 AM, Myriachan <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div dir=3D"ltr">On Saturday, December 13, 2=
014 3:55:37 AM UTC-8, Ville Voutilainen wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 13 Decemb=
er 2014 at 04:29, Howard Hinnant &lt;<a>howard....@gmail.com</a>&gt; wrote:
<br><span class=3D"">&gt; On Dec 12, 2014, at 9:04 PM, David Krauss &lt;<a>=
pot...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt;&gt; If you make overflow well-formed, then the tools can=E2=80=99t=
 flag it and the user will never have a correct program.
<br>&gt;&gt;
<br>&gt;&gt; Assigning meaning to nonsense programs is a poor way to obtain=
 =E2=80=9Ccorrectness.=E2=80=9D
<br>&gt;
<br>&gt; Nowhere has anyone suggested making signed overflow well-formed.=
=C2=A0 The proposal Melissa made at the beginning of this thread is to make=
 it implementation defined.=C2=A0 If I have implied otherwise, I apologize =
for that.
<br>
<br>Even so, there&#39;s a vast difference between &quot;tools can&#39;t fl=
ag it&quot; and
<br>&quot;tools that promise they
<br>will not flag it if it&#39;s not UB&quot;.
<br></span></blockquote><div><br>Yes.=C2=A0 Tools will exist regardless of =
whether the operations are defined--there are sanitizers for C/C++ that wil=
l help you find unsigned integer overflows, even though those are well-defi=
ned.<br></div></div></blockquote><div><br></div><div>These are not widely u=
sed and are not particularly useful, because their false positive rate is e=
xtremely high. In contrast, the false positive rate of the sanitizers that =
catch undefined behavior is effectively zero (their reports always indicate=
 a bug, either in the code under test or occasionally in the sanitizer itse=
lf...).</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20=
4);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>My view =
is more extreme than others, but I feel as though this is all about making =
the behavior match programmer expectation.=C2=A0 So many of us were taught =
about how two&#39;s complement works, and what happens on overflow.=C2=A0 T=
his is especially true given how it works in other languages--they&#39;re a=
lmost all &quot;trap&quot; or &quot;wrap&quot; semantics.=C2=A0 Even among =
professional C/C++ programmers, anecdotally it doesn&#39;t seem as though k=
nowledge that signed overflow is undefined is widespread.=C2=A0 I see frequ=
ently see code that takes advantage of expectations that are actually false=
 if strict enforcement is in play.</div></div></blockquote><div><br></div><=
div>In my experience, code that expects two&#39;s complement on overflow is=
 *vastly* less common than code that does not expect overflow to occur. Def=
ining the semantics as reduction mod 2^n on overflow does a lot of harm, be=
cause it would make the signed overflow sanitizers as useless as the unsign=
ed overflow sanitizers are today, and introduces an indirect performance pe=
nalty for all optimizing systems that use the lack of signed overflow as a =
basis for optimization. Defining the semantics as trap-on-overflow introduc=
es a direct performance penalty on some systems (due to the lack of direct =
hardware support for trap on overflow), in addition to the indirect perform=
ance penalty. Performance remains one of the major selling points for C++, =
so mandating either of these options seems like a losing proposition.</div>=
<div><br></div><div>We could give implementations a choice: pick between &q=
uot;trap on overflow&quot;, &quot;wrap on overflow&quot;, and &quot;UB on o=
verflow&quot; (and document your choice, and provide a mechanism to switch =
between these choices). But note that this is both already permitted by the=
 standard (trapping and wrapping are permissible results in the face of UB)=
 and is already widespread current practice (observe the -ftrapv and -fwrap=
v flags, and the UB sanitizers). Note also that implementors largely take t=
heir guidance as to how to behave in the presence of UB from their customer=
s; optimizations on the basis of UB are added because customers ask for fas=
ter code and are prepared to deal with the associated costs. Finally, note =
that very little code is built and shipped with -ftrapv or -fwrapv enabled,=
 suggesting that few users are aware of the issue and these flags and actua=
lly want defined semantics in these cases.</div><div><br></div><div>Perhaps=
 the only thing missing here is the ability to selectively enable trapping =
or wrapping semantics for a particular region of code, so that library auth=
ors don&#39;t need to tell their customers &quot;turn on -fwrapv because we=
 assume two&#39;s complement arithmetic in our header files&quot;. That abi=
lity could be provided by the language, but it could also be provided in a =
(possibly standard) library component.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--20cf30223f438ac347050a47c237--

.

------=_Part_1670_887083544.1418681349851
Content-Type: multipart/alternative;
 boundary="----=_Part_1671_1381646534.1418681349851"

------=_Part_1671_1381646534.1418681349851
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le lundi 15 d=C3=A9cembre 2014 22:16:48 UTC+1, Richard Smith a =C3=A9crit :
>
>
> In my experience, code that expects two's complement on overflow is=20
> *vastly* less common than code that does not expect overflow to occur.
>

The code I've seen where signed overflow was not an error can be easily=20
classified:
- variations on while (i++!=3D INT_MAX)... where the logic of the program i=
n=20
fact ignores -- more or less obviously -- the result of the overflowing=20
operation.
- trying to detect overflow by assuming the wrap behavior.
- inside simulators for a two's complement machine.
(I'm interested in other cases BTW)

In other words, I agree that the effect of defining signed overflow would=
=20
mostly change UB into logic error. The first case is the only one for which=
=20
I'm really interested in a better solution than the current ways ((i !=3D=
=20
INT_MAX) && (i++, true) has little appeal for me)

Defining the semantics as reduction mod 2^n on overflow does a lot of harm,=
=20
> because it would make the signed overflow sanitizers as useless as the=20
> unsigned overflow sanitizers are today, and introduces an indirect=20
> performance penalty for all optimizing systems that use the lack of signe=
d=20
> overflow as a basis for optimization. Defining the semantics as=20
> trap-on-overflow introduces a direct performance penalty on some systems=
=20
> (due to the lack of direct hardware support for trap on overflow), in=20
> addition to the indirect performance penalty. Performance remains one of=
=20
> the major selling points for C++, so mandating either of these options=20
> seems like a losing proposition.
>

I've mixed opinions about optimization assuming UB doesn't occur.=20
Simplifying i<i+1 to true doesn't bother me.  Simplifying i++ !=3D INT_MAX =
to=20
true do bother me as does back propagating range information so that the UB=
=20
has non causal effect. I'm not sure I'd be able to give a definition of=20
what I find acceptable.

Yours;

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_1671_1381646534.1418681349851
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Le lundi 15 d=C3=A9cembre 2014 22:16:48 UTC+1, Richard Smi=
th a =C3=A9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><br><div>In my experience, code th=
at expects two's complement on overflow is *vastly* less common than code t=
hat does not expect overflow to occur.</div></div></div></div></blockquote>=
<div><br>The code I've seen where signed overflow was not an error can be e=
asily classified:<br>- variations on while (i++!=3D INT_MAX)... where the l=
ogic of the program in fact ignores -- more or less obviously -- the result=
 of the overflowing operation.<br>- trying to detect overflow by assuming t=
he wrap behavior.<br>- inside simulators for a two's complement machine.<br=
>(I'm interested in other cases BTW)<br><br>In other words, I agree that th=
e effect of defining signed overflow would mostly change UB into logic erro=
r. The first case is the only one for which I'm really interested in a bett=
er solution than the current ways ((i !=3D INT_MAX) &amp;&amp; (i++, true) =
has little appeal for me)<br><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div> Defining th=
e semantics as reduction mod 2^n on overflow does a lot of harm, because it=
 would make the signed overflow sanitizers as useless as the unsigned overf=
low sanitizers are today, and introduces an indirect performance penalty fo=
r all optimizing systems that use the lack of signed overflow as a basis fo=
r optimization. Defining the semantics as trap-on-overflow introduces a dir=
ect performance penalty on some systems (due to the lack of direct hardware=
 support for trap on overflow), in addition to the indirect performance pen=
alty. Performance remains one of the major selling points for C++, so manda=
ting either of these options seems like a losing proposition.</div></div></=
div></div></blockquote><div><br>I've mixed opinions about optimization assu=
ming UB doesn't occur. Simplifying i&lt;i+1 to true doesn't bother me.&nbsp=
; Simplifying i++ !=3D INT_MAX to true do bother me as does back propagatin=
g range information so that the UB has non causal effect. I'm not sure I'd =
be able to give a definition of what I find acceptable.<br></div><br>Yours;=
<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1671_1381646534.1418681349851--
------=_Part_1670_887083544.1418681349851--

.

On Dec 15, 2014, at 4:16 PM, Richard Smith <richard@metafoo.co.uk> wrote:

> On Mon, Dec 15, 2014 at 10:54 AM, Myriachan <myriachan@gmail.com> wrote:
>> Yes.  Tools will exist regardless of whether the operations are defined-=
-there are sanitizers for C/C++ that will help you find unsigned integer ov=
erflows, even though those are well-defined.
>>=20
> These are not widely used and are not particularly useful, because their =
false positive rate is extremely high. In contrast, the false positive rate=
 of the sanitizers that catch undefined behavior is effectively zero (their=
 reports always indicate a bug, either in the code under test or occasional=
ly in the sanitizer itself=E2=80=A6).

SafeInt:

https://safeint.codeplex.com

It is widely used.  It is very effective.  And it checks for both signed an=
d unsigned overflow.

>> My view is more extreme than others, but I feel as though this is all ab=
out making the behavior match programmer expectation.  So many of us were t=
aught about how two's complement works, and what happens on overflow.  This=
 is especially true given how it works in other languages--they're almost a=
ll "trap" or "wrap" semantics.  Even among professional C/C++ programmers, =
anecdotally it doesn't seem as though knowledge that signed overflow is und=
efined is widespread.  I see frequently see code that takes advantage of ex=
pectations that are actually false if strict enforcement is in play.
>>=20
> In my experience, code that expects two's complement on overflow is *vast=
ly* less common than code that does not expect overflow to occur.

It is common when the code is trying to detect and recover from overflow.


> Defining the semantics as reduction mod 2^n on overflow does a lot of har=
m,

*Nobody* has proposed that.  The proposal on the table is *implementation d=
efined*.  I.e. Attention compiler:  please stop throwing away my code.  Jus=
t let it do what the hardware does.

> because it would make the signed overflow sanitizers as useless as the un=
signed overflow sanitizers are today, and introduces an indirect performanc=
e penalty for all optimizing systems that use the lack of signed overflow a=
s a basis for optimization. Defining the semantics as trap-on-overflow intr=
oduces a direct performance penalty on some systems (due to the lack of dir=
ect hardware support for trap on overflow), in addition to the indirect per=
formance penalty. Performance remains one of the major selling points for C=
++, so mandating either of these options seems like a losing proposition.

On the other hand, SafeInt, a 100% library solution, has been successfully =
addressing this need, with no help from compilers.  Indeed, most recently S=
afeInt had to be updated because gcc, clang and Intel started =E2=80=9Copti=
mizing=E2=80=9D out its overflow checks.

> We could give implementations a choice: pick between "trap on overflow", =
"wrap on overflow", and "UB on overflow" (and document your choice, and pro=
vide a mechanism to switch between these choices). But note that this is bo=
th already permitted by the standard (trapping and wrapping are permissible=
 results in the face of UB) and is already widespread current practice (obs=
erve the -ftrapv and -fwrapv flags, and the UB sanitizers).

The proposal on the table is -fno-strict-overflow (as I understand it), exc=
ept that every programmer wouldn=E2=80=99t have to learn the different ways=
 of spelling that for every different compiler.


> Note also that implementors largely take their guidance as to how to beha=
ve in the presence of UB from their customers; optimizations on the basis o=
f UB are added because customers ask for faster code and are prepared to de=
al with the associated costs.

There has been a lot of customer push back on this one, dating back a remar=
kably long time.

> Finally, note that very little code is built and shipped with -ftrapv or =
-fwrapv enabled, suggesting that few users are aware of the issue and these=
 flags and actually want defined semantics in these cases.

This is not a conclusion I could draw from my experience in the field.  I w=
ould estimate that these flags are not used much because most people don=E2=
=80=99t understand the need for or ramifications of having to use them.

*  Talks on undefined behavior draw large and interested crowds, and gasps =
of disbelief.
*  SafeInt, not made by amateurs, recently updated for this very issue.
*  It is easy to find overflow-checking code on SO which has undefined beha=
vior.  It is also easy to find SO answers pointing out the undefined behavi=
or.  The community is attempting to educate itself.

Is the benefit of this optimization worth the risk of not having everyone s=
ufficiently educated?

-Howard

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--001a113a7d6c2aa6ae050a49b8ed
Content-Type: text/plain; charset=UTF-8

On 15 December 2014 at 17:21, Howard Hinnant <howard.hinnant@gmail.com>
wrote:

> *Nobody* has proposed that.  The proposal on the table is *implementation
> defined*.  I.e. Attention compiler:  please stop throwing away my code.
> Just let it do what the hardware does.
>

This also means:  "Attention compiler:  please stop warning me about
potential bugs due to trapping/wrapping/saturating, because you cannot tell
the difference between my accidentally allowing that to happen and my
intentionally requiring that to happen."

If your hardware wraps, how often did you actually intend for your
calculations to wrap?  My (admittedly anecdotal) claim is that it is rare,
even for unsigned values.

Defining behavior does not necessarily make code less buggy, because you
cannot tell the difference between "I meant to do that" and "there be
dragons; don't go there".  Better interfaces can make code less buggy.
Unfortunately, C math isn't one of those interfaces, and defining the
behavior (even just implementation defined) makes things worse IMO.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a113a7d6c2aa6ae050a49b8ed
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On 15 December 2014 at 17:21, H=
oward Hinnant <span dir=3D"ltr">&lt;<a href=3D"mailto:howard.hinnant@gmail.=
com" target=3D"_blank">howard.hinnant@gmail.com</a>&gt;</span> wrote:<br><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=3D":2uu" cl=
ass=3D"a3s" style=3D"overflow:hidden">*Nobody* has proposed that.=C2=A0 The=
 proposal on the table is *implementation defined*.=C2=A0 I.e. Attention co=
mpiler:=C2=A0 please stop throwing away my code.=C2=A0 Just let it do what =
the hardware does.<br></div></blockquote><div><br></div><div>This also mean=
s: =C2=A0&quot;Attention compiler: =C2=A0please stop warning me about poten=
tial bugs due to trapping/wrapping/saturating, because you cannot tell the =
difference between my accidentally allowing that to happen and my intention=
ally requiring that to happen.&quot;=C2=A0</div></div><br>If your hardware =
wraps, how often did you actually intend for your calculations to wrap?=C2=
=A0 My (admittedly anecdotal) claim is that it is rare, even for unsigned v=
alues.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"=
>Defining behavior does not necessarily make code less buggy, because you c=
annot tell the difference between &quot;I meant to do that&quot; and &quot;=
there be dragons; don&#39;t go there&quot;.=C2=A0 Better interfaces can mak=
e code less buggy.=C2=A0 Unfortunately, C math isn&#39;t one of those inter=
faces, and defining the behavior (even just implementation defined) makes t=
hings worse IMO.</div><div class=3D"gmail_extra">-- <br><div class=3D"gmail=
_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113a7d6c2aa6ae050a49b8ed--

.

On Fri, Dec 12, 2014 at 6:01 PM, Howard Hinnant
<howard.hinnant@gmail.com> wrote:
>
> This is often purposefully coded more like:
>
>        if (i + 1 < i)
>        {
>            // oops, we=E2=80=99ve overflowed!
>            // deal with it!
>            // ...
>        }
>
> If i has unsigned type, this is well-formed and portable code.  unsigned =
arithmetic is required to be modulo 2^n (wraps on overflow).
>

It i has BigInt type, this is well-formed and never happens.

So in what world i + 1 < i?  Oh, unsigned integers.  Then
they violated the general rule of mathematics.

For me, I don't want to use unsigned integer when I need
mathematics operations.  They are good for manipulating
representations, but not for +-*/.  I have to because of size_t.

--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Fri, Dec 12, 2014 at 6:29 PM, Howard Hinnant
<howard.hinnant@gmail.com> wrote:
>
> An optimization is a transform that has no visible side effects other than performance.
>
> An optimization *is not* a transform that has side effects for which some committee said:  you are not allowed to look at these side effects!
>

I don't think you agree with yourself as a library implementer, since
the reason we can implement std::sort using intro-sort instead of
quick-sort is that the users are not allowed to look at the side
effects -- where the elements not satisfying strict weak ordering
lives -- that's an UB.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Monday 15 December 2014 12:24:43 Myriachan wrote:
> My suggestion is more along the lines of ensuring that values get sent down
> to the processor and handled however they are by the machine.  I think
> almost all machines would be covered by a policy of saying that signed
> integer overflow were implementation-defined to trap, wrap or saturate.

Or do nothing or result in garbage value.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_2626_1288511606.1418692327615
Content-Type: multipart/alternative;
 boundary="----=_Part_2627_789465694.1418692327616"

------=_Part_2627_789465694.1418692327616
Content-Type: text/plain; charset=UTF-8

On Monday, December 15, 2014 1:16:48 PM UTC-8, Richard Smith wrote:
>
> On Mon, Dec 15, 2014 at 10:54 AM, Myriachan <myri...@gmail.com
> <javascript:>> wrote:
>
>> Yes.  Tools will exist regardless of whether the operations are
>> defined--there are sanitizers for C/C++ that will help you find unsigned
>> integer overflows, even though those are well-defined.
>>
>
> These are not widely used and are not particularly useful, because their
> false positive rate is extremely high. In contrast, the false positive rate
> of the sanitizers that catch undefined behavior is effectively zero (their
> reports always indicate a bug, either in the code under test or
> occasionally in the sanitizer itself...).
>
>
They're sometimes only bugs *because* of the current undefined behavior
definition, such as "if (x + 35 < x)" checks.  Such code is not inherently
wrong.


> In my experience, code that expects two's complement on overflow is
> *vastly* less common than code that does not expect overflow to occur.
> Defining the semantics as reduction mod 2^n on overflow does a lot of harm,
> because it would make the signed overflow sanitizers as useless as the
> unsigned overflow sanitizers are today, and introduces an indirect
> performance penalty for all optimizing systems that use the lack of signed
> overflow as a basis for optimization. Defining the semantics as
> trap-on-overflow introduces a direct performance penalty on some systems
> (due to the lack of direct hardware support for trap on overflow), in
> addition to the indirect performance penalty. Performance remains one of
> the major selling points for C++, so mandating either of these options
> seems like a losing proposition.
>
>
That is true; for every SHA-256 implementation there are probably 100 "for"
loops that assume no overflow.

Are there any statistics on how important signed overflow being undefined
is to optimizers?  Such optimizers already can't do anything about unsigned
integer overflow.  I wonder whether the optimization is worth the cost of
hidden bugs.


> We could give implementations a choice: pick between "trap on overflow",
> "wrap on overflow", and "UB on overflow" (and document your choice, and
> provide a mechanism to switch between these choices). But note that this is
> both already permitted by the standard (trapping and wrapping are
> permissible results in the face of UB) and is already widespread current
> practice (observe the -ftrapv and -fwrapv flags, and the UB sanitizers).
> Note also that implementors largely take their guidance as to how to behave
> in the presence of UB from their customers; optimizations on the basis of
> UB are added because customers ask for faster code and are prepared to deal
> with the associated costs. Finally, note that very little code is built and
> shipped with -ftrapv or -fwrapv enabled, suggesting that few users are
> aware of the issue and these flags and actually want defined semantics in
> these cases.
>
>
Why allow it to be undefined behavior?  Trapping, wrapping and saturation
seems like would cover everything.  Note that "trapping" is highly
variable: Windows throws a catch()able exception, POSIX has SIGFPE,
embedded systems could have an unhandled interrupt that goes to la-la land
but is still a trap.

Perhaps the only thing missing here is the ability to selectively enable
> trapping or wrapping semantics for a particular region of code, so that
> library authors don't need to tell their customers "turn on -fwrapv because
> we assume two's complement arithmetic in our header files". That ability
> could be provided by the language, but it could also be provided in a
> (possibly standard) library component.
>

That's exactly what C# does: the keyword "checked" (inversely "unchecked")
specifies that the following expression or code block shall trap on
overflow.

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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_2627_789465694.1418692327616
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, December 15, 2014 1:16:48 PM UTC-8, Richard Smi=
th wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
><div class=3D"gmail_quote">On Mon, Dec 15, 2014 at 10:54 AM, Myriachan <sp=
an dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"YKdf-uzssioJ" onmousedown=3D"this.href=3D'javascript:';return tr=
ue;" onclick=3D"this.href=3D'javascript:';return true;">myri...@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>Yes.&nbsp; T=
ools will exist regardless of whether the operations are defined--there are=
 sanitizers for C/C++ that will help you find unsigned integer overflows, e=
ven though those are well-defined.<br></div></div></blockquote><div><br></d=
iv><div>These are not widely used and are not particularly useful, because =
their false positive rate is extremely high. In contrast, the false positiv=
e rate of the sanitizers that catch undefined behavior is effectively zero =
(their reports always indicate a bug, either in the code under test or occa=
sionally in the sanitizer itself...).</div><div><br></div></div></div></div=
></blockquote><div><br>They're sometimes only bugs <i>because</i> of the cu=
rrent undefined behavior definition, such as "<span style=3D"font-family: c=
ourier new,monospace;">if (x + 35 &lt; x)</span>" checks.&nbsp; Such code i=
s not inherently wrong.<br>&nbsp;</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div>In my =
experience, code that expects two's complement on overflow is *vastly* less=
 common than code that does not expect overflow to occur. Defining the sema=
ntics as reduction mod 2^n on overflow does a lot of harm, because it would=
 make the signed overflow sanitizers as useless as the unsigned overflow sa=
nitizers are today, and introduces an indirect performance penalty for all =
optimizing systems that use the lack of signed overflow as a basis for opti=
mization. Defining the semantics as trap-on-overflow introduces a direct pe=
rformance penalty on some systems (due to the lack of direct hardware suppo=
rt for trap on overflow), in addition to the indirect performance penalty. =
Performance remains one of the major selling points for C++, so mandating e=
ither of these options seems like a losing proposition.<div><br></div></div=
></div></div></blockquote><div><br>That is true; for every SHA-256 implemen=
tation there are probably 100 "<span style=3D"font-family: courier new,mono=
space;">for</span>" loops that assume no overflow.<br><br>Are there any sta=
tistics on how important signed overflow being undefined is to optimizers?&=
nbsp; Such optimizers already can't do anything about unsigned integer over=
flow.&nbsp; I wonder whether the optimization is worth the cost of hidden b=
ugs.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>We could give impl=
ementations a choice: pick between "trap on overflow", "wrap on overflow", =
and "UB on overflow" (and document your choice, and provide a mechanism to =
switch between these choices). But note that this is both already permitted=
 by the standard (trapping and wrapping are permissible results in the face=
 of UB) and is already widespread current practice (observe the -ftrapv and=
 -fwrapv flags, and the UB sanitizers). Note also that implementors largely=
 take their guidance as to how to behave in the presence of UB from their c=
ustomers; optimizations on the basis of UB are added because customers ask =
for faster code and are prepared to deal with the associated costs. Finally=
, note that very little code is built and shipped with -ftrapv or -fwrapv e=
nabled, suggesting that few users are aware of the issue and these flags an=
d actually want defined semantics in these cases.</div><div><br></div></div=
></div></div></blockquote><div><br>Why allow it to be undefined behavior?&n=
bsp; Trapping, wrapping and saturation seems like would cover everything.&n=
bsp; Note that "trapping" is highly variable: Windows throws a <span style=
=3D"font-family: courier new,monospace;">catch()</span>able exception, POSI=
X has <span style=3D"font-family: courier new,monospace;">SIGFPE</span>, em=
bedded systems could have an unhandled interrupt that goes to la-la land bu=
t is still a trap.<br><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>Perhaps =
the only thing missing here is the ability to selectively enable trapping o=
r wrapping semantics for a particular region of code, so that library autho=
rs don't need to tell their customers "turn on -fwrapv because we assume tw=
o's complement arithmetic in our header files". That ability could be provi=
ded by the language, but it could also be provided in a (possibly standard)=
 library component.</div></div></div></div></blockquote><div><br>That's exa=
ctly what C# does: the keyword "<span style=3D"font-family: courier new,mon=
ospace;">checked</span>" (inversely "<span style=3D"font-family: courier ne=
w,monospace;">unchecked</span>") specifies that the following expression or=
 code block shall trap on overflow.<br><br>Melissa<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2627_789465694.1418692327616--
------=_Part_2626_1288511606.1418692327615--

.

On Monday 15 December 2014 18:21:53 Howard Hinnant wrote:
> > Defining the semantics as reduction mod 2^n on overflow does a lot of
> > harm,
>
> *Nobody* has proposed that.  The proposal on the table is *implementation
> defined*.  I.e. Attention compiler:  please stop throwing away my
> code.  Just let it do what the hardware does.

Implementation-defined could also be "UB on overflow", in which case the
compiler will still throw away code that can never be reached.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Under the heading of:

-----------------------
I am not making this up
-----------------------

From SafeInt:

https://safeint.codeplex.com

> The fix for this particular issue is to go ahead and code in a dependency=
 on 2's complement representation of negative numbers - the compiler may re=
move -x, but it won't remove ~(unsigned)x + 1, which emits the same bit pat=
tern (and the same assembly code).

So this library, the whole point of which is to detect integral overflow at=
 run time, written by experts who have been working on it for 7 years, inst=
ead of writing:

                *pRet =3D -tmp;

are instead forced to write:

                *pRet =3D SignedNegation< signed __int32 >::Value( tmp );

where SignedNegation is defined as:

// Helper classes to work keep compilers from
// optimizing away negation
template < typename T > class SignedNegation;

template <>
class SignedNegation <signed __int32>
{
public:
    static signed __int32 Value(unsigned __int64 in) SAFEINT_NOTHROW
    {
        return (signed __int32)(~(unsigned __int32)in + 1);
    }

    static signed __int32 Value(unsigned __int32 in) SAFEINT_NOTHROW
    {
        return (signed __int32)(~in + 1);
    }
};

template <>
class SignedNegation <signed __int64>
{
public:
    static signed __int64 Value(unsigned __int64 in) SAFEINT_NOTHROW
    {
        return (signed __int64)(~in + 1);
    }
};

And people think this is a good thing?!

Howard

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--Apple-Mail=_B5B5CC5E-5E82-4468-A0B0-BD19DE10BF07
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2014=E2=80=9312=E2=80=9316, at 10:44 AM, Howard Hinnant <howard.hinnan=
t@gmail.com> wrote:
>=20
>> The fix for this particular issue is to go ahead and code in a dependenc=
y on 2's complement representation of negative numbers - the compiler may r=
emove -x, but it won't remove ~(unsigned)x + 1, which emits the same bit pa=
ttern (and the same assembly code).
>=20
> So this library, the whole point of which is to detect integral overflow =
at run time, written by experts who have been working on it for 7 years, in=
stead of writing:
>=20
>                *pRet =3D -tmp;
>=20
> are instead forced to write:

Referring to the site, the particular issue in question is =E2=80=9Cwhen yo=
u attempt to perform a unary negation on a signed number, and that signed n=
umber is a compile-time constant with a value of MIN_INT.=E2=80=9D (sic)

So, if the program depends on the number being actually negated, squelching=
 the error with unsigned arithmetic is not the solution. The operation shou=
ld be flagged. The library is in this case not =E2=80=9Cdetect[ing] integra=
l overflow at run time,=E2=80=9D for one of the main cases that would be de=
tected.

What we need is a better way of flagging runtime UB at compile time, and le=
ss thinking =E2=80=9Cthis program is valid as long as the defective part ne=
ver runs.=E2=80=9D What we don=E2=80=99t need is more of =E2=80=9Cthe progr=
ammer probably just wants the two=E2=80=99s-complement bit-patterns,=E2=80=
=9D because that intrinsically covers up catchable errors.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_B5B5CC5E-5E82-4468-A0B0-BD19DE10BF07
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2014=E2=80=9312=
=E2=80=9316, at 10:44 AM, Howard Hinnant &lt;<a href=3D"mailto:howard.hinna=
nt@gmail.com" class=3D"">howard.hinnant@gmail.com</a>&gt; wrote:</div><br c=
lass=3D"Apple-interchange-newline"><div class=3D""><blockquote type=3D"cite=
" style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fon=
t-variant: normal; font-weight: normal; letter-spacing: normal; line-height=
: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfor=
m: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text=
-stroke-width: 0px;" class=3D"">The fix for this particular issue is to go =
ahead and code in a dependency on 2's complement representation of negative=
 numbers - the compiler may remove -x, but it won't remove ~(unsigned)x + 1=
, which emits the same bit pattern (and the same assembly code).<br class=
=3D""></blockquote><br style=3D"font-family: Helvetica; font-size: 12px; fo=
nt-style: normal; font-variant: normal; font-weight: normal; letter-spacing=
: normal; line-height: normal; orphans: auto; text-align: start; text-inden=
t: 0px; text-transform: none; white-space: normal; widows: auto; word-spaci=
ng: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-fa=
mily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal;=
 font-weight: normal; letter-spacing: normal; line-height: normal; orphans:=
 auto; text-align: start; text-indent: 0px; text-transform: none; white-spa=
ce: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px=
; float: none; display: inline !important;" class=3D"">So this library, the=
 whole point of which is to detect integral overflow at run time, written b=
y experts who have been working on it for 7 years, instead of writing:</spa=
n><br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal;=
 font-variant: normal; font-weight: normal; letter-spacing: normal; line-he=
ight: normal; orphans: auto; text-align: start; text-indent: 0px; text-tran=
sform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-=
text-stroke-width: 0px;" class=3D""><br style=3D"font-family: Helvetica; fo=
nt-size: 12px; font-style: normal; font-variant: normal; font-weight: norma=
l; letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; widows:=
 auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span=
 style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font=
-variant: normal; font-weight: normal; letter-spacing: normal; line-height:=
 normal; orphans: auto; text-align: start; text-indent: 0px; text-transform=
: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-=
stroke-width: 0px; float: none; display: inline !important;" class=3D"">&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;*pRet =3D -tmp;</span><br style=3D"font-family: Helvetica; font=
-size: 12px; font-style: normal; font-variant: normal; font-weight: normal;=
 letter-spacing: normal; line-height: normal; orphans: auto; text-align: st=
art; text-indent: 0px; text-transform: none; white-space: normal; widows: a=
uto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><br sty=
le=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-var=
iant: normal; font-weight: normal; letter-spacing: normal; line-height: nor=
mal; orphans: auto; text-align: start; text-indent: 0px; text-transform: no=
ne; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stro=
ke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; font-size=
: 12px; font-style: normal; font-variant: normal; font-weight: normal; lett=
er-spacing: normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: in=
line !important;" class=3D"">are instead forced to write:</span><br style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px;" class=3D""></div></blockquote></div><br class=3D""><div class=
=3D"">Referring to the site, the particular issue in question is =E2=80=9Cw=
hen you=20
attempt to perform a unary negation on a signed number, and that signed=20
number is a compile-time constant with a value of
 MIN_INT.=E2=80=9D (sic)</div><div class=3D""><br class=3D""></div><div cla=
ss=3D"">So, if the program depends on the number being actually negated, sq=
uelching the error with unsigned arithmetic is not the solution. The operat=
ion should be flagged. The library is in this case not =E2=80=9Cdetect[ing]=
 integral overflow at run time,=E2=80=9D for one of the main cases that wou=
ld be detected.</div><div class=3D""><br class=3D""></div><div class=3D"">W=
hat we need is a better way of flagging runtime UB at compile time, and les=
s thinking =E2=80=9Cthis program is valid as long as the defective part nev=
er runs.=E2=80=9D What we don=E2=80=99t need is more of =E2=80=9Cthe progra=
mmer probably just wants the two=E2=80=99s-complement bit-patterns,=E2=80=
=9D because that intrinsically covers up catchable errors.</div></body></ht=
ml>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_B5B5CC5E-5E82-4468-A0B0-BD19DE10BF07--

.

On Tue, Dec 16, 2014 at 3:44 AM, Howard Hinnant
<howard.hinnant@gmail.com> wrote:
> And people think this is a good thing?!

No, but the solution isn't defining signed overflow.
What's needed is better ways to detect overflow.


--
Olaf

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_1961_968377518.1418723339629
Content-Type: multipart/alternative;
 boundary="----=_Part_1962_1889868060.1418723339629"

------=_Part_1962_1889868060.1418723339629
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Le mardi 16 d=C3=A9cembre 2014 00:21:54 UTC+1, Howard Hinnant a =C3=A9crit =
:
>
> > Defining the semantics as reduction mod 2^n on overflow does a lot of=
=20
> harm,=20
>
> *Nobody* has proposed that.  The proposal on the table is *implementation=
=20
> defined*.  I.e. Attention compiler:  please stop throwing away my code.=
=20
>  Just let it do what the hardware does.=20
>


Implementation-defined behavior is "behavior, for a well-formed program=20
construct and correct data, that depends on the implementation and that=20
each implementation documents".

Unspecified behavior is "behavior, for a well-formed program construct and=
=20
correct data, that depends on the implementation [Note: The implementation=
=20
is not required to document which behavior occurs. The range of possible=20
behaviors is usually delineated by this Internation Standard. - end note]"

My perception is that the proposal has been "implementation defined" with=
=20
an assumption that the implementations they care about would define it to=
=20
be "wrap around" (e.g. wanting that i<i+1 is false when overflow occurs).

The issue is that people probably don't want to stop all optimizations,=20
just those which they consider as harmful.  I don't like at all simplifying=
=20
i++ !=3D INT_MAX to true, on the other hand I'm far more in favor or=20
simplifying (i*10)/5 to i*2. and I've not started to look at code motion=20
out of loop or strength reduction.  The POV of most optimizer people I know=
=20
is that thinking about "what the hardware does" is usually based on=20
simplistic assumptions about the mapping from language constructs to=20
machine instructions.  They don't really know how to have something=20
intermediate between "the behavior is defined to be this" and "all bets are=
=20
off", the "all bets are off" aspects coming often from interactions between=
=20
individually "sane" optimizations.

I think that my position is more on the line of "assume that int are=20
unbounded integers" than "assume that no value will overflow int=20
computations" but I don't know how to state it formally. (I've no issue=20
with simplifying i<i+1 to true but I've with back propagating information=
=20
that i < INT_MAX to previous statements).

(About unsigned wrap around, I remember a post by DMR on Usenet, sadly I=20
can't find it, stating that providing a type with guaranteed wrap around=20
was one of the reasons of the introduction of unsigned -- it was introduced=
=20
at the same time as the first porting effort of C to machines other than=20
PDP-11. For sure there has always been a tension between people thinking=20
unsigned was for Z/2^n and those who though it was for N, with resulting=20
inconsistencies)

Yours,

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_1962_1889868060.1418723339629
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>Le mardi 16 d=C3=A9cembre 2014 00:21:54 UTC+1, Howard =
Hinnant a =C3=A9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt=
; Defining the semantics as reduction mod 2^n on overflow does a lot of har=
m,
<br>
<br>*Nobody* has proposed that. &nbsp;The proposal on the table is *impleme=
ntation defined*. &nbsp;I.e. Attention compiler: &nbsp;please stop throwing=
 away my code. &nbsp;Just let it do what the hardware does.
<br></blockquote><div><br></div><div><br></div><div>Implementation-defined =
behavior is "behavior, for a well-formed&nbsp;program construct and correct=
 data, that depends on the implementation and that each implementation docu=
ments".</div><div><br></div><div>Unspecified behavior is "behavior, for a w=
ell-formed program construct and correct data, that depends on the implemen=
tation [Note: The implementation is not required to document which behavior=
 occurs. The range of possible behaviors is usually delineated by this Inte=
rnation Standard. - end note]"</div><div><br></div><div>My perception is th=
at the proposal has been "implementation defined" with an assumption that t=
he implementations they care about would define it to be "wrap around" (e.g=
.. wanting that i&lt;i+1 is false when overflow occurs).</div><div><br></div=
><div>The issue is that people probably don't want to stop all optimization=
s, just those which they consider as harmful. &nbsp;I don't like at all sim=
plifying i++ !=3D INT_MAX to true, on the other hand I'm far more in favor =
or simplifying (i*10)/5 to i*2. and I've not started to look at code motion=
 out of loop or strength reduction. &nbsp;The POV of most optimizer people =
I know is that thinking about "what the hardware does" is usually based on =
simplistic assumptions about the mapping from language constructs to machin=
e instructions. &nbsp;They don't really know how to have something intermed=
iate between "the behavior is defined to be this" and "all bets are off", t=
he "all bets are off" aspects coming often from interactions between indivi=
dually "sane" optimizations.</div><div><br></div><div>I think that my posit=
ion is more on the line of "assume that int are unbounded integers" than "a=
ssume that no value will overflow int computations" but I don't know how to=
 state it formally. (I've no issue with simplifying i&lt;i+1 to true but I'=
ve with back propagating information that i &lt; INT_MAX to previous statem=
ents).<br></div><div><br></div><div>(About unsigned wrap around, I remember=
 a post by DMR on Usenet, sadly I can't find it, stating that providing a t=
ype with guaranteed wrap around was one of the reasons of the introduction =
of unsigned -- it was introduced at the same time as the first porting effo=
rt of C to machines other than PDP-11. For sure there has always been a ten=
sion between people thinking unsigned was for Z/2^n and those who though it=
 was for N, with resulting inconsistencies)</div><div><br></div><div>Yours,=
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1962_1889868060.1418723339629--
------=_Part_1961_968377518.1418723339629--

.

------=_Part_102_941591060.1418724849956
Content-Type: multipart/alternative;
 boundary="----=_Part_103_513950677.1418724849956"

------=_Part_103_513950677.1418724849956
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le mardi 16 d=C3=A9cembre 2014 02:12:07 UTC+1, Myriachan a =C3=A9crit :
>
>
>>
> Why allow it to be undefined behavior? Trapping, wrapping and saturation=
=20
> seems like would cover everything.  Note that "trapping" is highly=20
> variable: Windows throws a catch()able exception, POSIX has SIGFPE,=20
> embedded systems could have an unhandled interrupt that goes to la-la lan=
d=20
> but is still a trap.
>

NaN result would also reasonable. =20

I wonder about an unspecified behavior between unspecified result (similar=
=20
to the content of an initialized variable, so a 10*x/5 simplified to 2*x=20
works as well as a NaN) or a trap.  But trapping has somewhat the=20
assumption that you can catch it -- you go to lala land only if you don't=
=20
-- and that you can detect that things occurring "before" the overflow have=
=20
happened and code motion (especially for loop) valid under the assumption=
=20
that the overflow doesn't occur can also trap at unexpected time.

Yours,

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_103_513950677.1418724849956
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Le mardi 16 d=C3=A9cembre 2014 02:12:07 UTC+1, Myriachan a=
 =C3=A9crit&nbsp;:<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"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div cla=
ss=3D"gmail_quote"><div><br></div></div></div></div></blockquote><div><br>W=
hy allow it to be undefined behavior? Trapping, wrapping and saturation see=
ms like would cover everything.&nbsp; Note that "trapping" is highly variab=
le: Windows throws a <span style=3D"font-family: 'courier new', monospace;"=
>catch()</span>able exception, POSIX has <span style=3D"font-family: 'couri=
er new', monospace;">SIGFPE</span>, embedded systems could have an unhandle=
d interrupt that goes to la-la land but is still a trap.</div></div></block=
quote><div><br></div><div>NaN result would also reasonable. &nbsp;</div><di=
v><br></div><div>I wonder about an unspecified behavior between unspecified=
 result (similar to the content of an initialized variable, so a 10*x/5 sim=
plified to 2*x works as well as a NaN) or a trap. &nbsp;But trapping has so=
mewhat the assumption that you can catch it -- you go to lala land only if =
you don't -- and that you can detect that things occurring "before" the ove=
rflow have happened and code motion (especially for loop) valid under the a=
ssumption that the overflow doesn't occur can also trap at unexpected time.=
</div><div><br></div><div>Yours,</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_103_513950677.1418724849956--
------=_Part_102_941591060.1418724849956--

.

On Dec 16, 2014, at 2:12 AM, David Krauss <potswa@gmail.com> wrote:

> So, if the program depends on the number being actually negated, squelchi=
ng the error with unsigned arithmetic is not the solution. The operation sh=
ould be flagged. The library is in this case not =E2=80=9Cdetect[ing] integ=
ral overflow at run time,=E2=80=9D for one of the main cases that would be =
detected.

You=E2=80=99re response is that SafeInt has a bug in it?  Did you test it? =
 When I did with this:

    SafeInt<int> i =3D std::numeric_limits<int>::min();
    i =3D -i;

my program terminated with:

libc++abi.dylib: terminating with uncaught exception of type SafeIntExcepti=
on

indicating that SafeInt performed as advertised.

Howard

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Dec 16, 2014, at 4:48 AM, Jean-Marc Bourguet <jm.bourguet@gmail.com> wro=
te:

> The issue is that people probably don't want to stop all optimizations, j=
ust those which they consider as harmful.=20

This is a good point.  I don=E2=80=99t care what the solution is, just as l=
ong as we improve the current situation.

Howard

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

El 16/12/2014 0:21, Howard Hinnant wrote:

>
> This is not a conclusion I could draw from my experience in the
> field.  I would estimate that these flags are not used much because
> most people don=E2=80=99t understand the need for or ramifications of hav=
ing
> to use them.
>
> *  Talks on undefined behavior draw large and interested crowds, and
> gasps of disbelief. *  SafeInt, not made by amateurs, recently
> updated for this very issue. *  It is easy to find overflow-checking
> code on SO which has undefined behavior.  It is also easy to find SO
> answers pointing out the undefined behavior.  The community is
> attempting to educate itself.
>
> Is the benefit of this optimization worth the risk of not having
> everyone sufficiently educated?

I think you hit the nail on the head.

But let me just make a comment: We could just make signed numbers=20
implementation defined, but in 99,99% of cases, trapping or throwing an=20
exception (which no one caches) with utilities like SafeInt will not=20
hide the fact that the code has a bug or a limitation. If the=20
application is not ready to continue, then it's better to terminate it=20
with some emergency cleanup code.

Even with unsigned numbers, if it wraparounds, the programmer has=20
ignored a limit, it's not prepared to deal with the fact that resources=20
are limited and the representation of a number is limited for good=20
reasons (like efficiency). So we still need education. And many times=20
we'll just ignore this limit because it's really hard to think about=20
failures every time you add two numbers.

The most elegant answer in any code would be to be able to gracefully=20
handle this limitation, the same way it is sometimes necessary to deal=20
with memory limitations: most people just assume it never fails, that an=20
application crash is a correct answer (the vast majority of=20
applications, I guess). In many other domains, we need to detect it=20
before it happens and handle it (say, a push_back() would overflow a the=20
size_type unsigned integer of a container).

Maybe it's time to both make signed arithmetic implementation defined=20
and design a standard library section about safe numbers ;-)

Best,

Ion

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 17 December 2014 at 00:30, Ion Gazta=C3=B1aga <igaztanaga@gmail.com> wro=
te:
>> Is the benefit of this optimization worth the risk of not having
>> everyone sufficiently educated?
> I think you hit the nail on the head.
> But let me just make a comment: We could just make signed numbers
> implementation defined, but in 99,99% of cases, trapping or throwing an
> exception (which no one caches) with utilities like SafeInt will not hide
> the fact that the code has a bug or a limitation. If the application is n=
ot
> ready to continue, then it's better to terminate it with some emergency
> cleanup code.

Sure, that would be better, but implementations "optimizing" the UB code
away can be MUCH worse than that.

> Even with unsigned numbers, if it wraparounds, the programmer has ignored=
 a
> limit, it's not prepared to deal with the fact that resources are limited
> and the representation of a number is limited for good reasons (like
> efficiency). So we still need education. And many times we'll just ignore

That wrap-around is used deliberately - it's not always a case of a program=
mer
ignoring a limit.

> The most elegant answer in any code would be to be able to gracefully han=
dle
> this limitation, the same way it is sometimes necessary to deal with memo=
ry
> limitations: most people just assume it never fails, that an application
> crash is a correct answer (the vast majority of applications, I guess). I=
n

I have found a decent minority of applications that handle memory allocatio=
n
failures successfully. Some of those run under resource limits, in which ca=
se
over-commits and such don't make the failures almost-impossible to detect
and handle.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

El 16/12/2014 23:39, Ville Voutilainen escribi=C3=B3:
>> Even with unsigned numbers, if it wraparounds, the programmer has ignore=
d a
>> limit, it's not prepared to deal with the fact that resources are limite=
d
>> and the representation of a number is limited for good reasons (like
>> efficiency). So we still need education. And many times we'll just ignor=
e
>
> That wrap-around is used deliberately - it's not always a case of a progr=
ammer
> ignoring a limit.

Sure. I just wanted to express that in my experience, and specially for=20
non-educated users, most wrap-around is not intentional. There are=20
compilers that trap this wraparounds in debug mode and require some=20
explicit notation to communicate that wraparound was intentional. Most=20
of use just ignore the problem. The idea of dealing with unbounded=20
numbers is so attractive and sometimes it only fails in 1 out of 2^32=20
cases... ;-)

Ion

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--001a1139511c42b17c050a5d56b6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 16 December 2014 at 16:46, Ion Gazta=C3=B1aga <igaztanaga@gmail.com> wro=
te:

> Sure. I just wanted to express that in my experience, and specially for
> non-educated users, most wrap-around is not intentional.


+1, which is why I don't think we should standardize this behavior.  The
few times someone intends to do this, they should have a different syntax
indicating that they really meant to do that and not just define the
behavior so that everybody falls into it, mostly unintentionally.

Of course, being undefined people fall into it anyway, but we can educate
people that "there be dragons, don't go there" and develop tools to help
mitigate it.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a1139511c42b17c050a5d56b6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On 16 December 2014 at 16:46, I=
on Gazta=C3=B1aga <span dir=3D"ltr">&lt;<a href=3D"mailto:igaztanaga@gmail.=
com" target=3D"_blank">igaztanaga@gmail.com</a>&gt;</span> wrote:<div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">Sure. I just wanted to expr=
ess that in my experience, and specially for non-educated users, most wrap-=
around is not intentional.</blockquote></div><br></div><div class=3D"gmail_=
extra">+1, which is why I don&#39;t think we should standardize this behavi=
or.=C2=A0 The few times someone intends to do this, they should have a diff=
erent syntax indicating that they really meant to do that and not just defi=
ne the behavior so that everybody falls into it, mostly unintentionally.<br=
><br></div><div class=3D"gmail_extra">Of course, being undefined people fal=
l into it anyway, but we can educate people that &quot;there be dragons, do=
n&#39;t go there&quot; and develop tools to help mitigate it.<br></div><div=
 class=3D"gmail_extra">-- <br><div class=3D"gmail_signature">=C2=A0Nevin &q=
uot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.c=
om" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404</=
div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1139511c42b17c050a5d56b6--

.

On Tuesday 16 December 2014 17:00:37 Nevin Liber wrote:
> > Sure. I just wanted to express that in my experience, and specially for
> > non-educated users, most wrap-around is not intentional.
>
> +1, which is why I don't think we should standardize this behavior.  The
> few times someone intends to do this, they should have a different syntax
> indicating that they really meant to do that and not just define the
> behavior so that everybody falls into it, mostly unintentionally.

That sounds like a sane proposal.

1) create a syntax for sane wraparound, which probably means implementation-
defined wrapping for signed integers

2) allow compilers to generate traps or diagnostics for unprotected over- or
underflows, including assuming "code never reaches here because programmer has
already fixed the issues" (i.e., unbounded arithmetic)

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--Apple-Mail=_56B069D9-5D0E-495B-8893-E6C1AE219885
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2014=E2=80=9312=E2=80=9316, at 9:30 PM, Howard Hinnant <howard.hinnant=
@gmail.com> wrote:
>=20
> On Dec 16, 2014, at 2:12 AM, David Krauss <potswa@gmail.com> wrote:
>=20
>> So, if the program depends on the number being actually negated, squelch=
ing the error with unsigned arithmetic is not the solution. The operation s=
hould be flagged. The library is in this case not =E2=80=9Cdetect[ing] inte=
gral overflow at run time,=E2=80=9D for one of the main cases that would be=
 detected.
>=20
> You=E2=80=99re response is that SafeInt has a bug in it?  Did you test it=
?  When I did with this:
>=20
>    SafeInt<int> i =3D std::numeric_limits<int>::min();
>    i =3D -i;
>=20
> my program terminated with:
>=20
> libc++abi.dylib: terminating with uncaught exception of type SafeIntExcep=
tion
>=20
> indicating that SafeInt performed as advertised.

Your previous message gave the impression that programmers are =E2=80=9Cfor=
ced=E2=80=9D to use SignedNegation instead of the unary minus operator, but=
 now you say the unary minus overload does the right thing after all. Forgi=
ve me for not being familiar with the library.

It sounds like you=E2=80=99re saying that the built-in unary minus should b=
ehave like SignedNegation, but that doesn=E2=80=99t sound right either. The=
 library isn=E2=80=99t well documented, but according to the few code comme=
nts (which provide the only documentation), SignedNegation is only a =E2=80=
=9Chelper class=E2=80=9D and not an API intended for direct use. Looking at=
 all usages of it in the library, it=E2=80=99s only ever applied when overf=
low is already precluded. Its name does not capture this precondition very =
well, making it less safe as an interface. Its true purpose is to generate =
most-negative values.

Furthermore, the implementation of SignedNegation is defective and produces=
 UB every time it attempts to generate a negative result. The final operati=
on it performs is an unsigned-to-signed cast, and that can never produce a =
negative number in a well-defined way. Using ~=E2=80=A6+1 instead of unary =
minus is just hocus-pocus which might at best confuse the optimizer into ig=
noring an optimization, but the optimization remains equally valid.

The correct definition of SignedNegation cannot be written without the tern=
ary operator, which is even weirder. I do think there should be a standard =
library function for this, but I don=E2=80=99t think it=E2=80=99s productiv=
e to implementation-specifically bless crazy tricks that currently work sem=
i-portably under UB.

(Also I doubt the library is as widely used as you say; the homepage appear=
s to say it=E2=80=99s been downloaded all of 60 times in about 6 years. It =
doesn=E2=80=99t claim to have been tested with -Wextra nor with the sanitiz=
ation that has recently been added to GCC and Clang.)

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_56B069D9-5D0E-495B-8893-E6C1AE219885
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2014=E2=80=9312=
=E2=80=9316, at 9:30 PM, Howard Hinnant &lt;<a href=3D"mailto:howard.hinnan=
t@gmail.com" class=3D"">howard.hinnant@gmail.com</a>&gt; wrote:</div><br cl=
ass=3D"Apple-interchange-newline"><div class=3D"">On Dec 16, 2014, at 2:12 =
AM, David Krauss &lt;<a href=3D"mailto:potswa@gmail.com" class=3D"">potswa@=
gmail.com</a>&gt; wrote:<br class=3D""><br class=3D""><blockquote type=3D"c=
ite" class=3D"">So, if the program depends on the number being actually neg=
ated, squelching the error with unsigned arithmetic is not the solution. Th=
e operation should be flagged. The library is in this case not =E2=80=9Cdet=
ect[ing] integral overflow at run time,=E2=80=9D for one of the main cases =
that would be detected.<br class=3D""></blockquote><br class=3D"">You=E2=80=
=99re response is that SafeInt has a bug in it? &nbsp;Did you test it? &nbs=
p;When I did with this:<br class=3D""><br class=3D""> &nbsp;&nbsp;&nbsp;Saf=
eInt&lt;int&gt; i =3D std::numeric_limits&lt;int&gt;::min();<br class=3D"">=
 &nbsp;&nbsp;&nbsp;i =3D -i;<br class=3D""><br class=3D"">my program termin=
ated with:<br class=3D""><br class=3D"">libc++abi.dylib: terminating with u=
ncaught exception of type SafeIntException<br class=3D""><br class=3D"">ind=
icating that SafeInt performed as advertised.<br class=3D""></div></blockqu=
ote></div><br class=3D""><div class=3D"">Your previous message gave the imp=
ression that programmers are =E2=80=9Cforced=E2=80=9D to use SignedNegation=
 instead of the unary minus operator, but now you say the unary minus overl=
oad does the right thing after all. Forgive me for not being familiar with =
the library.</div><div class=3D""><br class=3D""></div><div class=3D"">It s=
ounds like you=E2=80=99re saying that the built-in unary minus should behav=
e like SignedNegation, but that doesn=E2=80=99t sound right either. The lib=
rary isn=E2=80=99t well documented, but according to the few code comments =
(which provide the only documentation), SignedNegation is only a =E2=80=9Ch=
elper class=E2=80=9D and not an API intended for direct use. Looking at all=
 usages of it in the library, it=E2=80=99s only ever applied when overflow =
is already precluded. Its name does not capture this precondition very well=
, making it less safe as an interface. Its true purpose is to generate most=
-negative values.</div><div class=3D""><br class=3D""></div><div class=3D""=
>Furthermore, the implementation of SignedNegation is defective and produce=
s UB every time it attempts to generate a negative result. The final operat=
ion it performs is an unsigned-to-signed cast, and that can never produce a=
 negative number in a well-defined way. Using <font face=3D"Courier" class=
=3D"">~=E2=80=A6+1</font>&nbsp;instead of unary minus is just hocus-pocus w=
hich might at best confuse the optimizer into ignoring an optimization, but=
 the optimization remains equally valid.</div><div class=3D""><br class=3D"=
"></div><div class=3D"">The correct definition of SignedNegation cannot be =
written without the ternary operator, which is even weirder. I do think the=
re should be a standard library function for this, but I don=E2=80=99t thin=
k it=E2=80=99s productive to implementation-specifically bless crazy tricks=
 that currently work semi-portably under UB.</div><div class=3D""><br class=
=3D""></div><div class=3D"">(Also I doubt the library is as widely used as =
you say; the homepage appears to say it=E2=80=99s been downloaded all of 60=
 times in about 6 years. It doesn=E2=80=99t claim to have been tested with =
-Wextra nor with the sanitization that has recently been added to GCC and C=
lang.)</div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_56B069D9-5D0E-495B-8893-E6C1AE219885--

.

------=_Part_3521_838790080.1418782798434
Content-Type: multipart/alternative;
 boundary="----=_Part_3522_1462215652.1418782798434"

------=_Part_3522_1462215652.1418782798434
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, December 16, 2014 5:36:12 PM UTC-8, David Krauss wrote:
>
> Your previous message gave the impression that programmers are =E2=80=9Cf=
orced=E2=80=9D to=20
> use SignedNegation
>
>
I know that this sentence fragment isn't directly related, but there often=
=20
is a need to use exotic methods in order to avoid stepping on undefined=20
behavior.  Even if you use unsigned integers because you know about=20
undefined behavior with signed overflow, it's really easy to step on=20
undefined behavior due to signed overflow anyway, thanks to the promotion=
=20
rules.

std::uint16_t dead =3D UINT16_C(0xDEAD);
std::uint16_t beef =3D UINT16_C(0xBEEF);
// Undefined behavior on 32-bit platforms, but OK on all others.
dead *=3D beef;

Portably avoiding the problem requires considerable extra effort just to=20
take advantage of what should be a defined operation, since at first glance=
=20
they're all unsigned types:

std::uint16_t dead =3D UINT16_C(0xDEAD);
std::uint16_t beef =3D UINT16_C(0xBEEF);
dead =3D static_cast<std::uint16_t>(static_cast<std::make_unsigned_t<declty=
pe
(+dead)>>(dead) * beef);


Furthermore, the implementation of SignedNegation is defective and produces=
=20
> UB every time it attempts to generate a negative result. The final=20
> operation it performs is an unsigned-to-signed cast, and that can never=
=20
> produce a negative number in a well-defined way. Using ~=E2=80=A6+1 inste=
ad of=20
> unary minus is just hocus-pocus which might at best confuse the optimizer=
=20
> into ignoring an optimization, but the optimization remains equally valid=
..
>
>
Conversions from too-large unsigned integers to signed integers are=20
implementation-defined, not undefined, and the code even has a comment to=
=20
this dependency.  Quoting [conv.integral] of N4140:
=20

> 3. If the destination type is signed, the value is unchanged if it can be=
=20
> represented in the destination type (and bit-field width); otherwise, the=
=20
> value is implementation-defined.
>

Melissa

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_3522_1462215652.1418782798434
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, December 16, 2014 5:36:12 PM UTC-8, David Krau=
ss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wr=
ap:break-word">Your previous message gave the impression that programmers a=
re =E2=80=9Cforced=E2=80=9D to use SignedNegation<br><div><br></div></div><=
/blockquote><div><br>I know that this sentence fragment isn't directly rela=
ted, but there often is a need to use exotic methods in order to avoid step=
ping on undefined behavior.&nbsp; Even if you use unsigned integers because=
 you know about undefined behavior with signed overflow, it's really easy t=
o step on undefined behavior due to signed overflow anyway, thanks to the p=
romotion rules.<br><br><div class=3D"prettyprint" style=3D"background-color=
: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid=
; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by=
-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">uint=
16_t dead </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> UINT16=
_C</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #066;" class=3D"styled-by-prettify">0xDEAD</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>std</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">uint16_t beef </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> UINT16_C</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">0xBEEF</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #800;" class=3D"styled-by-pret=
tify">// Undefined behavior on 32-bit platforms, but OK on all others.</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>dead </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">*=3D</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> beef</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>Po=
rtably avoiding the problem requires considerable extra effort just to take=
 advantage of what should be a defined operation, since at first glance the=
y're all unsigned types:<br><br><div class=3D"prettyprint" style=3D"backgro=
und-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-sty=
le: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"=
styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">uint16_t dead </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> UINT16_C</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0xDEAD</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>std</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">uint16_t beef </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> UINT16_C</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">0xBEEF</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>dead </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">static_cast</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">uint16_t</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">static_cast</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">make_unsigned_t</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">decltype</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(+</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">dead</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">)&gt;&gt;(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">dead</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> beef</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><=
br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"wor=
d-wrap:break-word"><div></div><div>Furthermore, the implementation of Signe=
dNegation is defective and produces UB every time it attempts to generate a=
 negative result. The final operation it performs is an unsigned-to-signed =
cast, and that can never produce a negative number in a well-defined way. U=
sing <font face=3D"Courier">~=E2=80=A6+1</font>&nbsp;instead of unary minus=
 is just hocus-pocus which might at best confuse the optimizer into ignorin=
g an optimization, but the optimization remains equally valid.</div><div><b=
r></div></div></blockquote><div><br>Conversions from too-large unsigned int=
egers to signed integers are implementation-defined, not undefined, and the=
 code even has a comment to this dependency.&nbsp; Quoting [conv.integral] =
of N4140:<br>&nbsp;<br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; bord=
er-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_q=
uote">3. If the destination type is signed, the value is unchanged if it ca=
n be represented in the destination type (and bit-field width); otherwise, =
the value is implementation-defined.<br></blockquote></div><br>Melissa<br><=
/div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3522_1462215652.1418782798434--
------=_Part_3521_838790080.1418782798434--

.

On Dec 16, 2014, at 8:35 PM, David Krauss <potswa@gmail.com> wrote:

>=20
>> On 2014=E2=80=9312=E2=80=9316, at 9:30 PM, Howard Hinnant <howard.hinnan=
t@gmail.com> wrote:
>>=20
>> On Dec 16, 2014, at 2:12 AM, David Krauss <potswa@gmail.com> wrote:
>>=20
>>> So, if the program depends on the number being actually negated, squelc=
hing the error with unsigned arithmetic is not the solution. The operation =
should be flagged. The library is in this case not =E2=80=9Cdetect[ing] int=
egral overflow at run time,=E2=80=9D for one of the main cases that would b=
e detected.
>>=20
>> You=E2=80=99re response is that SafeInt has a bug in it?  Did you test i=
t?  When I did with this:
>>=20
>>    SafeInt<int> i =3D std::numeric_limits<int>::min();
>>    i =3D -i;
>>=20
>> my program terminated with:
>>=20
>> libc++abi.dylib: terminating with uncaught exception of type SafeIntExce=
ption
>>=20
>> indicating that SafeInt performed as advertised.
>=20
> Your previous message gave the impression that programmers are =E2=80=9Cf=
orced=E2=80=9D to use SignedNegation instead of the unary minus operator, b=
ut now you say the unary minus overload does the right thing after all. For=
give me for not being familiar with the library.

Forgive me as well.  I also am not intimately familiar with the SafeInt lib=
rary.  I wrote about all the information I had:

1.  I quoted their notes that they were forced to compute a 2=E2=80=99s com=
plement negation using bit-wise not and plus 1.
2.  I quoted their code where they indeed to what their comments said they =
needed to do.
3.  I tested their signed negation and confirmed that it does what is expec=
ted.
4.  Upon further review, I note that their negation-workaround is to suppor=
t their safe multiply operations.  And I assume that this is a correct and =
high performance implementation of their specification.

On Dec 16, 2014, at 9:19 PM, Myriachan <myriachan@gmail.com> wrote:

>=20
>> Furthermore, the implementation of SignedNegation is defective and produ=
ces UB every time it attempts to generate a negative result. The final oper=
ation it performs is an unsigned-to-signed cast, and that can never produce=
 a negative number in a well-defined way. Using ~=E2=80=A6+1 instead of una=
ry minus is just hocus-pocus which might at best confuse the optimizer into=
 ignoring an optimization, but the optimization remains equally valid.
>>=20
>>=20
> Conversions from too-large unsigned integers to signed integers are imple=
mentation-defined, not undefined, and the code even has a comment to this d=
ependency.  Quoting [conv.integral] of N4140:

Thank you Melissa.

On Dec 16, 2014, at 8:35 PM, David Krauss <potswa@gmail.com> wrote:

> Furthermore, the implementation of SignedNegation is defective and produc=
es UB every time it attempts to generate a negative result. The final opera=
tion it performs is an unsigned-to-signed cast, and that can never produce =
a negative number in a well-defined way. Using ~=E2=80=A6+1 instead of unar=
y minus is just hocus-pocus which might at best confuse the optimizer into =
ignoring an optimization, but the optimization remains equally valid.
>=20
> The correct definition of SignedNegation cannot be written without the te=
rnary operator, which is even weirder. I do think there should be a standar=
d library function for this, but I don=E2=80=99t think it=E2=80=99s product=
ive to implementation-specifically bless crazy tricks that currently work s=
emi-portably under UB.

What we appear to have here is:

1.  Experienced programmers writing an overflow-checking =E2=80=9Csafe libr=
ary=E2=80=9D.

2.  Either these programmers are doing everything correctly, but have to us=
e horribly complicated code to achieve their objective, or=E2=80=A6

3.  Despite being very experienced, trying very hard, and using horribly co=
mplicated code, they still fail to achieve their objective.

Either way, this looks bad for C++.  The language is so hard to use in this=
 department, very experienced programmers find it challenging, both to writ=
e the correct code, and even to review the code written by others and deter=
mine whether or not it is correct.


> (Also I doubt the library is as widely used as you say; the homepage appe=
ars to say it=E2=80=99s been downloaded all of 60 times in about 6 years. I=
t doesn=E2=80=99t claim to have been tested with -Wextra nor with the sanit=
ization that has recently been added to GCC and Clang.)

Correction, that is 60 times since 2014-12-03T03:00:00 (just shy of two wee=
ks =E2=80=94 or 4 to 5 times a day).  I=E2=80=99m unsure what time zone tha=
t time stamp is in, but I don=E2=80=99t really think it matters.  This libr=
ary has an extensive following within one of the biggest software companies=
 on the planet (Microsoft), and according to the change log in its comments=
, dates back over a decade.  And while I=E2=80=99ve been unable to locate i=
ts unit tests, the comments on the site indicate that extensive unit tests =
exist (I believe there is currently a distribution problem with the unit te=
sts).

I really do not think that attacking the competence of the authors of this =
library, nor the library=E2=80=99s quality, is productive.  This library is=
 a prime example of what high quality code can be expected to look like fro=
m authors not intimately involved in the C++ standardization process.  And =
what I see here is an arms race:

Library writers trying to make C++ safer with a minimum sacrifice of perfor=
mance, and in the process having to actively battle compiler optimizations =
that are thwarting their efforts in the name of doing the same.  The librar=
y writer and the compiler writer are working against each other.  And it is=
 an arms race, as to who can outsmart the other.

I=E2=80=99m not saying that the library writer is right nor that the compil=
er writer is right.  I=E2=80=99m saying that the current situation has devo=
lved into absurdity, and the place to fix it is in the standard.  The statu=
s-quo (the current standard) is obviously not working with respect to this =
issue.  My intuition is that the C++ language should allow the programmer u=
nfettered (high-performance) access to his hardware.  And his hardware is 9=
9.99% homogenous in this department.  This is a much better situation than =
3 or 4 decades ago.  Access to the machine (i.e. a portable assembly) is wh=
at made C better than everything else decades ago.  Access to the hardware =
is still key today.  And it is what SafeInt clearly demonstrates it is tryi=
ng to do.

Howard

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--001a1139511cdabe1e050a615e6e
Content-Type: text/plain; charset=UTF-8

On 16 December 2014 at 21:40, Howard Hinnant <howard.hinnant@gmail.com>
wrote:

> My intuition is that the C++ language should allow the programmer
> unfettered (high-performance) access to his hardware.


I agree.

What I disagree with is the assertion that this facility should be spelled
signed char, short, int, long or long long.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1139511cdabe1e050a615e6e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On 16 December 2014 at 21:40, H=
oward Hinnant <span dir=3D"ltr">&lt;<a href=3D"mailto:howard.hinnant@gmail.=
com" target=3D"_blank">howard.hinnant@gmail.com</a>&gt;</span> wrote:<br><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My intuition is tha=
t the C++ language should allow the programmer unfettered (high-performance=
) access to his hardware.=C2=A0</blockquote></div><br>I agree.</div><div cl=
ass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">What I disagree wi=
th is the assertion that this facility should be spelled signed char, short=
, int, long or long long.<br>-- <br><div class=3D"gmail_signature">=C2=A0Ne=
vin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@evilover=
lord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-=
1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1139511cdabe1e050a615e6e--

.

--001a113b5a643d948c050a64b25c
Content-Type: text/plain; charset=UTF-8

On 16 December 2014 at 21:49, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 16 December 2014 at 21:40, Howard Hinnant <howard.hinnant@gmail.com>
> wrote:
>
>> My intuition is that the C++ language should allow the programmer
>> unfettered (high-performance) access to his hardware.
>
>
> I agree.
>
> What I disagree with is the assertion that this facility should be spelled
> signed char, short, int, long or long long.
>

There are four scenarios:

(1)  I want my code as fast as possible when I avoid overflow.

(2)  I want my code to rollover on overflow.

(3)  I want my code to saturate on overflow.

(4).  I want my code to trap on overflow.

Since I don't see how to make (1) less error-prone, I would be happy if (1)
remained undefined and we had separate classes (possibly with some magic
compiler support) for (2), (3), and (4).

Just a thought,
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a113b5a643d948c050a64b25c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 16 December 2014 at 21:49, Nevin Liber <span dir=3D"ltr=
">&lt;<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evi=
loverlord.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><span class=3D"">On 16 December 2014 at 21:40, Howard Hin=
nant <span dir=3D"ltr">&lt;<a href=3D"mailto:howard.hinnant@gmail.com" targ=
et=3D"_blank">howard.hinnant@gmail.com</a>&gt;</span> wrote:<br><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">My intuition is that the C+=
+ language should allow the programmer unfettered (high-performance) access=
 to his hardware.=C2=A0</blockquote></div><br></span>I agree.</div><div cla=
ss=3D"gmail_extra"><br></div><div class=3D"gmail_extra">What I disagree wit=
h is the assertion that this facility should be spelled signed char, short,=
 int, long or long long.</div></div></blockquote><div><br></div><div>There =
are four scenarios:</div><div><br></div><div>(1) =C2=A0I want my code as fa=
st as possible when I avoid overflow.</div><div><br></div><div>(2) =C2=A0I =
want my code to rollover on overflow.</div><div><br></div><div>(3) =C2=A0I =
want my code to saturate on overflow.</div><div><br></div><div>(4).=C2=A0 I=
 want my code to trap on overflow.</div><div><br></div><div>Since I don&#39=
;t see how to make (1) less error-prone, I would be happy if (1) remained u=
ndefined and we had separate classes (possibly with some magic compiler sup=
port) for (2), (3), and (4).</div><div><br></div><div>Just a thought,</div>=
</div>-- <br><div class=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Lib=
er=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_bl=
ank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113b5a643d948c050a64b25c--

.

--Apple-Mail=_920F8790-2CDB-412C-A045-C11ED5DB4E3D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2014=E2=80=9312=E2=80=9317, at 11:40 AM, Howard Hinnant <howard.hinnan=
t@gmail.com> wrote:
>=20
> Forgive me as well.  I also am not intimately familiar with the SafeInt l=
ibrary.  I wrote about all the information I had:

Considering more information we might uncover, does the example support the=
 point?

> On Dec 16, 2014, at 9:19 PM, Myriachan <myriachan@gmail.com <mailto:myria=
chan@gmail.com>> wrote:
>=20
>> Furthermore, the implementation of SignedNegation is defective and produ=
ces UB every time it attempts to generate a negative result. The final oper=
ation it performs is an unsigned-to-signed cast, and that can never produce=
 a negative number in a well-defined way. Using ~=E2=80=A6+1 instead of una=
ry minus is just hocus-pocus which might at best confuse the optimizer into=
 ignoring an optimization, but the optimization remains equally valid.
>>=20
> Conversions from too-large unsigned integers to signed integers are imple=
mentation-defined, not undefined, and the code even has a comment to this d=
ependency.  Quoting [conv.integral] of N4140:

Fair enough. The comment in the code is attached to the AbsValueHelper clas=
s, which does mostly the same thing as SignedNegation, and isn=E2=80=99t qu=
ite as full-featured as its name suggests.

    static unsigned __int32 Abs( T t ) SAFEINT_NOTHROW
    {
        SAFEINT_ASSERT( t < 0 );
        return ~(unsigned __int32)t + 1;
    }

Still, the complement-plus-one is unnecessary because it is identical to th=
e negation of the unsigned variable. Given wraparound on unsigned-to-signed=
 conversion, the only hoop anyone might need to jump through is casting to =
unsigned before the negation.

y =3D - x; // UB if the arithmetic result cannot be represented.
y =3D - (unsigned) x; // as safe as SafeInt, no ~ or +1 needed.

However, SafeInt doesn=E2=80=99t even need to explicitly write such a cast =
because the intermediate results are already unsigned. The built-in unary n=
egation operator is just fine.

Reviewing the past revisions, the bug occurred when a signed input operand =
got negated in-place. The whole SignedNegation and AbsValueHelper deal is a=
n overcorrection.

> On 2014=E2=80=9312=E2=80=9317, at 11:40 AM, Howard Hinnant <howard.hinnan=
t@gmail.com> wrote:
>=20
> What we appear to have here is:
>=20
> 1.  Experienced programmers writing an overflow-checking =E2=80=9Csafe li=
brary=E2=80=9D.
>=20
> 2.  Either these programmers are doing everything correctly, but have to =
use horribly complicated code to achieve their objective, or=E2=80=A6
>=20
> 3.  Despite being very experienced, trying very hard, and using horribly =
complicated code, they still fail to achieve their objective.

or less dramatically, the code achieves its objectives, it=E2=80=99s a bit =
more convoluted than necessary, and the author (I only see one) is unintere=
sted in simplifying it. It reflects suboptimally on C++ because it wasn=E2=
=80=99t intended as an exemplary sample.

Besides the extra arithmetic, does it need to be wrapped in a class? Does a=
ny of it need to be templated?

> Either way, this looks bad for C++.  The language is so hard to use in th=
is department, very experienced programmers find it challenging, both to wr=
ite the correct code, and even to review the code written by others and det=
ermine whether or not it is correct.

Numerics is a tough field. It=E2=80=99s impossible to design the language t=
o be numerically safe, yet easy to use for everyday code written against th=
e assumption of no overflow.

Not all bugs are caught in review. From the look of it, they responded to a=
 bug report in a timely fashion.


>> (Also I doubt the library is as widely used as you say; the homepage app=
ears to say it=E2=80=99s been downloaded all of 60 times in about 6 years. =
It doesn=E2=80=99t claim to have been tested with -Wextra nor with the sani=
tization that has recently been added to GCC and Clang.)
>=20
> Correction, that is 60 times since 2014-12-03T03:00:00 (just shy of two w=
eeks =E2=80=94 or 4 to 5 times a day).  I=E2=80=99m unsure what time zone t=
hat time stamp is in, but I don=E2=80=99t really think it matters.  This li=
brary has an extensive following within one of the biggest software compani=
es on the planet (Microsoft), and according to the change log in its commen=
ts, dates back over a decade.  And while I=E2=80=99ve been unable to locate=
 its unit tests, the comments on the site indicate that extensive unit test=
s exist (I believe there is currently a distribution problem with the unit =
tests).

Suffice to say, it=E2=80=99s not Boost, which is what most folks are going =
to choose. Microsoft probably has a reason to roll their own, but most comp=
etent programmers do not.

> I really do not think that attacking the competence of the authors of thi=
s library, nor the library=E2=80=99s quality, is productive.  This library =
is a prime example of what high quality code can be expected to look like f=
rom authors not intimately involved in the C++ standardization process.  An=
d what I see here is an arms race:
>=20
> Library writers trying to make C++ safer with a minimum sacrifice of perf=
ormance, and in the process having to actively battle compiler optimization=
s that are thwarting their efforts in the name of doing the same.  The libr=
ary writer and the compiler writer are working against each other.  And it =
is an arms race, as to who can outsmart the other.

Overflow conditions by definition produce numerically invalid results. Ther=
e=E2=80=99s no safety to be had. Before SafeInt fixed this bug, it was usin=
g the unary minus operator to get a positive value, yet getting a negative =
one. By luck the subsequent cast to unsigned type restored the correct posi=
tive value.

The programmer, although competent, wrote a bug and failed to state the rig=
ht intention.

I do think we should have library routines for, among other things, the uns=
igned negative of a signed number and the signed negative of an unsigned nu=
mber. Implementation-specified behavior for all numeric overflows is the wr=
ong band-aid, and it=E2=80=99s not going to stop any arms race.

The purpose of writing sensible programs while avoiding the possibility of =
overflows is served by numeric libraries, of which SafeInt is one. Sensible=
 cautious programmers will take that path, no need to adjust the core langu=
age.

There are a lot of folks and a lot of code that depends specifically on two=
=E2=80=99s-complement with wraparound, e.g. if ( x + 5 < 0 ) instead of if =
( x >=3D INT_MAX - 5 ). We should find a consistent way to support that sor=
t of thing, perhaps with a pragma analogous to FP_CONTRACT. Implementation-=
defined behavior is too loose and hand-wavy, and prone to change at the imp=
lementer=E2=80=99s whim. Programmers who know what they want to express sho=
uld be given a way to express it explicitly.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_920F8790-2CDB-412C-A045-C11ED5DB4E3D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2014=E2=80=9312=
=E2=80=9317, at 11:40 AM, Howard Hinnant &lt;<a href=3D"mailto:howard.hinna=
nt@gmail.com" class=3D"">howard.hinnant@gmail.com</a>&gt; wrote:</div><br c=
lass=3D"Apple-interchange-newline"><div class=3D"">Forgive me as well. &nbs=
p;I also am not intimately familiar with the SafeInt library. &nbsp;I wrote=
 about all the information I had:</div></blockquote><div><br class=3D""></d=
iv><div>Considering more information we might uncover, does the example sup=
port the point?</div><div><br class=3D""></div><blockquote type=3D"cite" cl=
ass=3D""><div class=3D""><span style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; line-height: normal; orphans: auto; text-align: start; te=
xt-indent: 0px; text-transform: none; white-space: normal; widows: auto; wo=
rd-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inli=
ne !important;" class=3D"">On Dec 16, 2014, at 9:19 PM, Myriachan &lt;</spa=
n><a href=3D"mailto:myriachan@gmail.com" style=3D"font-family: Helvetica; f=
ont-size: 12px; font-style: normal; font-variant: normal; font-weight: norm=
al; letter-spacing: normal; line-height: normal; orphans: auto; text-align:=
 start; text-indent: 0px; text-transform: none; white-space: normal; widows=
: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">myri=
achan@gmail.com</a><span style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; letter-spaci=
ng: normal; line-height: normal; orphans: auto; text-align: start; text-ind=
ent: 0px; text-transform: none; white-space: normal; widows: auto; word-spa=
cing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !im=
portant;" class=3D"">&gt; wrote:</span><br style=3D"font-family: Helvetica;=
 font-size: 12px; font-style: normal; font-variant: normal; font-weight: no=
rmal; letter-spacing: normal; line-height: normal; orphans: auto; text-alig=
n: start; text-indent: 0px; text-transform: none; white-space: normal; wido=
ws: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><b=
r class=3D""></div></blockquote><div class=3D""><blockquote type=3D"cite" s=
tyle=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-v=
ariant: normal; font-weight: normal; letter-spacing: normal; line-height: n=
ormal; orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-st=
roke-width: 0px;" class=3D""><blockquote type=3D"cite" class=3D"">Furthermo=
re, the implementation of SignedNegation is defective and produces UB every=
 time it attempts to generate a negative result. The final operation it per=
forms is an unsigned-to-signed cast, and that can never produce a negative =
number in a well-defined way. Using ~=E2=80=A6+1 instead of unary minus is =
just hocus-pocus which might at best confuse the optimizer into ignoring an=
 optimization, but the optimization remains equally valid.<br class=3D""><b=
r class=3D""></blockquote>Conversions from too-large unsigned integers to s=
igned integers are implementation-defined, not undefined, and the code even=
 has a comment to this dependency. &nbsp;Quoting [conv.integral] of N4140:<=
br class=3D""></blockquote><br style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; line-height: normal; orphans: auto; text-align: start; te=
xt-indent: 0px; text-transform: none; white-space: normal; widows: auto; wo=
rd-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""></div><div cla=
ss=3D"">Fair enough. The comment in the code is attached to the AbsValueHel=
per class, which does mostly the same thing as SignedNegation, and isn=E2=
=80=99t quite as full-featured as its name suggests.</div><div class=3D""><=
br class=3D""></div><div class=3D""><div class=3D""><font face=3D"Courier" =
class=3D"">&nbsp; &nbsp; static unsigned __int32 Abs( T t ) SAFEINT_NOTHROW=
</font></div><div class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp=
; {</font></div><div class=3D""><font face=3D"Courier" class=3D"">&nbsp; &n=
bsp; &nbsp; &nbsp; SAFEINT_ASSERT( t &lt; 0 );</font></div><div class=3D"">=
<font face=3D"Courier" class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; return ~(unsi=
gned __int32)t + 1;</font></div><div class=3D""><font face=3D"Courier" clas=
s=3D"">&nbsp; &nbsp; }</font></div></div><div class=3D""><br class=3D""></d=
iv><div class=3D"">Still, the complement-plus-one is unnecessary because it=
 is identical to the negation of the unsigned variable. Given wraparound on=
 unsigned-to-signed conversion, the only hoop anyone might need to jump thr=
ough is casting to unsigned before the negation.</div><div class=3D""><br c=
lass=3D""></div><div class=3D""><font face=3D"Courier" class=3D"">y =3D - x=
; // UB if the arithmetic result cannot be represented.</font></div><div cl=
ass=3D""><font face=3D"Courier" class=3D"">y =3D - (unsigned) x; // as safe=
 as SafeInt, no ~ or +1 needed.</font></div><div class=3D""><br class=3D"">=
</div><div class=3D"">However, SafeInt doesn=E2=80=99t even need to explici=
tly write such a cast because the intermediate results are already unsigned=
.. The built-in unary negation operator is just fine.</div><div class=3D""><=
br class=3D""></div><div class=3D"">Reviewing the past revisions, the bug o=
ccurred when a signed input operand got negated in-place. The whole SignedN=
egation and AbsValueHelper deal is an overcorrection.</div><div class=3D"">=
<br class=3D""></div><div class=3D""><div class=3D""></div></div><blockquot=
e type=3D"cite" class=3D""><div class=3D""><div class=3D"">On 2014=E2=80=93=
12=E2=80=9317, at 11:40 AM, Howard Hinnant &lt;<a href=3D"mailto:howard.hin=
nant@gmail.com" class=3D"">howard.hinnant@gmail.com</a>&gt; wrote:</div><br=
 class=3D"Apple-interchange-newline"></div></blockquote><blockquote type=3D=
"cite" class=3D""><div class=3D""><span style=3D"font-family: Helvetica; fo=
nt-size: 12px; font-style: normal; font-variant: normal; font-weight: norma=
l; letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; widows:=
 auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; disp=
lay: inline !important;" class=3D"">What we appear to have here is:</span><=
br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fo=
nt-variant: normal; font-weight: normal; letter-spacing: normal; line-heigh=
t: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfo=
rm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tex=
t-stroke-width: 0px;" class=3D""><br style=3D"font-family: Helvetica; font-=
size: 12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: sta=
rt; text-indent: 0px; text-transform: none; white-space: normal; widows: au=
to; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span st=
yle=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-va=
riant: normal; font-weight: normal; letter-spacing: normal; line-height: no=
rmal; orphans: auto; text-align: start; text-indent: 0px; text-transform: n=
one; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-str=
oke-width: 0px; float: none; display: inline !important;" class=3D"">1. &nb=
sp;Experienced programmers writing an overflow-checking =E2=80=9Csafe libra=
ry=E2=80=9D.</span><br style=3D"font-family: Helvetica; font-size: 12px; fo=
nt-style: normal; font-variant: normal; font-weight: normal; letter-spacing=
: normal; line-height: normal; orphans: auto; text-align: start; text-inden=
t: 0px; text-transform: none; white-space: normal; widows: auto; word-spaci=
ng: 0px; -webkit-text-stroke-width: 0px;" class=3D""><br style=3D"font-fami=
ly: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; f=
ont-weight: normal; letter-spacing: normal; line-height: normal; orphans: a=
uto; text-align: start; text-indent: 0px; text-transform: none; white-space=
: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"=
 class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-st=
yle: normal; font-variant: normal; font-weight: normal; letter-spacing: nor=
mal; line-height: normal; orphans: auto; text-align: start; text-indent: 0p=
x; text-transform: none; white-space: normal; widows: auto; word-spacing: 0=
px; -webkit-text-stroke-width: 0px; float: none; display: inline !important=
;" class=3D"">2. &nbsp;Either these programmers are doing everything correc=
tly, but have to use horribly complicated code to achieve their objective, =
or=E2=80=A6</span><br style=3D"font-family: Helvetica; font-size: 12px; fon=
t-style: normal; font-variant: normal; font-weight: normal; letter-spacing:=
 normal; line-height: normal; orphans: auto; text-align: start; text-indent=
: 0px; text-transform: none; white-space: normal; widows: auto; word-spacin=
g: 0px; -webkit-text-stroke-width: 0px;" class=3D""><br style=3D"font-famil=
y: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; fo=
nt-weight: normal; letter-spacing: normal; line-height: normal; orphans: au=
to; text-align: start; text-indent: 0px; text-transform: none; white-space:=
 normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" =
class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-sty=
le: normal; font-variant: normal; font-weight: normal; letter-spacing: norm=
al; line-height: normal; orphans: auto; text-align: start; text-indent: 0px=
; text-transform: none; white-space: normal; widows: auto; word-spacing: 0p=
x; -webkit-text-stroke-width: 0px; float: none; display: inline !important;=
" class=3D"">3. &nbsp;Despite being very experienced, trying very hard, and=
 using horribly complicated code, they still fail to achieve their objectiv=
e.</span><br style=3D"font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; te=
xt-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -=
webkit-text-stroke-width: 0px;" class=3D""></div></blockquote><div><br clas=
s=3D""></div><div>or less dramatically, the code achieves its objectives, i=
t=E2=80=99s a bit more convoluted than necessary, and the author (I only se=
e one) is uninterested in simplifying it. It reflects suboptimally on C++ b=
ecause it wasn=E2=80=99t intended as an exemplary sample.</div><div><br cla=
ss=3D""></div><div>Besides the extra arithmetic, does it need to be wrapped=
 in a class? Does any of it need to be templated?</div><div><br class=3D"">=
</div><blockquote type=3D"cite" class=3D""><div class=3D""><span style=3D"f=
ont-family: Helvetica; font-size: 12px; font-style: normal; font-variant: n=
ormal; font-weight: normal; letter-spacing: normal; line-height: normal; or=
phans: auto; text-align: start; text-indent: 0px; text-transform: none; whi=
te-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-widt=
h: 0px; float: none; display: inline !important;" class=3D"">Either way, th=
is looks bad for C++. &nbsp;The language is so hard to use in this departme=
nt, very experienced programmers find it challenging, both to write the cor=
rect code, and even to review the code written by others and determine whet=
her or not it is correct.</span><br style=3D"font-family: Helvetica; font-s=
ize: 12px; font-style: normal; font-variant: normal; font-weight: normal; l=
etter-spacing: normal; line-height: normal; orphans: auto; text-align: star=
t; text-indent: 0px; text-transform: none; white-space: normal; widows: aut=
o; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""></div></b=
lockquote><div><br class=3D""></div><div>Numerics is a tough field. It=E2=
=80=99s impossible to design the language to be numerically safe, yet easy =
to use for everyday code written against the assumption of no overflow.</di=
v><div><br class=3D""></div><div>Not all bugs are caught in review. From th=
e look of it, they responded to a bug report in a timely fashion.</div><div=
><br class=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D""><=
div class=3D""><blockquote type=3D"cite" style=3D"font-family: Helvetica; f=
ont-size: 12px; font-style: normal; font-variant: normal; font-weight: norm=
al; letter-spacing: normal; line-height: normal; orphans: auto; text-align:=
 start; text-indent: 0px; text-transform: none; white-space: normal; widows=
: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">(Als=
o I doubt the library is as widely used as you say; the homepage appears to=
 say it=E2=80=99s been downloaded all of 60 times in about 6 years. It does=
n=E2=80=99t claim to have been tested with -Wextra nor with the sanitizatio=
n that has recently been added to GCC and Clang.)<br class=3D""></blockquot=
e><br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal;=
 font-variant: normal; font-weight: normal; letter-spacing: normal; line-he=
ight: normal; orphans: auto; text-align: start; text-indent: 0px; text-tran=
sform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-=
text-stroke-width: 0px;" class=3D""><span style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: nor=
mal; letter-spacing: normal; line-height: normal; orphans: auto; text-align=
: start; text-indent: 0px; text-transform: none; white-space: normal; widow=
s: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; di=
splay: inline !important;" class=3D"">Correction, that is 60 times since 20=
14-12-03T03:00:00 (just shy of two weeks =E2=80=94 or 4 to 5 times a day). =
&nbsp;I=E2=80=99m unsure what time zone that time stamp is in, but I don=E2=
=80=99t really think it matters. &nbsp;This library has an extensive follow=
ing within one of the biggest software companies on the planet (Microsoft),=
 and according to the change log in its comments, dates back over a decade.=
 &nbsp;And while I=E2=80=99ve been unable to locate its unit tests, the com=
ments on the site indicate that extensive unit tests exist (I believe there=
 is currently a distribution problem with the unit tests).</span><br style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px;" class=3D""></div></blockquote><div><br class=3D""></div><div>=
Suffice to say, it=E2=80=99s not Boost, which is what most folks are going =
to choose. Microsoft probably has a reason to roll their own, but most comp=
etent programmers do not.</div><div><br class=3D""></div><blockquote type=
=3D"cite" class=3D""><div class=3D""><span style=3D"font-family: Helvetica;=
 font-size: 12px; font-style: normal; font-variant: normal; font-weight: no=
rmal; letter-spacing: normal; line-height: normal; orphans: auto; text-alig=
n: start; text-indent: 0px; text-transform: none; white-space: normal; wido=
ws: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; d=
isplay: inline !important;" class=3D"">I really do not think that attacking=
 the competence of the authors of this library, nor the library=E2=80=99s q=
uality, is productive. &nbsp;This library is a prime example of what high q=
uality code can be expected to look like from authors not intimately involv=
ed in the C++ standardization process. &nbsp;And what I see here is an arms=
 race:</span><br style=3D"font-family: Helvetica; font-size: 12px; font-sty=
le: normal; font-variant: normal; font-weight: normal; letter-spacing: norm=
al; line-height: normal; orphans: auto; text-align: start; text-indent: 0px=
; text-transform: none; white-space: normal; widows: auto; word-spacing: 0p=
x; -webkit-text-stroke-width: 0px;" class=3D""><br style=3D"font-family: He=
lvetica; font-size: 12px; font-style: normal; font-variant: normal; font-we=
ight: normal; letter-spacing: normal; line-height: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=
=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-style: n=
ormal; font-variant: normal; font-weight: normal; letter-spacing: normal; l=
ine-height: normal; orphans: auto; text-align: start; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -w=
ebkit-text-stroke-width: 0px; float: none; display: inline !important;" cla=
ss=3D"">Library writers trying to make C++ safer with a minimum sacrifice o=
f performance, and in the process having to actively battle compiler optimi=
zations that are thwarting their efforts in the name of doing the same. &nb=
sp;The library writer and the compiler writer are working against each othe=
r. &nbsp;And it is an arms race, as to who can outsmart the other.</span><b=
r style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fon=
t-variant: normal; font-weight: normal; letter-spacing: normal; line-height=
: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfor=
m: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text=
-stroke-width: 0px;" class=3D""></div></blockquote><div><br class=3D""></di=
v><div>Overflow conditions by definition produce numerically invalid result=
s. There=E2=80=99s no safety to be had. Before SafeInt fixed this bug, it w=
as using the unary minus operator to get a positive value, yet getting a ne=
gative one. By luck the subsequent cast to unsigned type restored the corre=
ct positive value.</div><div><br class=3D""></div><div>The programmer, alth=
ough competent, wrote a bug and failed to state the right intention.</div><=
div><br class=3D""></div><div>I do think we should have library routines fo=
r, among other things, the unsigned negative of a signed number and the sig=
ned negative of an unsigned number. Implementation-specified behavior for a=
ll numeric overflows is the wrong band-aid, and it=E2=80=99s not going to s=
top any arms race.</div><div><br class=3D""></div><div>The purpose of writi=
ng sensible programs while avoiding the possibility of overflows is served =
by numeric libraries, of which SafeInt is one. Sensible cautious programmer=
s will take that path, no need to adjust the core language.</div><div><br c=
lass=3D""></div><div>There are a lot of folks and a lot of code that depend=
s specifically on two=E2=80=99s-complement with wraparound, e.g. <font face=
=3D"Courier" class=3D"">if ( x + 5 &lt; 0 )</font> instead of <font face=3D=
"Courier" class=3D"">if ( x &gt;=3D INT_MAX - 5 )</font>. We should find a =
consistent way to support that sort of thing, perhaps with a pragma analogo=
us to <font face=3D"Courier" class=3D"">FP_CONTRACT</font>. Implementation-=
defined behavior is too loose and hand-wavy, and prone to change at the imp=
lementer=E2=80=99s whim. Programmers who know what they want to express sho=
uld be given a way to express it explicitly.</div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_920F8790-2CDB-412C-A045-C11ED5DB4E3D--

.

------=_Part_3814_2000358204.1418801741224
Content-Type: multipart/alternative;
 boundary="----=_Part_3815_1163840843.1418801741224"

------=_Part_3815_1163840843.1418801741224
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Wednesday, December 17, 2014 4:40:44 PM UTC+13, Howard Hinnant wrote:
<snip>=20

> I really do not think that attacking the competence of the authors of thi=
s=20
> library, nor the library=E2=80=99s quality, is productive.  This library =
is a prime=20
> example of what high quality code can be expected to look like from autho=
rs=20
> not intimately involved in the C++ standardization process.  And what I s=
ee=20
> here is an arms race:=20
>
> Library writers trying to make C++ safer with a minimum sacrifice of=20
> performance, and in the process having to actively battle compiler=20
> optimizations that are thwarting their efforts in the name of doing the=
=20
> same.  The library writer and the compiler writer are working against eac=
h=20
> other.  And it is an arms race, as to who can outsmart the other.=20
>
> I=E2=80=99m not saying that the library writer is right nor that the comp=
iler=20
> writer is right.  I=E2=80=99m saying that the current situation has devol=
ved into=20
> absurdity, and the place to fix it is in the standard.  The status-quo (t=
he=20
> current standard) is obviously not working with respect to this issue.  M=
y=20
> intuition is that the C++ language should allow the programmer unfettered=
=20
> (high-performance) access to his hardware.  And his hardware is 99.99%=20
> homogenous in this department.  This is a much better situation than 3 or=
 4=20
> decades ago.  Access to the machine (i.e. a portable assembly) is what ma=
de=20
> C better than everything else decades ago.  Access to the hardware is sti=
ll=20
> key today.  And it is what SafeInt clearly demonstrates it is trying to d=
o.=20
>
> Howard=20
>
>
Very well put. 100% agree.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_3815_1163840843.1418801741224
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, December 17, 2014 4:40:44 PM UTC+13,=
 Howard Hinnant wrote:<div>&lt;snip&gt;&nbsp;</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-lef=
t-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: sol=
id;">I really do not think that attacking the competence of the authors of =
this library, nor the library=E2=80=99s quality, is productive. &nbsp;This =
library is a prime example of what high quality code can be expected to loo=
k like from authors not intimately involved in the C++ standardization proc=
ess. &nbsp;And what I see here is an arms race:
<br>
<br>Library writers trying to make C++ safer with a minimum sacrifice of pe=
rformance, and in the process having to actively battle compiler optimizati=
ons that are thwarting their efforts in the name of doing the same. &nbsp;T=
he library writer and the compiler writer are working against each other. &=
nbsp;And it is an arms race, as to who can outsmart the other.
<br>
<br>I=E2=80=99m not saying that the library writer is right nor that the co=
mpiler writer is right. &nbsp;I=E2=80=99m saying that the current situation=
 has devolved into absurdity, and the place to fix it is in the standard. &=
nbsp;The status-quo (the current standard) is obviously not working with re=
spect to this issue. &nbsp;My intuition is that the C++ language should all=
ow the programmer unfettered (high-performance) access to his hardware. &nb=
sp;And his hardware is 99.99% homogenous in this department. &nbsp;This is =
a much better situation than 3 or 4 decades ago. &nbsp;Access to the machin=
e (i.e. a portable assembly) is what made C better than everything else dec=
ades ago. &nbsp;Access to the hardware is still key today. &nbsp;And it is =
what SafeInt clearly demonstrates it is trying to do.
<br>
<br>Howard
<br>
<br></blockquote><div><br></div><div>Very well put. 100% agree.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3815_1163840843.1418801741224--
------=_Part_3814_2000358204.1418801741224--

.

El 17/12/2014 8:47, Nevin Liber escribi=C3=B3:

>
> There are four scenarios:
>
> (1)  I want my code as fast as possible when I avoid overflow.
>
> (2)  I want my code to rollover on overflow.
>
> (3)  I want my code to saturate on overflow.
>
> (4).  I want my code to trap on overflow.

Nice summary. I'd add a fifth one:

(5).  I want standard utilities to detect overflow/UB before executing=20
the operation. That way I can decide how to handle the issue.

Best,

Ion

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_323_1705385788.1418844154983
Content-Type: multipart/alternative;
 boundary="----=_Part_324_2102186054.1418844154983"

------=_Part_324_2102186054.1418844154983
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, December 17, 2014 1:00:10 AM UTC-8, David Krauss wrote:
>
> Still, the complement-plus-one is unnecessary because it is identical to=
=20
> the negation of the unsigned variable. Given wraparound on=20
> unsigned-to-signed conversion, the only hoop anyone might need to jump=20
> through is casting to unsigned before the negation.
>
> y =3D - x; // UB if the arithmetic result cannot be represented.
> y =3D - (unsigned) x; // as safe as SafeInt, no ~ or +1 needed.
>
>
If you're willing to deal with the compiler warnings that most compilers=20
will give you, yes, that works.  Avoiding compiler warnings requires=20
subtracting from zero:

y =3D 0u - (unsigned) x;

You're right that this is a better way, since compilers are smart enough to=
=20
use "neg eax" here.  ~x + 1 will NOT/XOR then add.


However, SafeInt doesn=E2=80=99t even need to explicitly write such a cast =
because=20
> the intermediate results are already unsigned. The built-in unary negatio=
n=20
> operator is just fine.
>
>
T can be a signed type.  I disagree with the design of their interface, but=
=20
it works.

=20

> Besides the extra arithmetic, does it need to be wrapped in a class? Does=
=20
> any of it need to be templated?
>
>
Wrapping in a class imparts a ton of performance issues.  I don't know of a=
=20
compiler that will treat a boxed integer as always an integer, and always=
=20
store the whole thing in registers.

Additionally, class semantics are subtly different than integer semantics,=
=20
even if you use overloaded operators everywhere.  Let's say that "x" is a=
=20
user-defined literal for wrapped_integer:

wrapped_integer *p =3D ...;
bool result =3D !p || *p;  // take advantage of implicit cast to bool

Except that this crashes/causes UB if p is null, since overloaded ||=20
doesn't short-circuit.
=20

> Either way, this looks bad for C++.  The language is so hard to use in=20
> this department, very experienced programmers find it challenging, both t=
o=20
> write the correct code, and even to review the code written by others and=
=20
> determine whether or not it is correct.
>
>
> Numerics is a tough field. It=E2=80=99s impossible to design the language=
 to be=20
> numerically safe, yet easy to use for everyday code written against the=
=20
> assumption of no overflow.
>
> Not all bugs are caught in review. From the look of it, they responded to=
=20
> a bug report in a timely fashion.
>
>
The competing languages have well-defined overflow handling and they seem=
=20
fine.  It's pretty much wrap, trap or arbitrary value among the popular=20
languages:

D: Wraps
C#: Wraps; has a way to trap in a block of code
Java: Wraps
Visual Basic (classic and .NET): Traps
Perl: Number becomes floating-point (eww)
PHP: Number becomes floating-point
Python: N/A; arbitrary-precision
Ruby: N/A; arbitrary-precision
Lua: N/A; integers were always floating-point
Swift: Wraps or traps at programmer's choice via choice of operator
Objective-C: Undefined, but inherited from C

Of these, only Objective C considers it undefined.

C is supposed to be a language closer to the hardware, yet it's a language=
=20
that is *further* from the hardware than C# or Java for something as basic=
=20
as integer math.

Overflow conditions by definition produce numerically invalid results.=20
> There=E2=80=99s no safety to be had. Before SafeInt fixed this bug, it wa=
s using=20
> the unary minus operator to get a positive value, yet getting a negative=
=20
> one. By luck the subsequent cast to unsigned type restored the correct=20
> positive value.
>
> The programmer, although competent, wrote a bug and failed to state the=
=20
> right intention.
>
> I do think we should have library routines for, among other things, the=
=20
> unsigned negative of a signed number and the signed negative of an unsign=
ed=20
> number. Implementation-specified behavior for all numeric overflows is th=
e=20
> wrong band-aid, and it=E2=80=99s not going to stop any arms race.
>
>
A multiply for unsigned types that won't mysteriously and=20
platform-dependently be undefined on you would be nice.

Melissa

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_324_2102186054.1418844154983
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, December 17, 2014 1:00:10 AM UTC-8, David Kr=
auss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-=
wrap:break-word"><font face=3D"Courier"></font>Still, the complement-plus-o=
ne is unnecessary because it is identical to the negation of the unsigned v=
ariable. Given wraparound on unsigned-to-signed conversion, the only hoop a=
nyone might need to jump through is casting to unsigned before the negation=
..<div><div><br></div><div><font face=3D"Courier">y =3D - x; // UB if the ar=
ithmetic result cannot be represented.</font></div><div><font face=3D"Couri=
er">y =3D - (unsigned) x; // as safe as SafeInt, no ~ or +1 needed.</font><=
/div><div><br></div></div></div></blockquote><div><br>If you're willing to =
deal with the compiler warnings that most compilers will give you, yes, tha=
t works.&nbsp; Avoiding compiler warnings requires subtracting from zero:<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: #000;" class=3D"styled-by-prettify">y </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">0u</span><span style=3D"colo=
r: #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"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">unsigned</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code><=
/div><br>You're right that this is a better way, since compilers are smart =
enough to use "neg eax" here.&nbsp; ~x + 1 will NOT/XOR then add.<br><br><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wra=
p:break-word"><div><div></div><div>However, SafeInt doesn=E2=80=99t even ne=
ed to explicitly write such a cast because the intermediate results are alr=
eady unsigned. The built-in unary negation operator is just fine.</div><div=
><br></div></div></div></blockquote><div><br>T can be a signed type.&nbsp; =
I disagree with the design of their interface, but it works.<br><br>&nbsp;<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:b=
reak-word"><div><div></div><div>Besides the extra arithmetic, does it need =
to be wrapped in a class? Does any of it need to be templated?</div><div><b=
r></div></div></div></blockquote><div><br>Wrapping in a class imparts a ton=
 of performance issues.&nbsp; I don't know of a compiler that will treat a =
boxed integer as always an integer, and always store the whole thing in reg=
isters.<br><br>Additionally, class semantics are subtly different than inte=
ger semantics, even if you use overloaded operators everywhere.&nbsp; Let's=
 say that "x" is a user-defined literal for wrapped_integer:<br><br><div cl=
ass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-c=
olor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap=
: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">wrapped_integer </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">p </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">...;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">bool</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> result </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">!</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">p </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">||</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">p</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> &nbsp;</span><span style=3D"color: #800;" class=3D"styled-by-pr=
ettify">// take advantage of implicit cast to bool</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>E=
xcept that this crashes/causes UB if <span style=3D"font-family: courier ne=
w,monospace;">p</span> is null, since overloaded <span style=3D"font-family=
: courier new,monospace;">||</span> doesn't short-circuit.<br>&nbsp;</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-w=
ord"><div><div></div><blockquote type=3D"cite"><div><span style=3D"font-fam=
ily:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-wei=
ght:normal;letter-spacing:normal;line-height:normal;text-align:start;text-i=
ndent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:non=
e;display:inline!important">Either way, this looks bad for C++. &nbsp;The l=
anguage is so hard to use in this department, very experienced programmers =
find it challenging, both to write the correct code, and even to review the=
 code written by others and determine whether or not it is correct.</span><=
br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-var=
iant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;tex=
t-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px"></div></blockquote><div><br></div><div>Numerics is a tough fiel=
d. It=E2=80=99s impossible to design the language to be numerically safe, y=
et easy to use for everyday code written against the assumption of no overf=
low.</div><div><br></div><div>Not all bugs are caught in review. From the l=
ook of it, they responded to a bug report in a timely fashion.</div><div><b=
r></div></div></div></blockquote><div><br>The competing languages have well=
-defined overflow handling and they seem fine.&nbsp; It's pretty much wrap,=
 trap or arbitrary value among the popular languages:<br><br>D: Wraps<br>C#=
: Wraps; has a way to trap in a block of code<br>Java: Wraps<br>Visual Basi=
c (classic and .NET): Traps<br>Perl: Number becomes floating-point (eww)<br=
>PHP: Number becomes floating-point<br>Python: N/A; arbitrary-precision<br>=
Ruby: N/A; arbitrary-precision<br>Lua: N/A; integers were always floating-p=
oint<br>Swift: Wraps or traps at programmer's choice via choice of operator=
<br>Objective-C: Undefined, but inherited from C<br><br>Of these, only Obje=
ctive C considers it undefined.<br><br>C is supposed to be a language close=
r to the hardware, yet it's a language that is <i>further</i> from the hard=
ware than C# or Java for something as basic as integer math.<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;"><div style=3D"word-wrap:break-w=
ord"><div><div></div>Overflow conditions by definition produce numerically =
invalid results. There=E2=80=99s no safety to be had. Before SafeInt fixed =
this bug, it was using the unary minus operator to get a positive value, ye=
t getting a negative one. By luck the subsequent cast to unsigned type rest=
ored the correct positive value.<div><br></div><div>The programmer, althoug=
h competent, wrote a bug and failed to state the right intention.</div><div=
><br></div><div>I do think we should have library routines for, among other=
 things, the unsigned negative of a signed number and the signed negative o=
f an unsigned number. Implementation-specified behavior for all numeric ove=
rflows is the wrong band-aid, and it=E2=80=99s not going to stop any arms r=
ace.</div><div><br></div></div></div></blockquote><div><br>A multiply for u=
nsigned types that won't mysteriously and platform-dependently be undefined=
 on you would be nice.</div><br>Melissa<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_324_2102186054.1418844154983--
------=_Part_323_1705385788.1418844154983--

.

On 2014-12-17 14:22, Myriachan wrote:
> Additionally, class semantics are subtly different than integer semantics,
> even if you use overloaded operators everywhere.  Let's say that "x" is a
> user-defined literal for wrapped_integer:
>
> wrapped_integer *p = ...;
> bool result = !p || *p;  // take advantage of implicit cast to bool
>
> Except that this crashes/causes UB if p is null, since overloaded ||
> doesn't short-circuit.

Um... why would you overload operator|| here? I'd expect the above to
use wrapped_integer::operator!, wrapped_integer::operator bool (or
operator int, or...), and built-in operator||.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--Apple-Mail=_AF1D1C24-071F-4A2E-848C-C6001AD0DFDC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2014=E2=80=9312=E2=80=9318, at 3:22 AM, Myriachan <myriachan@gmail.com=
> wrote:
>=20
> On Wednesday, December 17, 2014 1:00:10 AM UTC-8, David Krauss wrote:
>=20
> However, SafeInt doesn=E2=80=99t even need to explicitly write such a cas=
t because the intermediate results are already unsigned. The built-in unary=
 negation operator is just fine.
>=20
> T can be a signed type.  I disagree with the design of their interface, b=
ut it works.

For AbsValueHelper, yes, but this discussion was originally about SignedNeg=
ation. The declaration of the parameter type of AbsValueHelper is behind a =
mess of metaprogramming, and given that (and the constraint about silencing=
 all warnings) I think the explicit cast is quite reasonable.

> Besides the extra arithmetic, does it need to be wrapped in a class? Does=
 any of it need to be templated?
>=20
> Wrapping in a class imparts a ton of performance issues.  I don't know of=
 a compiler that will treat a boxed integer as always an integer, and alway=
s store the whole thing in registers.

I was referring to the class templates like AbsValueHelper and SignedNegati=
on. They only contain static member functions, not any state.
=20
> Numerics is a tough field. It=E2=80=99s impossible to design the language=
 to be numerically safe, yet easy to use for everyday code written against =
the assumption of no overflow.
>=20
> Not all bugs are caught in review. From the look of it, they responded to=
 a bug report in a timely fashion.
>=20
> The competing languages have well-defined overflow handling and they seem=
 fine.  It's pretty much wrap, trap or arbitrary value among the popular la=
nguages:

Note that none of the languages makes it implementation-defined, except for=
 C and C++ which allow implementation variance under undefined behavior.

The majority opinion there is actually to abandon integer semantics entirel=
y. A survey isn=E2=80=99t really appropriate. However, Microsoft and Apple =
seem to have agreed to give programmers the ability to opt-in to trapping. =
I think scoped constructs and pragmas deserve more attention, rather than a=
djusting the language uniformly.

Also, =E2=80=9Cwell-defined overflow handling=E2=80=9D is not the same as h=
elping to catch bugs in code review or in testing. There=E2=80=99s a fallac=
y there that more specification (anything!) will improve all issues relatin=
g to the underspecification.

> C is supposed to be a language closer to the hardware, yet it's a languag=
e that is further from the hardware than C# or Java for something as basic =
as integer math.

Unsigned types portably implement wraparound without overhead. Signed types=
 unportably implement wraparound but never introduce overhead. I don=E2=80=
=99t see how that=E2=80=99s getting further from hardware, nor how implemen=
tation-definedness will improve anything. Yes, side effects may be guarante=
ed to happen (depending on standardese in [intro] =C2=A71) before everythin=
g is allowed to go haywire (unexpected trap or nonsense value).

The language doesn=E2=80=99t officially support adding two positive numbers=
 and getting a negative number, but there=E2=80=99s no sacrifice in efficie=
ncy. In most cases that=E2=80=99s not a sensible result, whatever the ALU f=
lag bits say. It=E2=80=99s better to let it be detected by tools somehow, s=
ometimes, without making trapping part of the program=E2=80=99s behavior. T=
he only problem right now is that such tools aren=E2=80=99t yet as widespre=
ad as they should be, but they=E2=80=99re already freely available.

> A multiply for unsigned types that won't mysteriously and platform-depend=
ently be undefined on you would be nice.

The built-in multiplication operator for unsigned types already satisfies t=
his. See the footnote to =C2=A73.9.1/4.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_AF1D1C24-071F-4A2E-848C-C6001AD0DFDC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2014=E2=80=9312=
=E2=80=9318, at 3:22 AM, Myriachan &lt;<a href=3D"mailto:myriachan@gmail.co=
m" class=3D"">myriachan@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-in=
terchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">On Wednesday=
, December 17, 2014 1:00:10 AM UTC-8, David Krauss wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word" class=3D"">=
<font face=3D"Courier" class=3D""></font></div></blockquote><div class=3D""=
><br class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div sty=
le=3D"word-wrap:break-word" class=3D""><div class=3D""><div class=3D""></di=
v><div class=3D"">However, SafeInt doesn=E2=80=99t even need to explicitly =
write such a cast because the intermediate results are already unsigned. Th=
e built-in unary negation operator is just fine.</div></div></div></blockqu=
ote><div class=3D""><br class=3D"">T can be a signed type.&nbsp; I disagree=
 with the design of their interface, but it works.<br class=3D""></div></di=
v></div></blockquote><div><br class=3D""></div><div>For AbsValueHelper, yes=
, but this discussion was originally about SignedNegation. The declaration =
of the parameter type of AbsValueHelper is behind a mess of metaprogramming=
, and given that (and the constraint about silencing all warnings) I think =
the explicit cast is quite reasonable.</div><br class=3D""><blockquote type=
=3D"cite" class=3D""><div dir=3D"ltr" class=3D""><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div style=3D"word-wrap:break-word" class=3D""><div clas=
s=3D""><div class=3D""></div><div class=3D"">Besides the extra arithmetic, =
does it need to be wrapped in a class? Does any of it need to be templated?=
</div></div></div></blockquote><div class=3D""><br class=3D"">Wrapping in a=
 class imparts a ton of performance issues.&nbsp; I don't know of a compile=
r that will treat a boxed integer as always an integer, and always store th=
e whole thing in registers.<br class=3D""></div></div></blockquote><div><br=
 class=3D""></div><div>I was referring to the class templates like AbsValue=
Helper and&nbsp;SignedNegation. They only contain static member functions, =
not any state.</div></div><div>&nbsp;<br class=3D""><blockquote type=3D"cit=
e" class=3D""><div dir=3D"ltr" class=3D""><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div style=3D"word-wrap:break-word" class=3D""><div class=3D"">=
<div class=3D""></div><div class=3D"">Numerics is a tough field. It=E2=80=
=99s impossible to design the language to be numerically safe, yet easy to =
use for everyday code written against the assumption of no overflow.</div><=
div class=3D""><br class=3D""></div><div class=3D"">Not all bugs are caught=
 in review. From the look of it, they responded to a bug report in a timely=
 fashion.</div></div></div></blockquote><div class=3D""><br class=3D"">The =
competing languages have well-defined overflow handling and they seem fine.=
&nbsp; It's pretty much wrap, trap or arbitrary value among the popular lan=
guages:<br class=3D""></div></div></blockquote><div><br class=3D""></div><d=
iv>Note that none of the languages makes it implementation-defined, except =
for C and C++ which allow implementation variance under undefined behavior.=
</div><div><br class=3D""></div><div>The majority opinion there is actually=
 to abandon integer semantics entirely. A survey isn=E2=80=99t really appro=
priate. However, Microsoft and Apple seem to have agreed to give programmer=
s the ability to opt-in to trapping. I think scoped constructs and pragmas =
deserve more attention, rather than adjusting the language uniformly.</div>=
<div><br class=3D""></div><div>Also, =E2=80=9Cwell-defined overflow handlin=
g=E2=80=9D is not the same as helping to catch bugs in code review or in te=
sting. There=E2=80=99s a fallacy there that more specification (anything!) =
will improve all issues relating to the underspecification.</div><br class=
=3D""><blockquote type=3D"cite" class=3D""><div dir=3D"ltr" class=3D""><div=
 class=3D"">C is supposed to be a language closer to the hardware, yet it's=
 a language that is <i class=3D"">further</i> from the hardware than C# or =
Java for something as basic as integer math.<br class=3D""></div></div></bl=
ockquote><div><br class=3D""></div><div>Unsigned types portably implement w=
raparound without overhead. Signed types unportably implement wraparound bu=
t never introduce overhead. I don=E2=80=99t see how that=E2=80=99s getting =
further from hardware, nor how implementation-definedness will improve anyt=
hing. Yes, side effects may be guaranteed to happen (depending on standarde=
se in [intro] =C2=A71) before everything is allowed to go haywire (unexpect=
ed trap or nonsense value).</div><div><br class=3D""></div><div>The languag=
e doesn=E2=80=99t officially support adding two positive numbers and gettin=
g a negative number, but there=E2=80=99s no sacrifice in efficiency. In mos=
t cases that=E2=80=99s not a sensible result, whatever the ALU flag bits sa=
y. It=E2=80=99s better to let it be detected by tools somehow, sometimes, w=
ithout making trapping part of the program=E2=80=99s behavior. The only pro=
blem right now is that such tools aren=E2=80=99t yet as widespread as they =
should be, but they=E2=80=99re already freely available.</div><div><br clas=
s=3D""></div><blockquote type=3D"cite" class=3D""><div dir=3D"ltr" class=3D=
""><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:bre=
ak-word" class=3D""><div class=3D""><div class=3D""></div></div></div></blo=
ckquote><div class=3D"">A multiply for unsigned types that won't mysterious=
ly and platform-dependently be undefined on you would be nice.</div></div><=
/blockquote><div><br class=3D""></div><div>The built-in multiplication oper=
ator for unsigned types already satisfies this. See the footnote to =C2=A73=
..9.1/4.</div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_AF1D1C24-071F-4A2E-848C-C6001AD0DFDC--

.

Howard Hinnant <howard.hinnant@gmail.com> writes:

[...]

| > Defining the semantics as reduction mod 2^n on overflow does a lot of harm,
|
| *Nobody* has proposed that.  The proposal on the table is
| *implementation defined*.  I.e. Attention compiler: please stop
| throwing away my code.  Just let it do what the hardware does.

Well, "implementation-defined" does not mean that and never meant that.
All that does is to require the compiler writer to document the behavior
and chose a behavior that isn't unbounded (i.e. undefined behavior).
The compiler write may still do something more than what the hardware does.

-- Gaby

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Nevin Liber <nevin@eviloverlord.com> writes:

| On 16 December 2014 at 21:40, Howard Hinnant
| <howard.hinnant@gmail.com> wrote:
|=20
|     My intuition is that the C++ language should allow the programmer
|     unfettered (high-performance) access to his hardware.=C2=A0
|=20
|=20
| I agree.
|=20
| What I disagree with is the assertion that this facility should be
| spelled signed char, short, int, long or long long.

C++ still prides itself as effectively supporting high-level design and
abstractions with direct mapping of language facilities to hardware.  It
is unfortunate it does not provide such effective support for hardware-leve=
l
common datatypes.

-- Gaby

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

Ion Gazta=C3=B1aga <igaztanaga@gmail.com> writes:

[...]

| (5).  I want standard utilities to detect overflow/UB before executing
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| the operation. That way I can decide how to handle the issue.

(6) I want a unicorn

:-)

-- Gaby

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_35_1426440966.1418932545639
Content-Type: multipart/alternative;
 boundary="----=_Part_36_1833364101.1418932545639"

------=_Part_36_1833364101.1418932545639
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, December 17, 2014 6:32:28 PM UTC-8, David Krauss wrote:
>
> Besides the extra arithmetic, does it need to be wrapped in a class? Does=
=20
>> any of it need to be templated?
>>
>
> Wrapping in a class imparts a ton of performance issues.  I don't know of=
=20
> a compiler that will treat a boxed integer as always an integer, and alwa=
ys=20
> store the whole thing in registers.
>
>
> I was referring to the class templates like AbsValueHelper=20
> and SignedNegation. They only contain static member functions, not any=20
> state.
> =20
>

That works for performance, but writing function calls for every arithmetic=
=20
operation is painful.
=20

> Note that none of the languages makes it implementation-defined, except=
=20
> for C and C++ which allow implementation variance under undefined behavio=
r.
>
>
Perl does; the point at which overflow becomes floating point is=20
implementation-dependent (specifically, by bit size).  Not the same thing,=
=20
though.
=20

> The majority opinion there is actually to abandon integer semantics=20
> entirely. A survey isn=E2=80=99t really appropriate. However, Microsoft a=
nd Apple=20
> seem to have agreed to give programmers the ability to opt-in to trapping=
..=20
> I think scoped constructs and pragmas deserve more attention, rather than=
=20
> adjusting the language uniformly.
>
>
I'm not sure what is meant by "abandon integer semantics" here, sorry. =20
Microsoft supports trapping?  I don't know of any such feature in MSVC=20
other than divide by zero.  (On ARMv7, which has no hardware divide, MSVC's=
=20
library implementation of division intentionally traps on divide by zero or=
=20
divide overflow (INT_MAX / -1).)
=20

> Also, =E2=80=9Cwell-defined overflow handling=E2=80=9D is not the same as=
 helping to catch=20
> bugs in code review or in testing. There=E2=80=99s a fallacy there that m=
ore=20
> specification (anything!) will improve all issues relating to the=20
> underspecification.
>
>
No, but it would make traditional reasoning about overflow work.=20

> C is supposed to be a language closer to the hardware, yet it's a languag=
e=20
> that is *further* from the hardware than C# or Java for something as=20
> basic as integer math.
>
> Unsigned types portably implement wraparound without overhead. Signed=20
> types unportably implement wraparound but never introduce overhead. I don=
=E2=80=99t=20
> see how that=E2=80=99s getting further from hardware, nor how=20
> implementation-definedness will improve anything. Yes, side effects may b=
e=20
> guaranteed to happen (depending on standardese in [intro] =C2=A71) before=
=20
> everything is allowed to go haywire (unexpected trap or nonsense value).
>
>
Claiming that unsigned types are the solution in my opinion doesn't work=20
because just how difficult it is to avoid using signed types; see below for=
=20
an example.

> A multiply for unsigned types that won't mysteriously and=20
> platform-dependently be undefined on you would be nice.
>
>
> The built-in multiplication operator for unsigned types already satisfies=
=20
> this. See the footnote to =C2=A73.9.1/4.
>

It's promotion that makes multiplication unsafe:

std::uint16_t x =3D UINT16_MAX;
std::uint16_t y =3D UINT16_MAX;
x =3D (std::uint16_t) (x * y);  // Undefined behavior on 32-bit platforms

On platforms with 32-bit int, x and y have types whose values entirely fit=
=20
in signed int, the first rank in the promotion hierarchy, and are lower in=
=20
rank than signed int, so both parameters promote to signed int.  65535 *=20
65535 overflows a 32-bit signed int.  This behavior is platform-dependent;=
=20
on any other size of signed int--either larger and smaller--this code is=20
well-defined.  I've seen compilers warn on similar lines, but only for=20
truncation--I haven't seen them warn on the multiplication itself.  Only=20
-fsanitize=3Dundefined caught this one for me.

Melissa

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_36_1833364101.1418932545639
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, December 17, 2014 6:32:28 PM UTC-8, David Kr=
auss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-=
wrap:break-word"><div><blockquote type=3D"cite"><div dir=3D"ltr"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div><div=
></div><div>Besides the extra arithmetic, does it need to be wrapped in a c=
lass? Does any of it need to be templated?</div></div></div></blockquote><d=
iv><br>Wrapping in a class imparts a ton of performance issues.&nbsp; I don=
't know of a compiler that will treat a boxed integer as always an integer,=
 and always store the whole thing in registers.<br></div></div></blockquote=
><div><br></div><div>I was referring to the class templates like AbsValueHe=
lper and&nbsp;SignedNegation. They only contain static member functions, no=
t any state.</div></div><div>&nbsp;<br></div></div></blockquote><div><br>Th=
at works for performance, but writing function calls for every arithmetic o=
peration is painful.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div style=3D"word-wrap:break-word"><div><div>Note that none of the l=
anguages makes it implementation-defined, except for C and C++ which allow =
implementation variance under undefined behavior.</div><div><br></div></div=
></div></blockquote><div><br>Perl does; the point at which overflow becomes=
 floating point is implementation-dependent (specifically, by bit size).&nb=
sp; Not the same thing, though.<br>&nbsp;</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div style=3D"word-wrap:break-word"><div><div></div><div>T=
he majority opinion there is actually to abandon integer semantics entirely=
.. A survey isn=E2=80=99t really appropriate. However, Microsoft and Apple s=
eem to have agreed to give programmers the ability to opt-in to trapping. I=
 think scoped constructs and pragmas deserve more attention, rather than ad=
justing the language uniformly.</div><div><br></div></div></div></blockquot=
e><div><br>I'm not sure what is meant by "abandon integer semantics" here, =
sorry.&nbsp; Microsoft supports trapping?&nbsp; I don't know of any such fe=
ature in MSVC other than divide by zero.&nbsp; (On ARMv7, which has no hard=
ware divide, MSVC's library implementation of division intentionally traps =
on divide by zero or divide overflow (INT_MAX / -1).)<br>&nbsp;</div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word">=
<div><div></div><div>Also, =E2=80=9Cwell-defined overflow handling=E2=80=9D=
 is not the same as helping to catch bugs in code review or in testing. The=
re=E2=80=99s a fallacy there that more specification (anything!) will impro=
ve all issues relating to the underspecification.</div><br></div></div></bl=
ockquote><div><br>No, but it would make traditional reasoning about overflo=
w work. <br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=
=3D"word-wrap:break-word"><div><blockquote type=3D"cite"><div dir=3D"ltr"><=
div>C is supposed to be a language closer to the hardware, yet it's a langu=
age that is <i>further</i> from the hardware than C# or Java for something =
as basic as integer math.<br></div></div></blockquote><div></div><div>Unsig=
ned types portably implement wraparound without overhead. Signed types unpo=
rtably implement wraparound but never introduce overhead. I don=E2=80=99t s=
ee how that=E2=80=99s getting further from hardware, nor how implementation=
-definedness will improve anything. Yes, side effects may be guaranteed to =
happen (depending on standardese in [intro] =C2=A71) before everything is a=
llowed to go haywire (unexpected trap or nonsense value).</div><br></div></=
div></blockquote><div><br>Claiming that unsigned types are the solution in =
my opinion doesn't work because just how difficult it is to avoid using sig=
ned types; see below for an example.<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div style=3D"word-wrap:break-word"><div><blockquote type=
=3D"cite"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div sty=
le=3D"word-wrap:break-word"><div><div></div></div></div></blockquote><div>A=
 multiply for unsigned types that won't mysteriously and platform-dependent=
ly be undefined on you would be nice.</div></div></blockquote><div><br></di=
v><div>The built-in multiplication operator for unsigned types already sati=
sfies this. See the footnote to =C2=A73.9.1/4.</div></div></div></blockquot=
e><div><br>It's promotion that makes multiplication unsafe:<br><br><div cla=
ss=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-co=
lor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap:=
 break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">uint16_t x </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> UINT16_MAX</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">uint16_t y </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> UINT16_MAX</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">uint16_t</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> y</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> &nbsp;</span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// Undefined behavior on 32-=
bit platforms</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span></div></code></div><br>On platforms with 32-bit <span style=
=3D"font-family: courier new,monospace;">int</span>, <span style=3D"font-fa=
mily: courier new,monospace;">x</span> and <span style=3D"font-family: cour=
ier new,monospace;">y</span> have types whose values entirely fit in <span =
style=3D"font-family: courier new,monospace;">signed int</span>, the first =
rank in the promotion hierarchy, and are lower in rank than <span style=3D"=
font-family: courier new,monospace;">signed int</span>, so both parameters =
promote to <span style=3D"font-family: courier new,monospace;">signed int</=
span>.&nbsp; <span style=3D"font-family: courier new,monospace;">65535 * 65=
535</span> overflows a 32-bit <span style=3D"font-family: courier new,monos=
pace;">signed int</span>.&nbsp; This behavior is platform-dependent; on any=
 other size of <span style=3D"font-family: courier new,monospace;">signed i=
nt</span>--either larger and smaller--this code is well-defined.&nbsp; I've=
 seen compilers warn on similar lines, but only for truncation--I haven't s=
een them warn on the multiplication itself.&nbsp; Only <span style=3D"font-=
family: courier new,monospace;">-fsanitize=3Dundefined</span> caught this o=
ne for me.<br><br>Melissa<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_36_1833364101.1418932545639--
------=_Part_35_1426440966.1418932545639--

.

El 18/12/2014 17:55, Gabriel Dos Reis escribi=C3=B3:
> Ion Gazta=C3=B1aga <igaztanaga@gmail.com> writes:
>
> [...]
>
> | (5).  I want standard utilities to detect overflow/UB before executing
>                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> | the operation. That way I can decide how to handle the issue.
>
> (6) I want a unicorn
>
> :-)

Do you want a red one...

if(std::unicorn::overflows(x, y))
   return EINVAL;
else
   z =3D x + y;
   return 0;

..... or a green one?

if(!std::unicorn::add_if_no_overflow(x, y, result))
    return EINVAL;
return 0;

;-)

Ion

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--Apple-Mail=_7BD0A991-2CA2-4533-B3E4-ADAC5AEA1979
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2014=E2=80=9312=E2=80=9319, at 3:55 AM, Myriachan <myriachan@gmail.com=
> wrote:
>=20
> On Wednesday, December 17, 2014 6:32:28 PM UTC-8, David Krauss wrote:
> =20
> The majority opinion there is actually to abandon integer semantics entir=
ely. A survey isn=E2=80=99t really appropriate. However, Microsoft and Appl=
e seem to have agreed to give programmers the ability to opt-in to trapping=
.. I think scoped constructs and pragmas deserve more attention, rather than=
 adjusting the language uniformly.
>=20
>=20
> I'm not sure what is meant by "abandon integer semantics" here, sorry.  M=
icrosoft supports trapping?

C# and Swift, the newer and OS-vendor-sponsored languages in your list, are=
 listed as having opt-in trapping features.

> Also, =E2=80=9Cwell-defined overflow handling=E2=80=9D is not the same as=
 helping to catch bugs in code review or in testing. There=E2=80=99s a fall=
acy there that more specification (anything!) will improve all issues relat=
ing to the underspecification.
>=20
> No, but it would make traditional reasoning about overflow work.=20

Depending whether one=E2=80=99s personal tradition matches the platform in =
use.

Platform vendors should have the right to end traditions.

> The built-in multiplication operator for unsigned types already satisfies=
 this. See the footnote to =C2=A73.9.1/4.
>=20
> It's promotion that makes multiplication unsafe:
>=20
> std::uint16_t x =3D UINT16_MAX;
> std::uint16_t y =3D UINT16_MAX;
> x =3D (std::uint16_t) (x * y);  // Undefined behavior on 32-bit platforms

There=E2=80=99s no good reason (except legacy) that an unsigned multiplicat=
ion should ever have a signed result. It might be more reasonable, straight=
forward, and easy to define an exception in the promotion rules for multipl=
ication. It=E2=80=99s the only operation with such a problem in promotion.

Personally, I avoid doing any math directly with types that need promotion.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_7BD0A991-2CA2-4533-B3E4-ADAC5AEA1979
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2014=E2=80=9312=
=E2=80=9319, at 3:55 AM, Myriachan &lt;<a href=3D"mailto:myriachan@gmail.co=
m" class=3D"">myriachan@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-in=
terchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">On Wednesday=
, December 17, 2014 6:32:28 PM UTC-8, David Krauss wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word" class=3D"">=
<div class=3D""><blockquote type=3D"cite" class=3D""><div dir=3D"ltr" class=
=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break=
-word" class=3D""><div class=3D""><div class=3D""></div></div></div></block=
quote></div></blockquote></div></div></blockquote></div></div></blockquote>=
<blockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=
=3D""><div class=3D"">&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div style=3D"word-wrap:break-word" class=3D""><div class=3D""><div c=
lass=3D""></div><div class=3D"">The majority opinion there is actually to a=
bandon integer semantics entirely. A survey isn=E2=80=99t really appropriat=
e. However, Microsoft and Apple seem to have agreed to give programmers the=
 ability to opt-in to trapping. I think scoped constructs and pragmas deser=
ve more attention, rather than adjusting the language uniformly.</div><div =
class=3D""><br class=3D""></div></div></div></blockquote><div class=3D""><b=
r class=3D"">I'm not sure what is meant by "abandon integer semantics" here=
, sorry.&nbsp; Microsoft supports trapping?</div></div></div></blockquote><=
div><br class=3D""></div><div>C# and Swift, the newer and OS-vendor-sponsor=
ed languages in your list, are listed as having opt-in trapping features.</=
div><br class=3D""><blockquote type=3D"cite" class=3D""><div dir=3D"ltr" cl=
ass=3D""><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wr=
ap:break-word" class=3D""><div class=3D""><div class=3D"">Also, =E2=80=9Cwe=
ll-defined overflow handling=E2=80=9D is not the same as helping to catch b=
ugs in code review or in testing. There=E2=80=99s a fallacy there that more=
 specification (anything!) will improve all issues relating to the underspe=
cification.</div></div></div></blockquote><div class=3D""><br class=3D"">No=
, but it would make traditional reasoning about overflow work. <br class=3D=
""></div></div></blockquote><div><br class=3D""></div><div>Depending whethe=
r one=E2=80=99s personal tradition matches the platform in use.</div><div><=
br class=3D""></div><div>Platform vendors should have the right to end trad=
itions.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div dir=
=3D"ltr" class=3D""><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=
=3D"word-wrap:break-word" class=3D""><div class=3D""><div class=3D"">The bu=
ilt-in multiplication operator for unsigned types already satisfies this. S=
ee the footnote to =C2=A73.9.1/4.</div></div></div></blockquote><div class=
=3D""><br class=3D"">It's promotion that makes multiplication unsafe:<br cl=
ass=3D""><br class=3D""><div class=3D"prettyprint" style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint">s=
td<span style=3D"color: #660;" class=3D"styled-by-prettify">::</span>uint16=
_t x <span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span> U=
INT16_MAX<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<br class=3D"">std<span style=3D"color: #660;" class=3D"styled-by-prettify"=
>::</span>uint16_t y <span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span> UINT16_MAX<span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><br class=3D"">x <span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">=3D</span> <span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span>std<span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span>uint16_t<span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">)</span> <span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan>x <span style=3D"color: #660;" class=3D"styled-by-prettify">*</span> y<=
span style=3D"color: #660;" class=3D"styled-by-prettify">);</span> &nbsp;<s=
pan style=3D"color: #800;" class=3D"styled-by-prettify">// Undefined behavi=
or on 32-bit platforms</span></code></div></div></div></blockquote><div><br=
 class=3D""></div><div>There=E2=80=99s no good reason (except legacy) that =
an unsigned multiplication should ever have a signed result. It might be mo=
re reasonable, straightforward, and easy to define an exception in the prom=
otion rules for multiplication. It=E2=80=99s the only operation with such a=
 problem in promotion.</div><div><br class=3D""></div><div>Personally, I av=
oid doing any math directly with types that need promotion.</div></div></bo=
dy></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_7BD0A991-2CA2-4533-B3E4-ADAC5AEA1979--

.

------=_Part_37_465065121.1420837135802
Content-Type: multipart/alternative;
 boundary="----=_Part_38_1656497214.1420837135802"

------=_Part_38_1656497214.1420837135802
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, December 18, 2014 at 6:40:48 PM UTC-8, David Krauss wrote:
>
> C# and Swift, the newer and OS-vendor-sponsored languages in your list,=
=20
> are listed as having opt-in trapping features.
>

That is true, but they *aren't* choosing, "delete chunk of code because=20
overflow can't happen".  Overflow is still well-defined: it's defined as=20
trapping, and in these two languages, even trapping has well-defined=20
mechanics.

I think that the behaviors should be limited to one of wrap, trap, snap, or=
=20
crap.

wrap: two's complement modulo behavior.
trap: implementation-defined exception behavior, such as a C++ exception,=
=20
Win32 exception, C/POSIX signal, etc.
snap: saturation to INT_MIN or INT_MAX.
crap: arbitrary unspecified value.

This seems like it would cover existing implementations.

Also, =E2=80=9Cwell-defined overflow handling=E2=80=9D is not the same as h=
elping to catch=20
>> bugs in code review or in testing. There=E2=80=99s a fallacy there that =
more=20
>> specification (anything!) will improve all issues relating to the=20
>> underspecification.
>>
>
> No, but it would make traditional reasoning about overflow work.=20
>
>
> Depending whether one=E2=80=99s personal tradition matches the platform i=
n use.
>
> Platform vendors should have the right to end traditions.
>
>
Not by randomly deleting one's code.
=20

> The built-in multiplication operator for unsigned types already satisfies=
=20
>> this. See the footnote to =C2=A73.9.1/4.
>>
>
> It's promotion that makes multiplication unsafe:
>
> std::uint16_t x =3D UINT16_MAX;
> std::uint16_t y =3D UINT16_MAX;
> x =3D (std::uint16_t) (x * y);  // Undefined behavior on 32-bit platforms
>
>
> There=E2=80=99s no good reason (except legacy) that an unsigned multiplic=
ation=20
> should ever have a signed result. It might be more reasonable,=20
> straightforward, and easy to define an exception in the promotion rules f=
or=20
> multiplication. It=E2=80=99s the only operation with such a problem in pr=
omotion.
>
>
It's not just multiplication that can do this.  Addition and subtraction of=
=20
unsigned integers can cause undefined behavior as well on platforms with=20
sufficiently-small differences in sizes between a defined unsigned type and=
=20
int.  For example, the following (admittedly extreme and contrived) code=20
evokes undefined behavior on 16-bit platforms without multiplication:

#define FAKE_MULTIPLY_16(x) (x+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x)
#define FAKE_MULTIPLY_272(x) (FAKE_MULTIPLY_16(FAKE_MULTIPLY_16(x)) +=20
FAKE_MULTIPLY_16(x))
// ill-formed: undefined behavior within a constexpr
constexpr std::uint8_t f0{FAKE_MULTIPLY_272(std::uint8_t{255}) & 0xFF};

Personally, I avoid doing any math directly with types that need promotion.
>

How do you know which types need promotion without evoking template=20
nonsense everywhere?  Perhaps we need std::uint_promoted8_t,=20
std::uint_promoted16_t, ...

Melissa

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_38_1656497214.1420837135802
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, December 18, 2014 at 6:40:48 PM UTC-8, David =
Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"wor=
d-wrap:break-word"><div>C# and Swift, the newer and OS-vendor-sponsored lan=
guages in your list, are listed as having opt-in trapping features.<br></di=
v></div></blockquote><div><br>That is true, but they <i>aren't</i> choosing=
, "delete chunk of code because overflow can't happen".&nbsp; Overflow is s=
till well-defined: it's defined as trapping, and in these two languages, ev=
en trapping has well-defined mechanics.<br><br>I think that the behaviors s=
hould be limited to one of wrap, trap, snap, or crap.<br><br>wrap: two's co=
mplement modulo behavior.<br>trap: implementation-defined exception behavio=
r, such as a C++ exception, Win32 exception, C/POSIX signal, etc.<br>snap: =
saturation to INT_MIN or INT_MAX.<br>crap: arbitrary unspecified value.<br>=
<br>This seems like it would cover existing implementations.<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;"><div style=3D"word-wrap:break-w=
ord"><div><blockquote type=3D"cite"><div dir=3D"ltr"><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div style=3D"word-wrap:break-word"><div><div>Also, =E2=
=80=9Cwell-defined overflow handling=E2=80=9D is not the same as helping to=
 catch bugs in code review or in testing. There=E2=80=99s a fallacy there t=
hat more specification (anything!) will improve all issues relating to the =
underspecification.</div></div></div></blockquote><div><br>No, but it would=
 make traditional reasoning about overflow work. <br></div></div></blockquo=
te><div><br></div><div>Depending whether one=E2=80=99s personal tradition m=
atches the platform in use.</div><div><br></div><div>Platform vendors shoul=
d have the right to end traditions.</div><br></div></div></blockquote><div>=
<br>Not by randomly deleting one's code.<br>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div><block=
quote type=3D"cite"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div style=3D"word-wrap:break-word"><div><div>The built-in multiplication=
 operator for unsigned types already satisfies this. See the footnote to =
=C2=A73.9.1/4.</div></div></div></blockquote><div><br>It's promotion that m=
akes multiplication unsafe:<br><br><div style=3D"background-color:rgb(250,2=
50,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;w=
ord-wrap:break-word"><code>std<span style=3D"color:#660">::</span>uint16_t =
x <span style=3D"color:#660">=3D</span> UINT16_MAX<span style=3D"color:#660=
">;</span><br>std<span style=3D"color:#660">::</span>uint16_t y <span style=
=3D"color:#660">=3D</span> UINT16_MAX<span style=3D"color:#660">;</span><br=
>x <span style=3D"color:#660">=3D</span> <span style=3D"color:#660">(</span=
>std<span style=3D"color:#660">::</span>uint16_t<span style=3D"color:#660">=
)</span> <span style=3D"color:#660">(</span>x <span style=3D"color:#660">*<=
/span> y<span style=3D"color:#660">);</span> &nbsp;<span style=3D"color:#80=
0">// Undefined behavior on 32-bit platforms</span></code></div></div></div=
></blockquote><div><br></div><div>There=E2=80=99s no good reason (except le=
gacy) that an unsigned multiplication should ever have a signed result. It =
might be more reasonable, straightforward, and easy to define an exception =
in the promotion rules for multiplication. It=E2=80=99s the only operation =
with such a problem in promotion.</div><div><br></div></div></div></blockqu=
ote><div><br>It's not just multiplication that can do this.&nbsp; Addition =
and subtraction of unsigned integers can cause undefined behavior as well o=
n platforms with sufficiently-small differences in sizes between a defined =
unsigned type and <span style=3D"font-family: courier new,monospace;">int</=
span>.&nbsp; For example, the following (admittedly extreme and contrived) =
code evokes undefined behavior on 16-bit platforms without multiplication:<=
br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, =
250); border-color: rgb(187, 187, 187); border-style: solid; border-width: =
1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #800;" class=3D"styled-by-prettify">#defi=
ne</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> FAKE_MU=
LTIPLY_16</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">x</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">+</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">x</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">+</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">+</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">x</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">+</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">x</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">+</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">+</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">x</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">x</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">+</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">+</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">x</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">+</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">+</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">#define</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> FAKE_MULTIPLY_272</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">FAKE_MULTIPLY_16</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">F=
AKE_MULTIPLY_16</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">))</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> FAKE_MULTIPLY_16</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">))</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span><span style=3D"color: #800;" class=3D"style=
d-by-prettify">// ill-formed: undefined behavior within a constexpr</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">uint8_t f0</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">FAKE_MULTIPLY_272</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">uint8_t</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #066;" class=3D"styled-by-prettify">25=
5</span><span style=3D"color: #660;" class=3D"styled-by-prettify">})</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
066;" class=3D"styled-by-prettify">0xFF</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span></div></code></div><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div><di=
v></div><div>Personally, I avoid doing any math directly with types that ne=
ed promotion.</div></div></div></blockquote><div><br>How do you know which =
types need promotion without evoking template nonsense everywhere?&nbsp; Pe=
rhaps we need <span style=3D"font-family: courier new,monospace;">std::uint=
_promoted8_t</span>, <span style=3D"font-family: courier new,monospace;">st=
d::uint_promoted16_t</span>, ...<br><br>Melissa<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_38_1656497214.1420837135802--
------=_Part_37_465065121.1420837135802--

.

--Apple-Mail=_D0F69081-D9CA-4E4A-8718-465DFE6C829E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9301=E2=80=9310, at 4:58 AM, Myriachan <myriachan@gmail.com=
 <mailto:myriachan@gmail.com>> wrote:
>=20
> wrap: two's complement modulo behavior.
> trap: implementation-defined exception behavior, such as a C++ exception,=
 Win32 exception, C/POSIX signal, etc.
> snap: saturation to INT_MIN or INT_MAX.
> crap: arbitrary unspecified value.
>=20
> This seems like it would cover existing implementations.

There would be no need for this discussion if existing implementations alre=
ady followed the proposed rules.

> Platform vendors should have the right to end traditions.
>=20
> Not by randomly deleting one's code.

It=E2=80=99s not random. It=E2=80=99s when the behavior of the program is u=
npredictable anyway: not defined by any of the compiler=E2=80=99s constrain=
ts, set by ISO or otherwise. We=E2=80=99re talking about programs with bugs=
, but reasoning in terms of intentional behavior. Why should ISO bother wit=
h things that won=E2=80=99t be portable anyway? If a platform wants to enco=
urage use of overflow, it can specify whatever it likes. You can request su=
pport for wrapping or trapping from your vendor. GCC and Clang already have=
 both -fwrapv and -ftrapv.

In the rapidly-approaching future, we=E2=80=99ll have -fsanitize working we=
ll enough to be a popular practice, perhaps even enabled by default in debu=
g builds, across the popular platforms.

Furthermore, as far as I know, no compiler is deleting blocks for the sole =
reason that arithmetic therein is provably UB. What=E2=80=99s happening is =
that values produced by UB are treated as don=E2=80=99t-care in controlling=
 conditions for control flow. This is the same as =E2=80=9Ccrap,=E2=80=9D e=
xcept that you propose requiring the optimizer to statically reason about t=
he crap values.

Even if the would-be deleted code makes it into the executable, it would ex=
ecute unpredictably. Please show me if there=E2=80=99s another kind of case=
 where deletion happens in practice.

> It's not just multiplication that can do this.  Addition and subtraction =
of unsigned integers can cause undefined behavior as well on platforms with=
 sufficiently-small differences in sizes between a defined unsigned type an=
d int.  For example, the following (admittedly extreme and contrived) code =
evokes undefined behavior on 16-bit platforms without multiplication:
>=20
> #define FAKE_MULTIPLY_16(x) (x+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x)
> #define FAKE_MULTIPLY_272(x) (FAKE_MULTIPLY_16(FAKE_MULTIPLY_16(x)) + FAK=
E_MULTIPLY_16(x))
> // ill-formed: undefined behavior within a constexpr
> constexpr std::uint8_t f0{FAKE_MULTIPLY_272(std::uint8_t{255}) & 0xFF};

This is true, but it does require more than 256 terms in a subexpression.

The C rationale document has an extensive historical discussion (=C2=A76.3.=
1.1). Although many pre-standard compilers propagated unsignedness though p=
romotions (=E2=80=9Cunsigned preserving=E2=80=9D), the C89 standard defined=
 narrow unsigned values to promote to int (=E2=80=9Cvalue preserving=E2=80=
=9D). The change was made because unsigned preserving semantics tend to mak=
e an subexpression unsigned if any term is unsigned, and unsigned math is g=
enerally more surprising than signed math. They say, "This was considered t=
he most serious semantic change made by the C89 Committee to a widespread c=
urrent practice."

Perhaps some wiggle room can be found for improving the rules of promotion.=
 Rather than change the promotion rules for multiplication alone, the compu=
tation of a result and any subsequent integer conversion/promotion could be=
 taken as a single operation. If a signed result is immediately converted t=
o unsigned type, its signedness may be elided and UB averted.

x =3D (std::uint16_t) (x * y);  // OK: result is immediately converted to u=
nsigned.

This still leaves a problem with chained operations.

x =3D (x * y) * x; // Error: (x * y) is not converted nor promoted.

If the elision were accomplished by promoting both operands to unsigned typ=
e, then unsignedness would propagate downward into subexpressions.

x =3D (x * y) * x; // OK: promote (x * y) and x to unsigned int.

It=E2=80=99s a little more complicated, and the back-propagation would prev=
ent a compiler from determining types while forming the AST, but such a rul=
e might be a better fit for C++ than what we=E2=80=99ve inherited from C.

> Personally, I avoid doing any math directly with types that need promotio=
n.
>=20
> How do you know which types need promotion without evoking template nonse=
nse everywhere?  Perhaps we need std::uint_promoted8_t, std::uint_promoted1=
6_t, ...

The types that need promotion are char and short. I do tend to assume that =
32-bit types don=E2=80=99t get promoted, but my heuristic is essentially to=
 explicitly use int variables when doing potentially narrower math, and to =
bear in mind that int may be 16- or 32-bit. When would would you actually u=
se uint_promoted16_t in preference to unsigned int?

Writing 8-bit code is another story, though. In that environment, you somet=
imes have to actively fight promotion by putting intermediate results in 8-=
bit variables. It=E2=80=99s really contrary to the design of C.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_D0F69081-D9CA-4E4A-8718-465DFE6C829E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"><meta http-equiv=3D"Content-Type" content=3D"text/html charset=3D=
utf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: spac=
e; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><div c=
lass=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=
=80=9301=E2=80=9310, at 4:58 AM, Myriachan &lt;<a href=3D"mailto:myriachan@=
gmail.com" class=3D"">myriachan@gmail.com</a>&gt; wrote:</div><br class=3D"=
Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D""><div=
 class=3D"">wrap: two's complement modulo behavior.<br class=3D"">trap: imp=
lementation-defined exception behavior, such as a C++ exception, Win32 exce=
ption, C/POSIX signal, etc.<br class=3D"">snap: saturation to INT_MIN or IN=
T_MAX.<br class=3D"">crap: arbitrary unspecified value.<br class=3D""><br c=
lass=3D"">This seems like it would cover existing implementations.<br class=
=3D""></div></div></div></blockquote><div class=3D""><br class=3D""></div><=
div class=3D"">There would be no need for this discussion if existing imple=
mentations already followed the proposed rules.</div><br class=3D""><blockq=
uote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-w=
ord" class=3D""><div class=3D""><div class=3D"">Platform vendors should hav=
e the right to end traditions.</div></div></div></blockquote><div class=3D"=
"><br class=3D"">Not by randomly deleting one's code.<br class=3D""></div><=
/div></div></blockquote><div class=3D""><br class=3D""></div><div class=3D"=
">It=E2=80=99s not random. It=E2=80=99s when the behavior of the program is=
 unpredictable anyway: not defined by any of the compiler=E2=80=99s constra=
ints, set by ISO or otherwise. We=E2=80=99re talking about programs with bu=
gs, but reasoning in terms of intentional behavior. Why should ISO bother w=
ith things that won=E2=80=99t be portable anyway? If a platform wants to en=
courage use of overflow, it can specify whatever it likes. You can request =
support for wrapping or trapping from your vendor. GCC and Clang already ha=
ve both&nbsp;<font face=3D"Courier" class=3D"">-fwrapv</font>&nbsp;and <fon=
t face=3D"Courier" class=3D"">-ftrapv</font>.</div><div class=3D""><br clas=
s=3D""></div><div class=3D"">In the rapidly-approaching future, we=E2=80=99=
ll have <font face=3D"Courier" class=3D"">-fsanitize</font> working well en=
ough to be a popular practice, perhaps even enabled by default in debug bui=
lds, across the popular platforms.</div><div class=3D""><br class=3D""></di=
v><div class=3D"">Furthermore, as far as I know, no compiler is deleting bl=
ocks for the sole reason that arithmetic therein is provably UB. What=E2=80=
=99s happening is that values produced by UB are treated as don=E2=80=99t-c=
are in controlling conditions for control flow. This is the same as =E2=80=
=9Ccrap,=E2=80=9D except that you propose requiring the optimizer to static=
ally reason about the crap values.</div><div class=3D""><br class=3D""></di=
v><div class=3D"">Even if the would-be deleted code makes it into the execu=
table, it would execute unpredictably. Please show me if there=E2=80=99s an=
other kind of case where deletion happens in practice.</div><div class=3D""=
><br class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D"">=
<div dir=3D"ltr" class=3D""><div class=3D"">It's not just multiplication th=
at can do this.&nbsp; Addition and subtraction of unsigned integers can cau=
se undefined behavior as well on platforms with sufficiently-small differen=
ces in sizes between a defined unsigned type and <span style=3D"font-family=
: courier new,monospace;" class=3D"">int</span>.&nbsp; For example, the fol=
lowing (admittedly extreme and contrived) code evokes undefined behavior on=
 16-bit platforms without multiplication:<br class=3D""><br class=3D""><div=
 class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); borde=
r-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-w=
rap: break-word;"><code class=3D"prettyprint"><span style=3D"color: #800;" =
class=3D"styled-by-prettify">#define</span> FAKE_MULTIPLY_16<span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span>x<span style=3D"color: #=
660;" class=3D"styled-by-prettify">)</span> <span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span>x<span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">+</span>x<span style=3D"color: #660;" class=3D"styled-by=
-prettify">+</span>x<span style=3D"color: #660;" class=3D"styled-by-prettif=
y">+</span>x<span style=3D"color: #660;" class=3D"styled-by-prettify">+</sp=
an>x<span style=3D"color: #660;" class=3D"styled-by-prettify">+</span>x<spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">+</span>x<span style=
=3D"color: #660;" class=3D"styled-by-prettify">+</span>x<span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">+</span>x<span style=3D"color: #660;=
" class=3D"styled-by-prettify">+</span>x<span style=3D"color: #660;" class=
=3D"styled-by-prettify">+</span>x<span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">+</span>x<span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">+</span>x<span style=3D"color: #660;" class=3D"styled-by-prettify">=
+</span>x<span style=3D"color: #660;" class=3D"styled-by-prettify">+</span>=
x<span style=3D"color: #660;" class=3D"styled-by-prettify">+</span>x<span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">)</span><br class=3D""><=
span style=3D"color: #800;" class=3D"styled-by-prettify">#define</span> FAK=
E_MULTIPLY_272<span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span>x<span style=3D"color: #660;" class=3D"styled-by-prettify">)</span> <s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span>FAKE_MULTIP=
LY_16<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>FAKE=
_MULTIPLY_16<span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an>x<span style=3D"color: #660;" class=3D"styled-by-prettify">))</span> <sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">+</span> FAKE_MULTIP=
LY_16<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>x<sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">))</span><br class=
=3D""><span style=3D"color: #800;" class=3D"styled-by-prettify">// ill-form=
ed: undefined behavior within a constexpr</span><br class=3D""><span style=
=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span> std<span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">::</span>uint8_t f0<span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span>FAKE_MULTIPLY_2=
72<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>std<spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">::</span>uint8_t<span=
 style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D=
"color: #066;" class=3D"styled-by-prettify">255</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">})</span> <span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&amp;</span> <span style=3D"color: #066;" cla=
ss=3D"styled-by-prettify">0xFF</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">};</span></code></div></div></div></div></blockquote><d=
iv class=3D""><br class=3D""></div>This is true, but it does require more t=
han 256 terms in a subexpression.</div><div class=3D""><br class=3D""></div=
><div class=3D"">The C rationale document has an extensive historical discu=
ssion (=C2=A76.3.1.1). Although many pre-standard compilers propagated unsi=
gnedness though promotions (=E2=80=9Cunsigned preserving=E2=80=9D), the C89=
 standard defined narrow unsigned values to promote to <font face=3D"Courie=
r" class=3D"">int</font> (=E2=80=9Cvalue preserving=E2=80=9D). The change w=
as made because unsigned preserving semantics tend to make an subexpression=
 unsigned if any term is unsigned, and unsigned math is generally more surp=
rising than signed math. They say, "This was considered the most&nbsp;serio=
us semantic change made by the C89 Committee to a widespread current&nbsp;p=
ractice."</div><div class=3D""><br class=3D""></div><div class=3D"">Perhaps=
 some wiggle room can be found for improving the rules of promotion. Rather=
 than change the promotion rules for multiplication alone, the computation =
of a result and any subsequent integer conversion/promotion could be taken =
as a single operation. If a signed result is immediately converted to unsig=
ned type, its signedness may be elided and UB averted.</div><div class=3D""=
><br class=3D""></div><div class=3D""><font face=3D"Courier" class=3D"">x&n=
bsp;=3D&nbsp;(std::uint16_t)&nbsp;(x&nbsp;*&nbsp;y);&nbsp;&nbsp;// OK: resu=
lt is immediately converted to&nbsp;unsigned.</font></div><div class=3D""><=
br class=3D""></div><div class=3D"">This still leaves a problem with chaine=
d operations.</div><div class=3D""><br class=3D""></div><div class=3D""><fo=
nt face=3D"Courier" class=3D"">x =3D (x * y) * x; // Error: (x * y) is not =
converted nor promoted.</font></div><div class=3D""><br class=3D""></div><d=
iv class=3D"">If the elision were accomplished by promoting both operands t=
o unsigned type, then unsignedness would propagate downward into subexpress=
ions.</div><div class=3D""><br class=3D""></div><div class=3D""><font face=
=3D"Courier" class=3D"">x =3D (x * y) * x; // OK: promote (x * y) and x to =
unsigned int.</font></div><div class=3D""><br class=3D""></div><div class=
=3D"">It=E2=80=99s a little more complicated, and the back-propagation woul=
d prevent a compiler from determining types while forming the AST, but such=
 a rule might be a better fit for C++ than what we=E2=80=99ve inherited fro=
m C.</div><div class=3D""><br class=3D""><blockquote type=3D"cite" class=3D=
""><div class=3D""><div dir=3D"ltr" class=3D""><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div style=3D"word-wrap:break-word" class=3D""><div class=
=3D""><div class=3D""></div><div class=3D"">Personally, I avoid doing any m=
ath directly with types that need promotion.</div></div></div></blockquote>=
<div class=3D""><br class=3D"">How do you know which types need promotion w=
ithout evoking template nonsense everywhere?&nbsp; Perhaps we need <span st=
yle=3D"font-family: courier new,monospace;" class=3D"">std::uint_promoted8_=
t</span>, <span style=3D"font-family: courier new,monospace;" class=3D"">st=
d::uint_promoted16_t</span>, ...<br class=3D""></div></div></div></blockquo=
te><div class=3D""><br class=3D""></div><div class=3D"">The types that need=
 promotion are <font face=3D"Courier" class=3D"">char</font> and <font face=
=3D"Courier" class=3D"">short</font>. I do tend to assume that 32-bit types=
 don=E2=80=99t get promoted, but my heuristic is essentially to explicitly =
use&nbsp;<font face=3D"Courier" class=3D"">int</font>&nbsp;variables when d=
oing potentially narrower math, and to bear in mind that <font face=3D"Cour=
ier" class=3D"">int</font> may be 16- or 32-bit. When would would you actua=
lly use <font face=3D"Courier" class=3D"">uint_promoted16_t</font> in prefe=
rence to <font face=3D"Courier" class=3D"">unsigned int</font>?</div><div c=
lass=3D""><br class=3D""></div><div class=3D"">Writing 8-bit code is anothe=
r story, though. In that environment, you sometimes have to actively fight =
promotion by putting intermediate results in 8-bit variables. It=E2=80=99s =
really contrary to the design of C.</div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_D0F69081-D9CA-4E4A-8718-465DFE6C829E--

.

--Apple-Mail=_ACE49B1F-7C44-4CE8-941A-338D4459CF49
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9301=E2=80=9310, at 4:58 AM, Myriachan <myriachan@gmail.com=
 <mailto:myriachan@gmail.com>> wrote:
>=20
> wrap: two's complement modulo behavior.
> trap: implementation-defined exception behavior, such as a C++ exception,=
 Win32 exception, C/POSIX signal, etc.
> snap: saturation to INT_MIN or INT_MAX.
> crap: arbitrary unspecified value.
>=20
> This seems like it would cover existing implementations.

There would be no need for this discussion if existing implementations alre=
ady followed the proposed rules.

> Platform vendors should have the right to end traditions.
>=20
> Not by randomly deleting one's code.

It=E2=80=99s not random. It=E2=80=99s when the behavior of the program is u=
npredictable anyway: not defined by any of the compiler=E2=80=99s constrain=
ts, set by ISO or otherwise. We=E2=80=99re talking about programs with bugs=
, but reasoning in terms of intentional behavior. Why should ISO bother wit=
h things that won=E2=80=99t be portable anyway? If a platform wants to enco=
urage use of overflow, it can specify whatever it likes. You can request su=
pport for wrapping or trapping from your vendor. GCC and Clang already have=
 both -fwrapv and -ftrapv.

In the rapidly-approaching future, we=E2=80=99ll have -fsanitize working we=
ll enough to be a popular practice, perhaps even enabled by default in debu=
g builds, across the popular platforms.

Furthermore, as far as I know, no compiler is deleting blocks for the sole =
reason that arithmetic therein is provably UB. What=E2=80=99s happening is =
that values produced by UB are treated as don=E2=80=99t-care in controlling=
 conditions for control flow. This is the same as =E2=80=9Ccrap,=E2=80=9D e=
xcept that you propose requiring the optimizer to statically reason about t=
he crap values.

Even if the would-be deleted code makes it into the executable, it would ex=
ecute unpredictably. Please show me if there=E2=80=99s another kind of case=
 where deletion happens in practice.

> It's not just multiplication that can do this.  Addition and subtraction =
of unsigned integers can cause undefined behavior as well on platforms with=
 sufficiently-small differences in sizes between a defined unsigned type an=
d int.  For example, the following (admittedly extreme and contrived) code =
evokes undefined behavior on 16-bit platforms without multiplication:
>=20
> #define FAKE_MULTIPLY_16(x) (x+x+x+x+x+x+x+x+x+x+x+x+x+x+x+x)
> #define FAKE_MULTIPLY_272(x) (FAKE_MULTIPLY_16(FAKE_MULTIPLY_16(x)) + FAK=
E_MULTIPLY_16(x))
> // ill-formed: undefined behavior within a constexpr
> constexpr std::uint8_t f0{FAKE_MULTIPLY_272(std::uint8_t{255}) & 0xFF};

This is true, but it does require more than 256 terms in a subexpression.

The C rationale document has an extensive historical discussion (=C2=A76.3.=
1.1). Although many pre-standard compilers propagated unsignedness though p=
romotions (=E2=80=9Cunsigned preserving=E2=80=9D), the C89 standard defined=
 narrow unsigned values to promote to int (=E2=80=9Cvalue preserving=E2=80=
=9D). The change was made because unsigned preserving semantics tend to mak=
e an subexpression unsigned if any term is unsigned, and unsigned math is g=
enerally more surprising than signed math. They say, "This was considered t=
he most serious semantic change made by the C89 Committee to a widespread c=
urrent practice."

Perhaps some wiggle room can be found for improving the rules of promotion.=
 Rather than change the promotion rules for multiplication alone, the compu=
tation of a result and any subsequent integer conversion/promotion could be=
 taken as a single operation. If a signed result is immediately converted t=
o unsigned type, its signedness may be elided and UB averted.

x =3D (std::uint16_t) (x * y);  // OK: result is immediately converted to u=
nsigned.

This still leaves a problem with chained operations.

x =3D (x * y) * x; // Error: (x * y) is not converted nor promoted.

If the elision were accomplished by promoting both operands to unsigned typ=
e, then unsignedness would propagate downward into subexpressions.

x =3D (x * y) * x; // OK: promote (x * y) and x to unsigned int.

It=E2=80=99s a little more complicated, and the back-propagation would prev=
ent a compiler from determining types while forming the AST, but such a rul=
e might be a better fit for C++ than what we=E2=80=99ve inherited from C.

> Personally, I avoid doing any math directly with types that need promotio=
n.
>=20
> How do you know which types need promotion without evoking template nonse=
nse everywhere?  Perhaps we need std::uint_promoted8_t, std::uint_promoted1=
6_t, ...

The types that need promotion are char and short. I do tend to assume that =
32-bit types don=E2=80=99t get promoted, but my heuristic is essentially to=
 explicitly use int variables when doing potentially narrower math, and to =
bear in mind that int may be 16- or 32-bit. When would would you actually u=
se uint_promoted16_t in preference to unsigned int?

Writing 8-bit code is another story, though. In that environment, you somet=
imes have to actively fight promotion by putting intermediate results in 8-=
bit variables. It=E2=80=99s really contrary to the design of C.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_ACE49B1F-7C44-4CE8-941A-338D4459CF49
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"><meta http-equiv=3D"Content-Type" content=3D"text/html charset=3D=
utf-8"><meta http-equiv=3D"Content-Type" content=3D"text/html charset=3Dutf=
-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space;" class=3D""><br class=3D""><div clas=
s=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=
=9301=E2=80=9310, at 4:58 AM, Myriachan &lt;<a href=3D"mailto:myriachan@gma=
il.com" class=3D"">myriachan@gmail.com</a>&gt; wrote:</div><br class=3D"App=
le-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D""><div cl=
ass=3D"">wrap: two's complement modulo behavior.<br class=3D"">trap: implem=
entation-defined exception behavior, such as a C++ exception, Win32 excepti=
on, C/POSIX signal, etc.<br class=3D"">snap: saturation to INT_MIN or INT_M=
AX.<br class=3D"">crap: arbitrary unspecified value.<br class=3D""><br clas=
s=3D"">This seems like it would cover existing implementations.<br class=3D=
""></div></div></div></blockquote><div class=3D""><br class=3D""></div><div=
 class=3D"">There would be no need for this discussion if existing implemen=
tations already followed the proposed rules.</div><br class=3D""><blockquot=
e type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word=
" class=3D""><div class=3D""><div class=3D"">Platform vendors should have t=
he right to end traditions.</div></div></div></blockquote><div class=3D""><=
br class=3D"">Not by randomly deleting one's code.<br class=3D""></div></di=
v></div></blockquote><div class=3D""><br class=3D""></div><div class=3D"">I=
t=E2=80=99s not random. It=E2=80=99s when the behavior of the program is un=
predictable anyway: not defined by any of the compiler=E2=80=99s constraint=
s, set by ISO or otherwise. We=E2=80=99re talking about programs with bugs,=
 but reasoning in terms of intentional behavior. Why should ISO bother with=
 things that won=E2=80=99t be portable anyway? If a platform wants to encou=
rage use of overflow, it can specify whatever it likes. You can request sup=
port for wrapping or trapping from your vendor. GCC and Clang already have =
both&nbsp;<font face=3D"Courier" class=3D"">-fwrapv</font>&nbsp;and <font f=
ace=3D"Courier" class=3D"">-ftrapv</font>.</div><div class=3D""><br class=
=3D""></div><div class=3D"">In the rapidly-approaching future, we=E2=80=99l=
l have <font face=3D"Courier" class=3D"">-fsanitize</font> working well eno=
ugh to be a popular practice, perhaps even enabled by default in debug buil=
ds, across the popular platforms.</div><div class=3D""><br class=3D""></div=
><div class=3D"">Furthermore, as far as I know, no compiler is deleting blo=
cks for the sole reason that arithmetic therein is provably UB. What=E2=80=
=99s happening is that values produced by UB are treated as don=E2=80=99t-c=
are in controlling conditions for control flow. This is the same as =E2=80=
=9Ccrap,=E2=80=9D except that you propose requiring the optimizer to static=
ally reason about the crap values.</div><div class=3D""><br class=3D""></di=
v><div class=3D"">Even if the would-be deleted code makes it into the execu=
table, it would execute unpredictably. Please show me if there=E2=80=99s an=
other kind of case where deletion happens in practice.</div><div class=3D""=
><br class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D"">=
<div dir=3D"ltr" class=3D""><div class=3D"">It's not just multiplication th=
at can do this.&nbsp; Addition and subtraction of unsigned integers can cau=
se undefined behavior as well on platforms with sufficiently-small differen=
ces in sizes between a defined unsigned type and <span style=3D"font-family=
: courier new,monospace;" class=3D"">int</span>.&nbsp; For example, the fol=
lowing (admittedly extreme and contrived) code evokes undefined behavior on=
 16-bit platforms without multiplication:<br class=3D""><br class=3D""><div=
 class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); borde=
r-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-w=
rap: break-word;"><code class=3D"prettyprint"><span style=3D"color: #800;" =
class=3D"styled-by-prettify">#define</span> FAKE_MULTIPLY_16<span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span>x<span style=3D"color: #=
660;" class=3D"styled-by-prettify">)</span> <span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span>x<span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">+</span>x<span style=3D"color: #660;" class=3D"styled-by=
-prettify">+</span>x<span style=3D"color: #660;" class=3D"styled-by-prettif=
y">+</span>x<span style=3D"color: #660;" class=3D"styled-by-prettify">+</sp=
an>x<span style=3D"color: #660;" class=3D"styled-by-prettify">+</span>x<spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">+</span>x<span style=
=3D"color: #660;" class=3D"styled-by-prettify">+</span>x<span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">+</span>x<span style=3D"color: #660;=
" class=3D"styled-by-prettify">+</span>x<span style=3D"color: #660;" class=
=3D"styled-by-prettify">+</span>x<span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">+</span>x<span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">+</span>x<span style=3D"color: #660;" class=3D"styled-by-prettify">=
+</span>x<span style=3D"color: #660;" class=3D"styled-by-prettify">+</span>=
x<span style=3D"color: #660;" class=3D"styled-by-prettify">+</span>x<span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">)</span><br class=3D""><=
span style=3D"color: #800;" class=3D"styled-by-prettify">#define</span> FAK=
E_MULTIPLY_272<span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span>x<span style=3D"color: #660;" class=3D"styled-by-prettify">)</span> <s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span>FAKE_MULTIP=
LY_16<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>FAKE=
_MULTIPLY_16<span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an>x<span style=3D"color: #660;" class=3D"styled-by-prettify">))</span> <sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">+</span> FAKE_MULTIP=
LY_16<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>x<sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">))</span><br class=
=3D""><span style=3D"color: #800;" class=3D"styled-by-prettify">// ill-form=
ed: undefined behavior within a constexpr</span><br class=3D""><span style=
=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span> std<span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">::</span>uint8_t f0<span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span>FAKE_MULTIPLY_2=
72<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>std<spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">::</span>uint8_t<span=
 style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D=
"color: #066;" class=3D"styled-by-prettify">255</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">})</span> <span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&amp;</span> <span style=3D"color: #066;" cla=
ss=3D"styled-by-prettify">0xFF</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">};</span></code></div></div></div></div></blockquote><d=
iv class=3D""><br class=3D""></div>This is true, but it does require more t=
han 256 terms in a subexpression.</div><div class=3D""><br class=3D""></div=
><div class=3D"">The C rationale document has an extensive historical discu=
ssion (=C2=A76.3.1.1). Although many pre-standard compilers propagated unsi=
gnedness though promotions (=E2=80=9Cunsigned preserving=E2=80=9D), the C89=
 standard defined narrow unsigned values to promote to <font face=3D"Courie=
r" class=3D"">int</font> (=E2=80=9Cvalue preserving=E2=80=9D). The change w=
as made because unsigned preserving semantics tend to make an subexpression=
 unsigned if any term is unsigned, and unsigned math is generally more surp=
rising than signed math. They say, "This was considered the most&nbsp;serio=
us semantic change made by the C89 Committee to a widespread current&nbsp;p=
ractice."</div><div class=3D""><br class=3D""></div><div class=3D"">Perhaps=
 some wiggle room can be found for improving the rules of promotion. Rather=
 than change the promotion rules for multiplication alone, the computation =
of a result and any subsequent integer conversion/promotion could be taken =
as a single operation. If a signed result is immediately converted to unsig=
ned type, its signedness may be elided and UB averted.</div><div class=3D""=
><br class=3D""></div><div class=3D""><font face=3D"Courier" class=3D"">x&n=
bsp;=3D&nbsp;(std::uint16_t)&nbsp;(x&nbsp;*&nbsp;y);&nbsp;&nbsp;// OK: resu=
lt is immediately converted to&nbsp;unsigned.</font></div><div class=3D""><=
br class=3D""></div><div class=3D"">This still leaves a problem with chaine=
d operations.</div><div class=3D""><br class=3D""></div><div class=3D""><fo=
nt face=3D"Courier" class=3D"">x =3D (x * y) * x; // Error: (x * y) is not =
converted nor promoted.</font></div><div class=3D""><br class=3D""></div><d=
iv class=3D"">If the elision were accomplished by promoting both operands t=
o unsigned type, then unsignedness would propagate downward into subexpress=
ions.</div><div class=3D""><br class=3D""></div><div class=3D""><font face=
=3D"Courier" class=3D"">x =3D (x * y) * x; // OK: promote (x * y) and x to =
unsigned int.</font></div><div class=3D""><br class=3D""></div><div class=
=3D"">It=E2=80=99s a little more complicated, and the back-propagation woul=
d prevent a compiler from determining types while forming the AST, but such=
 a rule might be a better fit for C++ than what we=E2=80=99ve inherited fro=
m C.</div><div class=3D""><br class=3D""><blockquote type=3D"cite" class=3D=
""><div class=3D""><div dir=3D"ltr" class=3D""><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div style=3D"word-wrap:break-word" class=3D""><div class=
=3D""><div class=3D""></div><div class=3D"">Personally, I avoid doing any m=
ath directly with types that need promotion.</div></div></div></blockquote>=
<div class=3D""><br class=3D"">How do you know which types need promotion w=
ithout evoking template nonsense everywhere?&nbsp; Perhaps we need <span st=
yle=3D"font-family: courier new,monospace;" class=3D"">std::uint_promoted8_=
t</span>, <span style=3D"font-family: courier new,monospace;" class=3D"">st=
d::uint_promoted16_t</span>, ...<br class=3D""></div></div></div></blockquo=
te><div class=3D""><br class=3D""></div><div class=3D"">The types that need=
 promotion are <font face=3D"Courier" class=3D"">char</font> and <font face=
=3D"Courier" class=3D"">short</font>. I do tend to assume that 32-bit types=
 don=E2=80=99t get promoted, but my heuristic is essentially to explicitly =
use&nbsp;<font face=3D"Courier" class=3D"">int</font>&nbsp;variables when d=
oing potentially narrower math, and to bear in mind that <font face=3D"Cour=
ier" class=3D"">int</font> may be 16- or 32-bit. When would would you actua=
lly use <font face=3D"Courier" class=3D"">uint_promoted16_t</font> in prefe=
rence to <font face=3D"Courier" class=3D"">unsigned int</font>?</div><div c=
lass=3D""><br class=3D""></div><div class=3D"">Writing 8-bit code is anothe=
r story, though. In that environment, you sometimes have to actively fight =
promotion by putting intermediate results in 8-bit variables. It=E2=80=99s =
really contrary to the design of C.</div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_ACE49B1F-7C44-4CE8-941A-338D4459CF49--

.

On Sat, Jan 10, 2015 at 5:45 AM, David Krauss <potswa@gmail.com> wrote:
>
> On 2015=E2=80=9301=E2=80=9310, at 4:58 AM, Myriachan <myriachan@gmail.com=
> wrote:
> The C rationale document has an extensive historical discussion (=C2=A76.=
3.1.1).
> Although many pre-standard compilers propagated unsignedness though
> promotions (=E2=80=9Cunsigned preserving=E2=80=9D), the C89 standard defi=
ned narrow unsigned
> values to promote to int (=E2=80=9Cvalue preserving=E2=80=9D). The change=
 was made because
> unsigned preserving semantics tend to make an subexpression unsigned if a=
ny
> term is unsigned, and unsigned math is generally more surprising than sig=
ned
> math. They say, "This was considered the most serious semantic change mad=
e
> by the C89 Committee to a widespread current practice."
>
> Perhaps some wiggle room can be found for improving the rules of promotio=
n.
> Rather than change the promotion rules for multiplication alone, the
> computation of a result and any subsequent integer conversion/promotion
> could be taken as a single operation. If a signed result is immediately
> converted to unsigned type, its signedness may be elided and UB averted.

What about taking into account the types of the (two) operands? If
both are unsigned, the result is unsigned. Literals should probably be
handled specially.

IMO we should also have standard intrinsics for saturating, trapping
and wrapping arithmetic. And maybe also for overflow detection without
requiring a (valid) result.
--=20
Olaf

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

> On 2015=E2=80=9301=E2=80=9311, at 7:54 PM, Olaf van der Spek <olafvdspek@=
gmail.com> wrote:
>=20
> What about taking into account the types of the (two) operands? If
> both are unsigned, the result is unsigned. Literals should probably be
> handled specially.

I don=E2=80=99t know if there=E2=80=99s any middle ground between what we h=
ave and the over-eager unsignedness that was rejected by C89. Maybe if you =
can give more specific rules=E2=80=A6

> IMO we should also have standard intrinsics for saturating, trapping
> and wrapping arithmetic. And maybe also for overflow detection without
> requiring a (valid) result.

Library functions, yes.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_2323_219655461.1420985827203
Content-Type: multipart/alternative;
 boundary="----=_Part_2324_224943834.1420985827203"

------=_Part_2324_224943834.1420985827203
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

With library solution we could fix all problems. Promotion rules and=20
overflow results.

template<OverflowType OT, typename Result, typename A1, typename A2> Result=
=20
safe_add(A1 a, A2 b); //same function for rest of operations
auto x =3D safe_add<OverflowType::trap, unsigned>(1, 10u); //ugly way
auto y =3D 1safe + 1u; //overload + and UDL

Every one could define int that fit they requirements. Another thing is=20
that this allow mix different types of int in one project, but it will=20
protect you from implicit mixing both types.


On Sunday, January 11, 2015 at 2:54:09 PM UTC+1, David Krauss wrote:
>
>
> > On 2015=E2=80=9301=E2=80=9311, at 7:54 PM, Olaf van der Spek <olafv...@=
gmail.com=20
> <javascript:>> wrote:=20
> >=20
> > What about taking into account the types of the (two) operands? If=20
> > both are unsigned, the result is unsigned. Literals should probably be=
=20
> > handled specially.=20
>
> I don=E2=80=99t know if there=E2=80=99s any middle ground between what we=
 have and the=20
> over-eager unsignedness that was rejected by C89. Maybe if you can give=
=20
> more specific rules=E2=80=A6=20
>
> > IMO we should also have standard intrinsics for saturating, trapping=20
> > and wrapping arithmetic. And maybe also for overflow detection without=
=20
> > requiring a (valid) result.=20
>
> Library functions, yes.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_2324_224943834.1420985827203
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">With library solution we could fix all problems. Promotion=
 rules and overflow results.<br><br><div class=3D"prettyprint" style=3D"bac=
kground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border=
-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">template</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">OverflowType</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> OT</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">typen=
ame</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">Result</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> A1</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> A2</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">Result</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> safe_add</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">A1 a</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> A2 b</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by=
-prettify">//same function for rest of operations</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> x </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> safe_add</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><code class=3D"prettyprint"><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">OverflowType</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"></span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">::</span></code>trap</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>unsigned</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
gt;(</span><span style=3D"color: #066;" class=3D"styled-by-prettify">1</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: #066;" class=3D"styled-by-prettify">10u</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">//ugly way</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> y </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">1safe</span><spa=
n 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"> </span><span style=3D"color: #066;" =
class=3D"styled-by-prettify">1u</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettif=
y">//overload + and UDL</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span></div></code></div><br>Every one could define int t=
hat fit they requirements. Another thing is that this allow mix different t=
ypes of int in one project, but it will protect you from implicit mixing bo=
th types.<br><br><br>On Sunday, January 11, 2015 at 2:54:09 PM UTC+1, David=
 Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; On 2015=E2=80=9301=E2=80=9311, at 7:54 PM, Olaf van der Spek &lt;<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"0qXU5bU_M=
MUJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this=
..href=3D'javascript:';return true;">olafv...@gmail.com</a>&gt; wrote:
<br>&gt;=20
<br>&gt; What about taking into account the types of the (two) operands? If
<br>&gt; both are unsigned, the result is unsigned. Literals should probabl=
y be
<br>&gt; handled specially.
<br>
<br>I don=E2=80=99t know if there=E2=80=99s any middle ground between what =
we have and the over-eager unsignedness that was rejected by C89. Maybe if =
you can give more specific rules=E2=80=A6
<br>
<br>&gt; IMO we should also have standard intrinsics for saturating, trappi=
ng
<br>&gt; and wrapping arithmetic. And maybe also for overflow detection wit=
hout
<br>&gt; requiring a (valid) result.
<br>
<br>Library functions, yes.</blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2324_224943834.1420985827203--
------=_Part_2323_219655461.1420985827203--

.

I'd prefer different types for different rules. E.g. class
trapping_int, saturating_int, wrapping_int etc.

On 1/11/15, inkwizytoryankes@gmail.com <inkwizytoryankes@gmail.com> wrote:
> With library solution we could fix all problems. Promotion rules and
> overflow results.
>
> template<OverflowType OT, typename Result, typename A1, typename A2> Resu=
lt
>
> safe_add(A1 a, A2 b); //same function for rest of operations
> auto x =3D safe_add<OverflowType::trap, unsigned>(1, 10u); //ugly way
> auto y =3D 1safe + 1u; //overload + and UDL
>
> Every one could define int that fit they requirements. Another thing is
> that this allow mix different types of int in one project, but it will
> protect you from implicit mixing both types.
>
>
> On Sunday, January 11, 2015 at 2:54:09 PM UTC+1, David Krauss wrote:
>>
>>
>> > On 2015=E2=80=9301=E2=80=9311, at 7:54 PM, Olaf van der Spek <olafv...=
@gmail.com
>> <javascript:>> wrote:
>> >
>> > What about taking into account the types of the (two) operands? If
>> > both are unsigned, the result is unsigned. Literals should probably be
>> > handled specially.
>>
>> I don=E2=80=99t know if there=E2=80=99s any middle ground between what w=
e have and the
>> over-eager unsignedness that was rejected by C89. Maybe if you can give
>> more specific rules=E2=80=A6
>>
>> > IMO we should also have standard intrinsics for saturating, trapping
>> > and wrapping arithmetic. And maybe also for overflow detection without
>> > requiring a (valid) result.
>>
>> Library functions, yes.
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

A variant on the saturating alternative would be to have bit patterns
representing +inf, NaN and (for signed ints) -inf.

On 1/11/15, Douglas Boffey <douglas.boffey@gmail.com> wrote:
> I'd prefer different types for different rules. E.g. class
> trapping_int, saturating_int, wrapping_int etc.
>
> On 1/11/15, inkwizytoryankes@gmail.com <inkwizytoryankes@gmail.com> wrote=
:
>> With library solution we could fix all problems. Promotion rules and
>> overflow results.
>>
>> template<OverflowType OT, typename Result, typename A1, typename A2>
>> Result
>>
>> safe_add(A1 a, A2 b); //same function for rest of operations
>> auto x =3D safe_add<OverflowType::trap, unsigned>(1, 10u); //ugly way
>> auto y =3D 1safe + 1u; //overload + and UDL
>>
>> Every one could define int that fit they requirements. Another thing is
>> that this allow mix different types of int in one project, but it will
>> protect you from implicit mixing both types.
>>
>>
>> On Sunday, January 11, 2015 at 2:54:09 PM UTC+1, David Krauss wrote:
>>>
>>>
>>> > On 2015=E2=80=9301=E2=80=9311, at 7:54 PM, Olaf van der Spek <olafv..=
..@gmail.com
>>> <javascript:>> wrote:
>>> >
>>> > What about taking into account the types of the (two) operands? If
>>> > both are unsigned, the result is unsigned. Literals should probably b=
e
>>> > handled specially.
>>>
>>> I don=E2=80=99t know if there=E2=80=99s any middle ground between what =
we have and the
>>> over-eager unsignedness that was rejected by C89. Maybe if you can give
>>> more specific rules=E2=80=A6
>>>
>>> > IMO we should also have standard intrinsics for saturating, trapping
>>> > and wrapping arithmetic. And maybe also for overflow detection withou=
t
>>> > requiring a (valid) result.
>>>
>>> Library functions, yes.
>>
>> --
>>
>> ---
>> 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.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Sunday 11 January 2015 16:29:27 Douglas Boffey wrote:
> A variant on the saturating alternative would be to have bit patterns
> representing +inf, NaN and (for signed ints) -inf.

There is no such representation for integers in any CPU that I know of.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_1613_1560384429.1421005573329
Content-Type: multipart/alternative;
 boundary="----=_Part_1614_310801039.1421005573329"

------=_Part_1614_310801039.1421005573329
Content-Type: text/plain; charset=UTF-8

On Sunday, January 11, 2015 at 6:17:07 AM UTC-8, inkwizyt...@gmail.com
wrote:
>
> With library solution we could fix all problems. Promotion rules and
> overflow results.
>
> template<OverflowType OT, typename Result, typename A1, typename A2>
> Result safe_add(A1 a, A2 b); //same function for rest of operations
> auto x = safe_add<OverflowType::trap, unsigned>(1, 10u); //ugly way
> auto y = 1safe + 1u; //overload + and UDL
>
> Every one could define int that fit they requirements. Another thing is
> that this allow mix different types of int in one project, but it will
> protect you from implicit mixing both types.
>
>
Except that it's not enough--size is needed as well, because otherwise you
could just use unsigned.  With a specified size, now you have my fixed-size
literals proposas, or a variant of it designed for promotion safety, and
people on this list were rejecting it, too.  So only the first option works.

Just imagine how ugly a SHA-256 implementation would have to look in order
to be fully portable, with its reliance upon integer wrapping behavior.

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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1614_310801039.1421005573329
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, January 11, 2015 at 6:17:07 AM UTC-8, inkwizyt.=
...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">With library solution we could fix all problems. Promotion rules and =
overflow results.<br><br><div style=3D"background-color:rgb(250,250,250);bo=
rder-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:b=
reak-word"><code><div><span style=3D"color:#008">template</span><span style=
=3D"color:#660">&lt;</span><span style=3D"color:#606">OverflowType</span><s=
pan style=3D"color:#000"> OT</span><span style=3D"color:#660">,</span><span=
 style=3D"color:#000"> </span><span style=3D"color:#008">typename</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#606">Result</span><sp=
an style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#008">typename</span><span style=3D"color:#000"> A1</span><spa=
n style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#008">typename</span><span style=3D"color:#000"> A2</span><span=
 style=3D"color:#660">&gt;</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#606">Result</span><span style=3D"color:#000"> safe_add</span=
><span style=3D"color:#660">(</span><span style=3D"color:#000">A1 a</span><=
span style=3D"color:#660">,</span><span style=3D"color:#000"> A2 b</span><s=
pan style=3D"color:#660">);</span><span style=3D"color:#000"> </span><span =
style=3D"color:#800">//same function for rest of operations</span><span sty=
le=3D"color:#000"><br></span><span style=3D"color:#008">auto</span><span st=
yle=3D"color:#000"> x </span><span style=3D"color:#660">=3D</span><span sty=
le=3D"color:#000"> safe_add</span><span style=3D"color:#660">&lt;</span><sp=
an style=3D"color:#000"><code><span style=3D"color:#606">OverflowType</span=
><span style=3D"color:#000"></span><span style=3D"color:#000">::</span></co=
de>trap</span><span style=3D"color:#660">,</span><span style=3D"color:#000"=
> </span><span style=3D"color:#008">unsigned</span><span style=3D"color:#66=
0">&gt;(</span><span style=3D"color:#066">1</span><span style=3D"color:#660=
">,</span><span style=3D"color:#000"> </span><span style=3D"color:#066">10u=
</span><span style=3D"color:#660">);</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#800">//ugly way</span><span style=3D"color:#000"><=
br></span><span style=3D"color:#008">auto</span><span style=3D"color:#000">=
 y </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> =
</span><span style=3D"color:#066">1safe</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#660">+</span><span style=3D"color:#000"> </span=
><span style=3D"color:#066">1u</span><span style=3D"color:#660">;</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#800">//overload + and=
 UDL</span><span style=3D"color:#000"><br></span></div></code></div><br>Eve=
ry one could define int that fit they requirements. Another thing is that t=
his allow mix different types of int in one project, but it will protect yo=
u from implicit mixing both types.<br><br></div></blockquote><div><br>Excep=
t that it's not enough--size is needed as well, because otherwise you could=
 just use <span style=3D"font-family: courier new,monospace;">unsigned</spa=
n>.&nbsp; With a specified size, now you have my fixed-size literals propos=
as, or a variant of it designed for promotion safety, and people on this li=
st were rejecting it, too.&nbsp; So only the first option works.<br><br>Jus=
t imagine how ugly a SHA-256 implementation would have to look in order to =
be fully portable, with its reliance upon integer wrapping behavior.<br><br=
>Melissa<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1614_310801039.1421005573329--
------=_Part_1613_1560384429.1421005573329--

.

--Apple-Mail=_2D8BDE94-8E4F-41CF-9FC8-0668F2B300E5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9301=E2=80=9312, at 3:46 AM, Myriachan <myriachan@gmail.com=
> wrote:
>=20
> On Sunday, January 11, 2015 at 6:17:07 AM UTC-8, inkwizyt...@gmail.com wr=
ote:
> With library solution we could fix all problems. Promotion rules and over=
flow results.
>=20
> template<OverflowType OT, typename Result, typename A1, typename A2> Resu=
lt safe_add(A1 a, A2 b); //same function for rest of operations
> auto x =3D safe_add<OverflowType::trap, unsigned>(1, 10u); //ugly way
> auto y =3D 1safe + 1u; //overload + and UDL
>=20
> Every one could define int that fit they requirements. Another thing is t=
hat this allow mix different types of int in one project, but it will prote=
ct you from implicit mixing both types.
>=20
> Except that it's not enough--size is needed as well, because otherwise yo=
u could just use unsigned.  With a specified size, now you have my fixed-si=
ze literals proposas, or a variant of it designed for promotion safety, and=
 people on this list were rejecting it, too.=20

You proposed fixed-size literals for existing types and implementation-defi=
ned (-variant) behavior. Inkwizytoryankes proposes an arithmetic library, a=
nd perhaps UDLs (new types) for beautification. (Such libraries already exi=
st, of course.)

I think I=E2=80=99ve seen such a LWG proposal, except for operator overload=
ing, but I can=E2=80=99t remember the year, title, or author.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_2D8BDE94-8E4F-41CF-9FC8-0668F2B300E5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9301=
=E2=80=9312, at 3:46 AM, Myriachan &lt;<a href=3D"mailto:myriachan@gmail.co=
m" class=3D"">myriachan@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-in=
terchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">On Sunday, J=
anuary 11, 2015 at 6:17:07 AM UTC-8, inkwizyt...@<a href=3D"http://gmail.co=
m" class=3D"">gmail.com</a> 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" class=3D"">With library solution we could fix all pr=
oblems. Promotion rules and overflow results.<br class=3D""><br class=3D"">=
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,18=
7);border-style:solid;border-width:1px;word-wrap:break-word" class=3D""><co=
de class=3D""><span style=3D"color:#008" class=3D"">template</span><span st=
yle=3D"color:#660" class=3D"">&lt;</span><span style=3D"color:#606" class=
=3D"">OverflowType</span> OT<span style=3D"color:#660" class=3D"">,</span> =
<span style=3D"color:#008" class=3D"">typename</span> <span style=3D"color:=
#606" class=3D"">Result</span><span style=3D"color:#660" class=3D"">,</span=
> <span style=3D"color:#008" class=3D"">typename</span> A1<span style=3D"co=
lor:#660" class=3D"">,</span> <span style=3D"color:#008" class=3D"">typenam=
e</span> A2<span style=3D"color:#660" class=3D"">&gt;</span> <span style=3D=
"color:#606" class=3D"">Result</span> safe_add<span style=3D"color:#660" cl=
ass=3D"">(</span>A1 a<span style=3D"color:#660" class=3D"">,</span> A2 b<sp=
an style=3D"color:#660" class=3D"">);</span> <span style=3D"color:#800" cla=
ss=3D"">//same function for rest of operations</span><br class=3D""><span s=
tyle=3D"color:#008" class=3D"">auto</span> x <span style=3D"color:#660" cla=
ss=3D"">=3D</span> safe_add<span style=3D"color:#660" class=3D"">&lt;</span=
><code class=3D""><span style=3D"color:#606" class=3D"">OverflowType</span>=
<span style=3D"" class=3D""></span><span style=3D"" class=3D"">::</span></c=
ode>trap<span style=3D"color:#660" class=3D"">,</span> <span style=3D"color=
:#008" class=3D"">unsigned</span><span style=3D"color:#660" class=3D"">&gt;=
(</span><span style=3D"color:#066" class=3D"">1</span><span style=3D"color:=
#660" class=3D"">,</span> <span style=3D"color:#066" class=3D"">10u</span><=
span style=3D"color:#660" class=3D"">);</span> <span style=3D"color:#800" c=
lass=3D"">//ugly way</span><br class=3D""><span style=3D"color:#008" class=
=3D"">auto</span> y <span style=3D"color:#660" class=3D"">=3D</span> <span =
style=3D"color:#066" class=3D"">1safe</span> <span style=3D"color:#660" cla=
ss=3D"">+</span> <span style=3D"color:#066" class=3D"">1u</span><span style=
=3D"color:#660" class=3D"">;</span> <span style=3D"color:#800" class=3D"">/=
/overload + and UDL</span><br class=3D""></code></div><br class=3D"">Every =
one could define int that fit they requirements. Another thing is that this=
 allow mix different types of int in one project, but it will protect you f=
rom implicit mixing both types.<br class=3D""></div></blockquote><div class=
=3D""><br class=3D"">Except that it's not enough--size is needed as well, b=
ecause otherwise you could just use <span style=3D"font-family: courier new=
,monospace;" class=3D"">unsigned</span>.&nbsp; With a specified size, now y=
ou have my fixed-size literals proposas, or a variant of it designed for pr=
omotion safety, and people on this list were rejecting it, too.&nbsp; </div=
></div></div></blockquote><div><br class=3D""></div><div>You proposed fixed=
-size literals for existing types and implementation-defined (-variant) beh=
avior. Inkwizytoryankes proposes an arithmetic library, and perhaps UDLs (n=
ew types) for beautification. (Such libraries already exist, of course.)</d=
iv><div><br class=3D""></div><div>I think I=E2=80=99ve seen such a LWG prop=
osal, except for operator overloading, but I can=E2=80=99t remember the yea=
r, title, or author.</div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_2D8BDE94-8E4F-41CF-9FC8-0668F2B300E5--

.

------=_Part_4916_629410202.1421184015809
Content-Type: multipart/alternative;
 boundary="----=_Part_4917_2140303539.1421184015809"

------=_Part_4917_2140303539.1421184015809
Content-Type: text/plain; charset=UTF-8


On Sunday, January 11, 2015 at 10:03:52 AM UTC-5, Douglas Boffey wrote:
>
> I'd prefer different types for different rules. E.g. class
> trapping_int, saturating_int, wrapping_int etc.
>

There should be both a minimal low level procedural interface which works
on all ints and a higher level type which just encapsulates an int
and performs the desired behavior for all operations by default. The latter
is implemented using the former.

I should be able to do a saturated addition on an int whenever I like using
a function call instead of the builtin operators. If I know I want
saturated math all of the time, then I can use the saturated_int type.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_4917_2140303539.1421184015809
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Sunday, January 11, 2015 at 10:03:52 AM UTC-5, Doug=
las Boffey wrote:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-le=
ft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bor=
der-left-style: solid;" class=3D"gmail_quote">I'd prefer different types fo=
r different rules. E.g. class
<br>trapping_int, saturating_int, wrapping_int etc.
<br>
</blockquote><div>&nbsp;</div><div>There should be both a minimal&nbsp;low =
level procedural interface which works on all ints and a higher level type =
which just encapsulates an int and&nbsp;performs the desired behavior for a=
ll operations by default. The latter is implemented using the former.</div>=
<div>&nbsp;</div><div>I should be able to do a saturated addition on an int=
 whenever I like using a function call instead of the builtin operators. If=
 I know I want saturated math all of the time, then I can use the saturated=
_int type.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4917_2140303539.1421184015809--
------=_Part_4916_629410202.1421184015809--

.

------=_Part_6436_1014666445.1421273098187
Content-Type: multipart/alternative;
 boundary="----=_Part_6437_331300288.1421273098187"

------=_Part_6437_331300288.1421273098187
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sunday, January 11, 2015 at 2:54:09 PM UTC+1, David Krauss wrote:
>
>
> > On 2015=E2=80=9301=E2=80=9311, at 7:54 PM, Olaf van der Spek <olafv...@=
gmail.com=20
> <javascript:>> wrote:=20
> >=20
> > What about taking into account the types of the (two) operands? If=20
> > both are unsigned, the result is unsigned. Literals should probably be=
=20
> > handled specially.=20
>
> I don=E2=80=99t know if there=E2=80=99s any middle ground between what we=
 have and the=20
> over-eager unsignedness that was rejected by C89. Maybe if you can give=
=20
> more specific rules=E2=80=A6=20
>

(AFAIK)
Currently (unsigned) char and (unsigned) short are promoted to (unsigned)=
=20
int depending on their respective sizes but not taking into account the=20
type of the other argument (for binary operators).
Unsigned char and unsigned short are often promoted to int (which might be=
=20
surprising), but sometimes to unsigned (int). AFAIK this is platform=20
specific.

My idea is to take the type of the other argument into account, so if=20
you've got two unsigned chars, they'd be promoted to unsigned int instead=
=20
of to int.
Integer promotion is only one part of the puzzle though and probably not=20
the easiest part to change.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_6437_331300288.1421273098187
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, January 11, 2015 at 2:54:09 PM UTC+1, David Kra=
uss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; On 2015=E2=80=9301=E2=80=9311, at 7:54 PM, Olaf van der Spek &lt;<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"0qXU5bU_M=
MUJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this=
..href=3D'javascript:';return true;">olafv...@gmail.com</a>&gt; wrote:
<br>&gt;=20
<br>&gt; What about taking into account the types of the (two) operands? If
<br>&gt; both are unsigned, the result is unsigned. Literals should probabl=
y be
<br>&gt; handled specially.
<br>
<br>I don=E2=80=99t know if there=E2=80=99s any middle ground between what =
we have and the over-eager unsignedness that was rejected by C89. Maybe if =
you can give more specific rules=E2=80=A6
<br></blockquote><div><br></div><div>(AFAIK)</div><div>Currently (unsigned)=
 char and (unsigned) short are promoted to (unsigned) int depending on thei=
r respective sizes but not taking into account the type of the other argume=
nt (for binary operators).</div><div>Unsigned char and unsigned short are o=
ften promoted to int (which might be surprising), but sometimes to unsigned=
 (int). AFAIK this is platform specific.</div><div><br></div><div>My idea i=
s to take the type of the other argument into account, so if you've got two=
 unsigned chars, they'd be promoted to unsigned int instead of to int.</div=
><div>Integer promotion is only one part of the puzzle though and probably =
not the easiest part to change.</div><div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6437_331300288.1421273098187--
------=_Part_6436_1014666445.1421273098187--

.

------=_Part_297_125439082.1421285543864
Content-Type: multipart/alternative;
 boundary="----=_Part_298_1573193467.1421285543864"

------=_Part_298_1573193467.1421285543864
Content-Type: text/plain; charset=UTF-8

On Wednesday, January 14, 2015 at 2:04:58 PM UTC-8, Olaf van der Spek wrote:
>
>
> (AFAIK)
> Currently (unsigned) char and (unsigned) short are promoted to (unsigned)
> int depending on their respective sizes but not taking into account the
> type of the other argument (for binary operators).
> Unsigned char and unsigned short are often promoted to int (which might be
> surprising), but sometimes to unsigned (int). AFAIK this is platform
> specific.
>
> My idea is to take the type of the other argument into account, so if
> you've got two unsigned chars, they'd be promoted to unsigned int instead
> of to int.
> Integer promotion is only one part of the puzzle though and probably not
> the easiest part to change.
>
>
I don't think that it is fixable without breaking a huge amount of existing
code.

One of the ways you can get platform-specific code is attempting to wrap
around zero.  It's well-defined behavior, but the results of this program
are platform-specific:

#include <climits>
#include <cstdint>
#include <cstdio>

template <typename T>
void print_zero_minus1_signed()
{
    T zero = T{0};
    std::printf("%zu: %d\n", sizeof(T) * CHAR_BIT, zero - 1 < zero);
}

int main()
{
    print_zero_minus1_signed<std::uint8_t>();
    print_zero_minus1_signed<std::uint16_t>();
    print_zero_minus1_signed<std::uint32_t>();
    print_zero_minus1_signed<std::uint64_t>();
    return 0;
}

On a typical 32-bit int platform, this prints 1, 1, 0, 0.

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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_298_1573193467.1421285543864
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, January 14, 2015 at 2:04:58 PM UTC-8, Olaf v=
an der Spek wrote:<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"><br><div>(AFAIK)</div><div>Currently (unsigned) char and (unsigned) sh=
ort are promoted to (unsigned) int depending on their respective sizes but =
not taking into account the type of the other argument (for binary operator=
s).</div><div>Unsigned char and unsigned short are often promoted to int (w=
hich might be surprising), but sometimes to unsigned (int). AFAIK this is p=
latform specific.</div><div><br></div><div>My idea is to take the type of t=
he other argument into account, so if you've got two unsigned chars, they'd=
 be promoted to unsigned int instead of to int.</div><div>Integer promotion=
 is only one part of the puzzle though and probably not the easiest part to=
 change.</div><div><br></div></div></blockquote><div><br>I don't think that=
 it is fixable without breaking a huge amount of existing code.<br><br>One =
of the ways you can get platform-specific code is attempting to wrap around=
 zero.&nbsp; It's well-defined behavior, but the results of this program ar=
e platform-specific:<br><br><div class=3D"prettyprint" style=3D"background-=
color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: =
solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprin=
t"><div class=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styl=
ed-by-prettify">#include</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-prett=
ify">&lt;climits&gt;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">#include</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;cst=
dint&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><span style=3D"color: #800;" class=3D"styled-by-prettify">#include=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #080;" class=3D"styled-by-prettify">&lt;cstdio&gt;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">template</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> print_zero_minus1_signed</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br>&nbsp; &nbsp; T zero </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; std=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">printf</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #080;" class=3D"styled-by-prettify">"%zu: %d\n"</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">sizeof</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> CHAR_BIT</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> zero </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">-</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" clas=
s=3D"styled-by-prettify">1</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> zero</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> main</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>&nbsp; &nbsp; print_zero_minus1_signed</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">uint8_t</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&gt;();</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>&nbsp; &nbsp; print_zero_minus1_signed</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">uint16_t</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&gt;();</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp; &nbsp; print_zero_minus1_signed</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">uint32_t</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&gt;();</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br>&nbsp; &nbsp; print_zero_minus1_signed</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">uint64_t</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&gt;();</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">}</span></div></code></div><br>On a typical 32-bit <span style=3D"=
font-family: courier new,monospace;">int</span> platform, this prints 1, 1,=
 0, 0.<br><br>Melissa<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_298_1573193467.1421285543864--
------=_Part_297_125439082.1421285543864--

.

--Apple-Mail=_B96F21CC-089E-4781-8CCF-77D3543C8614
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9301=E2=80=9315, at 9:32 AM, Myriachan <myriachan@gmail.com=
> wrote:
>=20
> I don't think that it is fixable without breaking a huge amount of existi=
ng code.
>=20
> One of the ways you can get platform-specific code is attempting to wrap =
around zero.  It's well-defined behavior, but the results of this program a=
re platform-specific:

My suggestion, to back-propagate the unsignedness from the integer conversi=
on sequence following the operation, would not break your example, because =
the result is not converted to unsigned.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_B96F21CC-089E-4781-8CCF-77D3543C8614
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9301=
=E2=80=9315, at 9:32 AM, Myriachan &lt;<a href=3D"mailto:myriachan@gmail.co=
m" class=3D"">myriachan@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-in=
terchange-newline"><div class=3D""><span style=3D"font-family: Helvetica; f=
ont-size: 12px; font-style: normal; font-variant: normal; font-weight: norm=
al; letter-spacing: normal; line-height: normal; orphans: auto; text-align:=
 start; text-indent: 0px; text-transform: none; white-space: normal; widows=
: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; dis=
play: inline !important;" class=3D"">I don't think that it is fixable witho=
ut breaking a huge amount of existing code.</span><br style=3D"font-family:=
 Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font=
-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto=
; text-align: start; text-indent: 0px; text-transform: none; white-space: n=
ormal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" cl=
ass=3D""><br style=3D"font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; te=
xt-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -=
webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: Helv=
etica; font-size: 12px; font-style: normal; font-variant: normal; font-weig=
ht: normal; letter-spacing: normal; line-height: normal; orphans: auto; tex=
t-align: start; text-indent: 0px; text-transform: none; white-space: normal=
; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: n=
one; display: inline !important;" class=3D"">One of the ways you can get pl=
atform-specific code is attempting to wrap around zero.&nbsp; It's well-def=
ined behavior, but the results of this program are platform-specific:</span=
><br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; line-hei=
ght: normal; orphans: auto; text-align: start; text-indent: 0px; text-trans=
form: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-t=
ext-stroke-width: 0px;" class=3D""></div></blockquote></div><br class=3D"">=
<div class=3D"">My suggestion, to back-propagate the unsignedness from the =
integer conversion sequence following the operation, would not break your e=
xample, because the result is not converted to unsigned.</div></body></html=
>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_B96F21CC-089E-4781-8CCF-77D3543C8614--

.