Topic: Should istream::read() be allowed to clobber the
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Wed, 19 Sep 2018 15:06:34 -0700 (PDT)
Raw View
------=_Part_140_668120453.1537394794267
Content-Type: multipart/alternative;
boundary="----=_Part_141_983655777.1537394794267"
------=_Part_141_983655777.1537394794267
Content-Type: text/plain; charset="UTF-8"
When you do a read on an istream with a buffer larger than the file (in
text mode) the MSVC was recently changed so that it may change bytes in the
buffer after the file length. The same goes for the C function fread().
I'm unsure if the standard actually allows this behaviour. Microsoft
recently changed the behaviour and it broke our test programs.
Microsoft claims this is allowed, I think it is not logical to allow it.
Is this behaviour allowed? If it is allowed, should it be?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/21a506dd-40ae-4cae-986d-4f014de8d859%40isocpp.org.
------=_Part_141_983655777.1537394794267
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">When you do a read on an istream with a buffer larger than=
the file (in text mode) the MSVC was recently changed so that it may chang=
e bytes in the buffer after the file length. The same goes for the C functi=
on fread().<div><br></div><div>I'm unsure if the standard actually allo=
ws this behaviour. Microsoft recently changed the behaviour and it broke ou=
r test programs.</div><div><br></div><div>Microsoft claims this is allowed,=
I think it is not logical to allow it.</div><div><br></div><div>Is this be=
haviour allowed? If it is allowed, should it be?</div><div><br></div><div><=
br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/21a506dd-40ae-4cae-986d-4f014de8d859%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/21a506dd-40ae-4cae-986d-4f014de8d859=
%40isocpp.org</a>.<br />
------=_Part_141_983655777.1537394794267--
------=_Part_140_668120453.1537394794267--
.
Author: Brian Bi <bbi5291@gmail.com>
Date: Wed, 19 Sep 2018 21:19:40 -0400
Raw View
--000000000000eaf06a057643516f
Content-Type: text/plain; charset="UTF-8"
Can you provide an example of the code and the file that produce this
behaviour? The C standard seems to allow some garbage to be written for the
last object's value if the size of the file isn't a multiple of the object
size, but I'm not sure if that's what you're talking about.
(C11 7.21.8.1/2)
.... If a partial element is read, its value is indeterminate.
>
On Wed, Sep 19, 2018 at 6:06 PM Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:
> When you do a read on an istream with a buffer larger than the file (in
> text mode) the MSVC was recently changed so that it may change bytes in the
> buffer after the file length. The same goes for the C function fread().
>
> I'm unsure if the standard actually allows this behaviour. Microsoft
> recently changed the behaviour and it broke our test programs.
>
> Microsoft claims this is allowed, I think it is not logical to allow it.
>
> Is this behaviour allowed? If it is allowed, should it be?
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/21a506dd-40ae-4cae-986d-4f014de8d859%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/21a506dd-40ae-4cae-986d-4f014de8d859%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
*Brian Bi*
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbOQo30FaJJfosjTbqroMf2yPO1%3DQZuq0GueJEiZX%2Bpjrw%40mail.gmail.com.
--000000000000eaf06a057643516f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div>Can you provide an example of the co=
de and the file that produce this behaviour? The C standard seems to allow =
some garbage to be written for the last object's value if the size of t=
he file isn't a multiple of the object size, but I'm not sure if th=
at's what you're talking about.<br></div><div><br></div><div>(C11 <=
a href=3D"http://7.21.8.1/2">7.21.8.1/2</a>)<br></div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div>... If a partial element i=
s read, its value is indeterminate.<br></div></blockquote></div></div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Sep 19, 2018 at 6:06 PM =
Bengt Gustafsson <<a href=3D"mailto:bengt.gustafsson@beamways.com">bengt=
..gustafsson@beamways.com</a>> wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">When you do a read on an istream with a buffer larger=
than the file (in text mode) the MSVC was recently changed so that it may =
change bytes in the buffer after the file length. The same goes for the C f=
unction fread().<div><br></div><div>I'm unsure if the standard actually=
allows this behaviour. Microsoft recently changed the behaviour and it bro=
ke our test programs.</div><div><br></div><div>Microsoft claims this is all=
owed, I think it is not logical to allow it.</div><div><br></div><div>Is th=
is behaviour allowed? If it is allowed, should it be?</div><div><br></div><=
div><br></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/21a506dd-40ae-4cae-986d-4f014de8d859%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/21a506dd-40ae-=
4cae-986d-4f014de8d859%40isocpp.org</a>.<br>
</blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr" class=3D"g=
mail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><d=
iv dir=3D"ltr"><font color=3D"#c0c0c0"><i>Brian Bi</i></font><br><div></div=
><div></div><div></div></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAMmfjbOQo30FaJJfosjTbqroMf2yPO1%3DQZ=
uq0GueJEiZX%2Bpjrw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbOQo30F=
aJJfosjTbqroMf2yPO1%3DQZuq0GueJEiZX%2Bpjrw%40mail.gmail.com</a>.<br />
--000000000000eaf06a057643516f--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Thu, 20 Sep 2018 00:50:06 -0700 (PDT)
Raw View
------=_Part_276_1601830266.1537429806370
Content-Type: multipart/alternative;
boundary="----=_Part_277_266712490.1537429806371"
------=_Part_277_266712490.1537429806371
Content-Type: text/plain; charset="UTF-8"
Here is the issue I posted to
Microsoft: https://developercommunity.visualstudio.com/content/problem/326138/istreamread-clobbers-up-buffer-after-last-byte-rea.html
Den torsdag 20 september 2018 kl. 03:19:54 UTC+2 skrev Brian Bi:
>
> Can you provide an example of the code and the file that produce this
> behaviour? The C standard seems to allow some garbage to be written for the
> last object's value if the size of the file isn't a multiple of the object
> size, but I'm not sure if that's what you're talking about.
>
> (C11 7.21.8.1/2)
>
> ... If a partial element is read, its value is indeterminate.
>>
> Well, that doesn't seem to be the same thing. Well, if they decided to
call with size == buffer size and count == 1 it could be interpreted like
that, I guess. It seems that both C and C++ standards need to be clarified
on this point.
> On Wed, Sep 19, 2018 at 6:06 PM Bengt Gustafsson <bengt.gu...@beamways.com
> <javascript:>> wrote:
>
>> When you do a read on an istream with a buffer larger than the file (in
>> text mode) the MSVC was recently changed so that it may change bytes in the
>> buffer after the file length. The same goes for the C function fread().
>>
>> I'm unsure if the standard actually allows this behaviour. Microsoft
>> recently changed the behaviour and it broke our test programs.
>>
>> Microsoft claims this is allowed, I think it is not logical to allow it.
>>
>> Is this behaviour allowed? If it is allowed, should it be?
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/21a506dd-40ae-4cae-986d-4f014de8d859%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/21a506dd-40ae-4cae-986d-4f014de8d859%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> --
> *Brian Bi*
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1730cf0b-2236-49d5-a2e2-0df97b1aa24e%40isocpp.org.
------=_Part_277_266712490.1537429806371
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Here is the issue I posted to Microsoft:=C2=A0https://deve=
lopercommunity.visualstudio.com/content/problem/326138/istreamread-clobbers=
-up-buffer-after-last-byte-rea.html<div><br></div><div><br><br>Den torsdag =
20 september 2018 kl. 03:19:54 UTC+2 skrev Brian Bi:<blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div dir=3D"ltr"><div>Can you provid=
e an example of the code and the file that produce this behaviour? The C st=
andard seems to allow some garbage to be written for the last object's =
value if the size of the file isn't a multiple of the object size, but =
I'm not sure if that's what you're talking about.<br></div><div=
><br></div><div>(C11 <a href=3D"http://7.21.8.1/2" target=3D"_blank" rel=3D=
"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dh=
ttp%3A%2F%2F7.21.8.1%2F2\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE3_ikRO0TH=
IjrpNByasL4ve09Lnw';return true;" onclick=3D"this.href=3D'http://ww=
w.google.com/url?q\x3dhttp%3A%2F%2F7.21.8.1%2F2\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNE3_ikRO0THIjrpNByasL4ve09Lnw';return true;">7.21.8.1/2</a>=
)<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div>... If a partial element is read, its value is indeterminate.<br></di=
v></blockquote></div></div></blockquote><div>Well, that doesn't seem to=
be the same thing. Well, if they decided to call with size =3D=3D buffer s=
ize and count =3D=3D 1 it could be interpreted like that, I guess. It seems=
that both C and C++ standards need to be clarified on this point.</div><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div></di=
v></blockquote></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Wed, Sep 19, 2018 at 6:06 PM Bengt Gustafsson <<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"oKqB8imACQAJ" rel=3D"nofollow"=
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"=
this.href=3D'javascript:';return true;">bengt.gu...@beamways.com</a=
><wbr>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
When you do a read on an istream with a buffer larger than the file (in tex=
t mode) the MSVC was recently changed so that it may change bytes in the bu=
ffer after the file length. The same goes for the C function fread().<div><=
br></div><div>I'm unsure if the standard actually allows this behaviour=
.. Microsoft recently changed the behaviour and it broke our test programs.<=
/div><div><br></div><div>Microsoft claims this is allowed, I think it is no=
t logical to allow it.</div><div><br></div><div>Is this behaviour allowed? =
If it is allowed, should it be?</div><div><br></div><div><br></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
oKqB8imACQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"oKqB8imACQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/21a506dd-40ae-4cae-986d-4f014de8d859%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/21a506dd-40ae-4cae-986d-4f014de8d859%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/21a506dd-40ae-4cae-986d-4f014de8d859%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/21a506dd-40ae-4cae-<wbr>986d-=
4f014de8d859%40isocpp.org</a><wbr>.<br>
</blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr"><div dir=
=3D"ltr"><div><div dir=3D"ltr"><font color=3D"#c0c0c0"><i>Brian Bi</i></fon=
t><br><div></div><div></div><div></div></div></div></div></div>
</blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1730cf0b-2236-49d5-a2e2-0df97b1aa24e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1730cf0b-2236-49d5-a2e2-0df97b1aa24e=
%40isocpp.org</a>.<br />
------=_Part_277_266712490.1537429806371--
------=_Part_276_1601830266.1537429806370--
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Fri, 21 Sep 2018 00:05:32 -0700 (PDT)
Raw View
------=_Part_724_2116202034.1537513532903
Content-Type: multipart/alternative;
boundary="----=_Part_725_1483955140.1537513532904"
------=_Part_725_1483955140.1537513532904
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Il giorno gioved=C3=AC 20 settembre 2018 00:06:34 UTC+2, Bengt Gustafsson h=
a=20
scritto:
>
> When you do a read on an istream with a buffer larger than the file (in=
=20
> text mode) the MSVC was recently changed so that it may change bytes in t=
he=20
> buffer after the file length. The same goes for the C function fread().
>
> I'm unsure if the standard actually allows this behaviour. Microsoft=20
> recently changed the behaviour and it broke our test programs.
>
> Microsoft claims this is allowed, I think it is not logical to allow it.
>
> Is this behaviour allowed?=20
>
This is the relevant part of the standard:=20
http://eel.is/c++draft/istream.unformatted#30
It's not specifically allowed nor denied, so I guess it could be=20
interpreted to allow the Microsoft implementation.
If it is allowed, should it be?
>
If it allows a significant optimization, as stated by the Microsoft=20
developers involved, definitely it should, in my opinion. Accessing the=20
rest of the buffer pretending that it did not get overwritten is such a=20
special and, no offense, rather useless scenario. I much rather prefer to=
=20
have the main scenario optimized than having a specific corner case=20
"correct". Again, that's my opinion.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0766c3b4-2f95-4c3a-a716-5b868551ecec%40isocpp.or=
g.
------=_Part_725_1483955140.1537513532904
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Il giorno gioved=C3=AC 20 settembre 2018 00:06:34 UTC+2, B=
engt Gustafsson ha scritto:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">When you do a read on an istream with a buffer larger than th=
e file (in text mode) the MSVC was recently changed so that it may change b=
ytes in the buffer after the file length. The same goes for the C function =
fread().<div><br></div><div>I'm unsure if the standard actually allows =
this behaviour. Microsoft recently changed the behaviour and it broke our t=
est programs.</div><div><br></div><div>Microsoft claims this is allowed, I =
think it is not logical to allow it.</div><div><br></div><div>Is this behav=
iour allowed? <br></div></div></blockquote><div><br></div><div>This is the =
relevant part of the standard: http://eel.is/c++draft/istream.unformatted#3=
0</div><div><br></div><div>It's not specifically allowed nor denied, so=
I guess it could be interpreted to allow the Microsoft implementation.</di=
v><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">=
<div>If it is allowed, should it be?</div></blockquote><div><br></div><div>=
If it allows a significant optimization, as stated by the Microsoft develop=
ers involved, definitely it should, in my opinion. Accessing the rest of th=
e buffer pretending that it did not get overwritten is such a special and, =
no offense, rather useless scenario. I much rather prefer to have the main =
scenario optimized than having a specific corner case "correct". =
Again, that's my opinion.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0766c3b4-2f95-4c3a-a716-5b868551ecec%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0766c3b4-2f95-4c3a-a716-5b868551ecec=
%40isocpp.org</a>.<br />
------=_Part_725_1483955140.1537513532904--
------=_Part_724_2116202034.1537513532903--
.