Topic: Require size_t to be of at least "unsigned int" rank
Author: Myriachan <myriachan@gmail.com>
Date: Fri, 18 Sep 2015 13:15:40 -0700 (PDT)
Raw View
------=_Part_2689_245746187.1442607340944
Content-Type: multipart/alternative;
boundary="----=_Part_2690_685454130.1442607340945"
------=_Part_2690_685454130.1442607340945
Content-Type: text/plain; charset=UTF-8
I think that std::size_t should always be of at least "unsigned int" rank.
It is a security danger if std::size_t is not at least "unsigned int" rank,
because most arithmetic operations would unexpectedly cause it to be
promoted to "signed int" and potentially result in unauthorized takeovers
of devices due to compiler omission of security checks.
It's frequent with std::size_t to have code like this:
std::size_t untrusted_number = ...;
if (untrusted_number + sizeof(SomeType) < untrusted_number)
{
return false;
}
Likewise, std::ptrdiff_t ought to be of at least "signed int" rank;
however, this is not a security issue, just a convenience one.
This isn't an issue on "sane" architectures...
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_2690_685454130.1442607340945
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think that <span style=3D"font-family: courier new,monos=
pace;">std::size_t</span> should always be of at least "<span style=3D=
"font-family: courier new,monospace;">unsigned int</span>" rank.=C2=A0=
It is a security danger if <span style=3D"font-family: courier new,monospa=
ce;">std::size_t</span> is not at least "<span style=3D"font-family: c=
ourier new,monospace;">unsigned int</span>" rank, because most arithme=
tic operations would unexpectedly cause it to be promoted to "<span st=
yle=3D"font-family: courier new,monospace;">signed int</span>" and pot=
entially result in unauthorized takeovers of devices due to compiler omissi=
on of security checks.<br><br>It's frequent with <span style=3D"font-fa=
mily: courier new,monospace;">std::size_t</span> to have code like this:<br=
><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 25=
0); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1p=
x; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpre=
ttyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">std</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">size_t untrusted_numbe=
r </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">...;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">if</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">untrusted_number </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">sizeof</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Som=
eType</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</sp=
an><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"> untrusted_number</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: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">false</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><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span></div></code></div><br>Likewise, <span style=3D"font-family: cou=
rier new,monospace;">std::ptrdiff_t</span> ought to be of at least "<s=
pan style=3D"font-family: courier new,monospace;">signed int</span>" r=
ank; however, this is not a security issue, just a convenience one.<br><br>=
This isn't an issue on "sane" architectures...<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" 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_2690_685454130.1442607340945--
------=_Part_2689_245746187.1442607340944--
.
Author: "Nevin \":-)\" Liber" <"Nevin ":-)" Liber" <nliber@gmail.com>>
Date: Fri, 18 Sep 2015 16:50:30 -0500
Raw View
Questions that come to mind:
Shouldn't this be addressed by the C Committee?
What platforms is it a problem on?
Will those vendors change their size_t (being a subtle breaking change)?
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (312) 623-5420
> On Sep 18, 2015, at 3:15 PM, Myriachan <myriachan@gmail.com> wrote:
>
> This isn't an issue on "sane" architectures...
--
---
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/.
.
Author: Bo Persson <bop@gmb.dk>
Date: Sat, 19 Sep 2015 09:52:54 +0200
Raw View
On 2015-09-18 22:15, Myriachan wrote:
> I think that std::size_t should always be of at least "unsigned int"
> rank. It is a security danger if std::size_t is not at least "unsigned
> int" rank, because most arithmetic operations would unexpectedly cause
> it to be promoted to "signed int" and potentially result in unauthorized
> takeovers of devices due to compiler omission of security checks.
>
> It's frequent with std::size_t to have code like this:
>
> |
> std::size_t untrusted_number =...;
>
> if(untrusted_number +sizeof(SomeType)<untrusted_number)
> {
> returnfalse;
> }
> |
>
> Likewise, std::ptrdiff_t ought to be of at least "signed int" rank;
> however, this is not a security issue, just a convenience one.
>
> This isn't an issue on "sane" architectures...
>
We can do that ourselves, if we want to limit portablity to "sane"
platforms.
static_assert(sizeof(size_t) >= sizeof(unsigned int),
"Sane platforms only, please!");
We don't want to make life even harder for the unusual systems.
Bo Persson
--
---
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/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 19 Sep 2015 08:51:43 -0700 (PDT)
Raw View
------=_Part_3225_51619850.1442677904071
Content-Type: multipart/alternative;
boundary="----=_Part_3226_2099703087.1442677904071"
------=_Part_3226_2099703087.1442677904071
Content-Type: text/plain; charset=UTF-8
On Friday, September 18, 2015 at 4:15:41 PM UTC-4, Myriachan wrote:
>
> I think that std::size_t should always be of at least "unsigned int"
> rank. It is a security danger if std::size_t is not at least "unsigned
> int" rank, because most arithmetic operations would unexpectedly cause it
> to be promoted to "signed int" and potentially result in unauthorized
> takeovers of devices due to compiler omission of security checks.
>
I'm not an expert in security, but I'm curious as to how integer promotion
in expression *alone* could cause a security breach. I could see how it
might cause a computation to result in an overflow or other unexpected
values. But I don't see how that would yield a security problem unless that
integer were used by code that doesn't do range checking.
In which case, the problem is the lack of range checking, not integer
promotion.
--
---
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_3226_2099703087.1442677904071
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, September 18, 2015 at 4:15:41 PM UTC-4,=
Myriachan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">I think that <span style=3D"font-family:courier new,monospace">std::siz=
e_t</span> should always be of at least "<span style=3D"font-family:co=
urier new,monospace">unsigned int</span>" rank.=C2=A0 It is a security=
danger if <span style=3D"font-family:courier new,monospace">std::size_t</s=
pan> is not at least "<span style=3D"font-family:courier new,monospace=
">unsigned int</span>" rank, because most arithmetic operations would =
unexpectedly cause it to be promoted to "<span style=3D"font-family:co=
urier new,monospace">signed int</span>" and potentially result in unau=
thorized takeovers of devices due to compiler omission of security checks.<=
br></div></blockquote><div><br>I'm not an expert in security, but I'=
;m curious as to how integer promotion in expression <i>alone</i> could cau=
se a security breach. I could see how it might cause a computation to resul=
t in an overflow or other unexpected values. But I don't see how that w=
ould yield a security problem unless that integer were used by code that do=
esn't do range checking.<br><br>In which case, the problem is the lack =
of range checking, not integer promotion.</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" 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_3226_2099703087.1442677904071--
------=_Part_3225_51619850.1442677904071--
.
Author: Myriachan <myriachan@gmail.com>
Date: Thu, 24 Sep 2015 11:37:42 -0700 (PDT)
Raw View
------=_Part_1426_195444837.1443119862171
Content-Type: multipart/alternative;
boundary="----=_Part_1427_2142172725.1443119862171"
------=_Part_1427_2142172725.1443119862171
Content-Type: text/plain; charset=UTF-8
On Saturday, September 19, 2015 at 8:51:44 AM UTC-7, Nicol Bolas wrote:
>
> I'm not an expert in security, but I'm curious as to how integer promotion
> in expression *alone* could cause a security breach. I could see how it
> might cause a computation to result in an overflow or other unexpected
> values. But I don't see how that would yield a security problem unless that
> integer were used by code that doesn't do range checking.
>
> In which case, the problem is the lack of range checking, not integer
> promotion.
>
The problem is that range checking might itself be deleted by the compiler
because the compiler assumes that signed overflow cannot occur. Range
checking with unsigned numbers often involves causing overflow then
detecting it afterward, a technique that doesn't work with signed numbers
due to compiler assumptions.
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_1427_2142172725.1443119862171
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, September 19, 2015 at 8:51:44 AM UTC-7, Nicol=
Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
I'm not an expert in security, but I'm curious as to how integer pr=
omotion in expression <i>alone</i> could cause a security breach. I could s=
ee how it might cause a computation to result in an overflow or other unexp=
ected values. But I don't see how that would yield a security problem u=
nless that integer were used by code that doesn't do range checking.<br=
><div><br>In which case, the problem is the lack of range checking, not int=
eger promotion.</div></div></blockquote><div><br>The problem is that range =
checking might itself be deleted by the compiler because the compiler assum=
es that signed overflow cannot occur.=C2=A0 Range checking with unsigned nu=
mbers often involves causing overflow then detecting it afterward, a techni=
que that doesn't work with signed numbers due to compiler assumptions.<=
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" 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_1427_2142172725.1443119862171--
------=_Part_1426_195444837.1443119862171--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 24 Sep 2015 13:10:36 -0700 (PDT)
Raw View
------=_Part_1109_1297580963.1443125436691
Content-Type: multipart/alternative;
boundary="----=_Part_1110_1979576647.1443125436691"
------=_Part_1110_1979576647.1443125436691
Content-Type: text/plain; charset=UTF-8
On Thursday, September 24, 2015 at 2:37:42 PM UTC-4, Myriachan wrote:
>
> On Saturday, September 19, 2015 at 8:51:44 AM UTC-7, Nicol Bolas wrote:
>>
>> I'm not an expert in security, but I'm curious as to how integer
>> promotion in expression *alone* could cause a security breach. I could
>> see how it might cause a computation to result in an overflow or other
>> unexpected values. But I don't see how that would yield a security problem
>> unless that integer were used by code that doesn't do range checking.
>>
>> In which case, the problem is the lack of range checking, not integer
>> promotion.
>>
>
> The problem is that range checking might itself be deleted by the compiler
> because the compiler assumes that signed overflow cannot occur.
>
.... Isn't that a compiler defect? And therefore, something that should be
taken up with your compiler vendor?
I'm not saying that it isn't a problem. I'm saying that the problem of
over-optimization is best handled by compiler vendors themselves.
Alternatively, couldn't you just create and use a "safe-signed" type that
has predictable/detectable overflow behavior? It could be cast into
`size_t` as needed, right when it is to be used.
--
---
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_1110_1979576647.1443125436691
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, September 24, 2015 at 2:37:42 PM UTC-4, Myriachan wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Saturday, Septem=
ber 19, 2015 at 8:51:44 AM UTC-7, Nicol Bolas wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">I'm not an expert in security, but I&=
#39;m curious as to how integer promotion in expression <i>alone</i> could =
cause a security breach. I could see how it might cause a computation to re=
sult in an overflow or other unexpected values. But I don't see how tha=
t would yield a security problem unless that integer were used by code that=
doesn't do range checking.<br><div><br>In which case, the problem is t=
he lack of range checking, not integer promotion.</div></div></blockquote><=
div><br>The problem is that range checking might itself be deleted by the c=
ompiler because the compiler assumes that signed overflow cannot occur.</di=
v></div></blockquote><div><br>... Isn't that a compiler defect? And the=
refore, something that should be taken up with your compiler vendor?<br><br=
>I'm not saying that it isn't a problem. I'm saying that the pr=
oblem=20
of over-optimization is best handled by compiler vendors themselves.<br><br=
>Alternatively, couldn't you just create and use a "safe-signed&qu=
ot; type that has predictable/detectable overflow behavior? It could be cas=
t into `size_t` as needed, right when it is to be used.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+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_1110_1979576647.1443125436691--
------=_Part_1109_1297580963.1443125436691--
.
Author: Myriachan <myriachan@gmail.com>
Date: Mon, 28 Sep 2015 11:59:00 -0700 (PDT)
Raw View
------=_Part_6097_655116149.1443466740470
Content-Type: multipart/alternative;
boundary="----=_Part_6098_1090131569.1443466740470"
------=_Part_6098_1090131569.1443466740470
Content-Type: text/plain; charset=UTF-8
On Thursday, September 24, 2015 at 1:10:37 PM UTC-7, Nicol Bolas wrote:
>
> On Thursday, September 24, 2015 at 2:37:42 PM UTC-4, Myriachan wrote:
>>
>>
>> The problem is that range checking might itself be deleted by the
>> compiler because the compiler assumes that signed overflow cannot occur.
>>
>
> ... Isn't that a compiler defect? And therefore, something that should be
> taken up with your compiler vendor?
>
> I'm not saying that it isn't a problem. I'm saying that the problem of
> over-optimization is best handled by compiler vendors themselves.
>
>
Nope; such compilers would be entirely consistent with the Standard. I
hate that rule, but it's the rule.
// Infinite loop when x > 0 in GCC and Clang today
void Meow(int x)
{
while (x > 0)
{
x *= 2;
}
}
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_6098_1090131569.1443466740470
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, September 24, 2015 at 1:10:37 PM UTC-7, Nicol=
Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thursday, Sept=
ember 24, 2015 at 2:37:42 PM UTC-4, Myriachan wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><br><div>The problem is that range checki=
ng might itself be deleted by the compiler because the compiler assumes tha=
t signed overflow cannot occur.</div></div></blockquote><div><br>... Isn=
9;t that a compiler defect? And therefore, something that should be taken u=
p with your compiler vendor?<br><br>I'm not saying that it isn't a =
problem. I'm saying that the problem=20
of over-optimization is best handled by compiler vendors themselves.<br><br=
></div></blockquote><div><br>Nope; such compilers would be entirely consist=
ent with the Standard.=C2=A0 I hate that rule, but it's the rule.<br><b=
r><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"subpretty=
print"><span style=3D"color: #800;" class=3D"styled-by-prettify">// Infinit=
e loop when x > 0 in GCC and Clang today</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">Meow</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">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 styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">while</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">x </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: #066;" class=3D"styled-by-prettify">0</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0=
=C2=A0 x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
*=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #066;" class=3D"styled-by-prettify">2</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>=C2=A0 =C2=A0 </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span></div></code></div><br>Melissa<br></di=
v></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+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_6098_1090131569.1443466740470--
------=_Part_6097_655116149.1443466740470--
.