Topic: [proposal] specify behavior in case of
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Thu, 24 Aug 2017 11:57:45 +0300
Raw View
On 08/24/17 11:37, Arthur O'Dwyer wrote:
>
>
> On Thursday, August 24, 2017 at 12:04:09 AM UTC-7, crusad...@gmail.com
> wrote:
>
> On Wednesday, August 23, 2017 at 5:31:45 PM UTC-5, Bryce Glover wrote:
>
>> On Aug 23, 2017, at 6:13 PM, std-pr...@isocpp.org wrote:
>>
>> Hi,
>>
>> I looked around this forum and realized that it is populated
>> by the same
>> people as discussion forum. Premises for this proposal were
>> discussed there
>> few days ago and some of you probably remember it. It makes my
>> task a bit
>> easier. :)
>>
>> Here is the draft:
>> https://github.com/crusader-mike/misc/blob/master/D0770R0.md
>> <https://github.com/crusader-mike/misc/blob/master/D0770R0.md>
>
>
> Can you explain how your mechanism would handle a program like this one,
> where there's more than one exception in flight at once?
> https://wandbox.org/permlink/G23Eqak3aYVufquA
> If you find that you /can/ handle this program without heap-allocation,
> then you should trumpet that solution to the world, regardless of
> whether the proposal itself is a good idea or not.
> OTOH, if you find that you have no idea how to implement your proposal,
> you probably shouldn't formally propose it. ;) Not that there's anything
> wrong with starting a discussion on the topic.
>
> I'd rather see a paper that tackled either of the two really hard
> problems that your paper tiptoes around:
> (A) Exception handling mechanisms require(?) dynamic memory allocation,
> and don't allow the programmer to specify a custom allocation mechanism
> (B) C++ pretends that stack exhaustion is impossible, which is a big fat lie
>
> If you don't propose a solution for (B), then you haven't really changed
> the situation, have you? The current situation is "Your program can
> crash at any time, if it exhausts a resource that exists IRL but which
> the Standard doesn't mention," and if you patch the standard according
> to your proposal, the situation will still be "Your program can crash at
> any time, if it exhausts a resource that exists IRL but which the
> Standard doesn't mention."
>
> Do you actually see this failure mode in real code?
We touched the stack overflow problem in the earlier discussion on
std-discussion. IMO, stack overflow is a separate problem that may have
a separate solution. This proposal focuses on the problem with throwing
exceptions, and I think this is the right approach.
Stack overflow happens when your program reaches a certain
implementation-specific limit, and your program can be written in a way
that this never happens (i.e. you can target specific implementations).
OOM, on the other hand, can happen at any time regardless of how you
write your program. This means that SO can be considered an
implementation limit and be largely ignored by the standard, while OOM
is a general possibility, and the language has to offer the user ways to
handle it, preferably without terminating the application right away.
--
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/7c5b6814-4935-33f3-07fc-05c8d22cf5ad%40gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 24 Aug 2017 09:07:35 -0700 (PDT)
Raw View
------=_Part_1357_594228243.1503590855762
Content-Type: multipart/alternative;
boundary="----=_Part_1358_1005098631.1503590855762"
------=_Part_1358_1005098631.1503590855762
Content-Type: text/plain; charset="UTF-8"
On Thursday, August 24, 2017 at 4:57:51 AM UTC-4, Andrey Semashev wrote:
>
> On 08/24/17 11:37, Arthur O'Dwyer wrote:
> >
> >
> > On Thursday, August 24, 2017 at 12:04:09 AM UTC-7, crusad...@gmail.com
> > wrote:
> >
> > On Wednesday, August 23, 2017 at 5:31:45 PM UTC-5, Bryce Glover
> wrote:
> >
> >> On Aug 23, 2017, at 6:13 PM, std-pr...@isocpp.org wrote:
> >>
> >> Hi,
> >>
> >> I looked around this forum and realized that it is populated
> >> by the same
> >> people as discussion forum. Premises for this proposal were
> >> discussed there
> >> few days ago and some of you probably remember it. It makes my
> >> task a bit
> >> easier. :)
> >>
> >> Here is the draft:
> >> https://github.com/crusader-mike/misc/blob/master/D0770R0.md
> >> <https://github.com/crusader-mike/misc/blob/master/D0770R0.md>
> >
> >
> > Can you explain how your mechanism would handle a program like this one,
> > where there's more than one exception in flight at once?
> > https://wandbox.org/permlink/G23Eqak3aYVufquA
> > If you find that you /can/ handle this program without heap-allocation,
> > then you should trumpet that solution to the world, regardless of
> > whether the proposal itself is a good idea or not.
> > OTOH, if you find that you have no idea how to implement your proposal,
> > you probably shouldn't formally propose it. ;) Not that there's anything
> > wrong with starting a discussion on the topic.
> >
> > I'd rather see a paper that tackled either of the two really hard
> > problems that your paper tiptoes around:
> > (A) Exception handling mechanisms require(?) dynamic memory allocation,
> > and don't allow the programmer to specify a custom allocation mechanism
> > (B) C++ pretends that stack exhaustion is impossible, which is a big fat
> lie
> >
> > If you don't propose a solution for (B), then you haven't really changed
> > the situation, have you? The current situation is "Your program can
> > crash at any time, if it exhausts a resource that exists IRL but which
> > the Standard doesn't mention," and if you patch the standard according
> > to your proposal, the situation will still be "Your program can crash at
> > any time, if it exhausts a resource that exists IRL but which the
> > Standard doesn't mention."
> >
> > Do you actually see this failure mode in real code?
>
> We touched the stack overflow problem in the earlier discussion on
> std-discussion. IMO, stack overflow is a separate problem that may have
> a separate solution. This proposal focuses on the problem with throwing
> exceptions, and I think this is the right approach.
>
> Stack overflow happens when your program reaches a certain
> implementation-specific limit, and your program can be written in a way
> that this never happens (i.e. you can target specific implementations).
> OOM, on the other hand, can happen at any time regardless of how you
> write your program. This means that SO can be considered an
> implementation limit and be largely ignored by the standard, while OOM
> is a general possibility, and the language has to offer the user ways to
> handle it, preferably without terminating the application right away.
>
But if you're already targeting specific implementations, then what the
standard says is essentially irrelevant. What you want is an implementation
that can guarantee the ability to throw. It's not clear why that behavior
needs to be required by the standard, since you're willing to build your
code on implementation-specific requirements anyway.
This would simply be one more requirement.
--
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/abc032c7-0828-4060-82b1-c6039f706db5%40isocpp.org.
------=_Part_1358_1005098631.1503590855762
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, August 24, 2017 at 4:57:51 AM UTC-4, Andrey S=
emashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 08/24/17 11:3=
7, Arthur O'Dwyer wrote:
<br>>=20
<br>>=20
<br>> On Thursday, August 24, 2017 at 12:04:09 AM UTC-7, <a>crusad...@gm=
ail.com</a>=20
<br>> wrote:
<br>>=20
<br>> =C2=A0 =C2=A0 On Wednesday, August 23, 2017 at 5:31:45 PM UTC-5, B=
ryce Glover wrote:
<br>>=20
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Aug 23, 2017, at 6:13 PM, <a>st=
d-pr...@isocpp.org</a> wrote:
<br>>>
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,
<br>>>
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 I looked around this forum and rea=
lized that it is populated
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 by the same
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 people as discussion forum. Premis=
es for this proposal were
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 discussed there
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 few days ago and some of you proba=
bly remember it. It makes my
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 task a bit
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 easier. :)
<br>>>
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Here is the draft:
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://github.com/crus=
ader-mike/misc/blob/master/D0770R0.md" target=3D"_blank" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%=
2Fgithub.com%2Fcrusader-mike%2Fmisc%2Fblob%2Fmaster%2FD0770R0.md\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNHFZk2ciNqn7OnemSbYmJiXT3625w';return true=
;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%=
2Fgithub.com%2Fcrusader-mike%2Fmisc%2Fblob%2Fmaster%2FD0770R0.md\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNHFZk2ciNqn7OnemSbYmJiXT3625w';return true=
;">https://github.com/crusader-<wbr>mike/misc/blob/master/D0770R0.<wbr>md</=
a>
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"https://github.com/=
crusader-mike/misc/blob/master/D0770R0.md" target=3D"_blank" rel=3D"nofollo=
w" onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A=
%2F%2Fgithub.com%2Fcrusader-mike%2Fmisc%2Fblob%2Fmaster%2FD0770R0.md\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHFZk2ciNqn7OnemSbYmJiXT3625w';return =
true;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A=
%2F%2Fgithub.com%2Fcrusader-mike%2Fmisc%2Fblob%2Fmaster%2FD0770R0.md\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHFZk2ciNqn7OnemSbYmJiXT3625w';return =
true;">https://github.com/crusader-<wbr>mike/misc/blob/master/D0770R0.<wbr>=
md</a>>
<br>>=20
<br>>=20
<br>> Can you explain how your mechanism would handle a program like thi=
s one,=20
<br>> where there's more than one exception in flight at once?
<br>> <a href=3D"https://wandbox.org/permlink/G23Eqak3aYVufquA" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.go=
ogle.com/url?q\x3dhttps%3A%2F%2Fwandbox.org%2Fpermlink%2FG23Eqak3aYVufquA\x=
26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGuws0-XNuqXBBLTk4HjkswwllWmw';re=
turn true;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhtt=
ps%3A%2F%2Fwandbox.org%2Fpermlink%2FG23Eqak3aYVufquA\x26sa\x3dD\x26sntz\x3d=
1\x26usg\x3dAFQjCNGuws0-XNuqXBBLTk4HjkswwllWmw';return true;">https://w=
andbox.org/permlink/<wbr>G23Eqak3aYVufquA</a>
<br>> If you find that you /can/ handle this program without heap-alloca=
tion,=20
<br>> then you should trumpet that solution to the world, regardless of=
=20
<br>> whether the proposal itself is a good idea or not.
<br>> OTOH, if you find that you have no idea how to implement your prop=
osal,=20
<br>> you probably shouldn't formally propose it. ;) Not that there&=
#39;s anything=20
<br>> wrong with starting a discussion on the topic.
<br>>=20
<br>> I'd rather see a paper that tackled either of the two really h=
ard=20
<br>> problems that your paper tiptoes around:
<br>> (A) Exception handling mechanisms require(?) dynamic memory alloca=
tion,=20
<br>> and don't allow the programmer to specify a custom allocation =
mechanism
<br>> (B) C++ pretends that stack exhaustion is impossible, which is a b=
ig fat lie
<br>>=20
<br>> If you don't propose a solution for (B), then you haven't =
really changed=20
<br>> the situation, have you? The current situation is "Your progr=
am can=20
<br>> crash at any time, if it exhausts a resource that exists IRL but w=
hich=20
<br>> the Standard doesn't mention," and if you patch the stand=
ard according=20
<br>> to your proposal, the situation will still be "Your program c=
an crash at=20
<br>> any time, if it exhausts a resource that exists IRL but which the=
=20
<br>> Standard doesn't mention."
<br>>=20
<br>> Do you actually see this failure mode in real code?
<br>
<br>We touched the stack overflow problem in the earlier discussion on=20
<br>std-discussion. IMO, stack overflow is a separate problem that may have=
=20
<br>a separate solution. This proposal focuses on the problem with throwing=
=20
<br>exceptions, and I think this is the right approach.
<br>
<br>Stack overflow happens when your program reaches a certain=20
<br>implementation-specific limit, and your program can be written in a way=
=20
<br>that this never happens (i.e. you can target specific implementations).=
=20
<br>OOM, on the other hand, can happen at any time regardless of how you=20
<br>write your program. This means that SO can be considered an=20
<br>implementation limit and be largely ignored by the standard, while OOM=
=20
<br>is a general possibility, and the language has to offer the user ways t=
o=20
<br>handle it, preferably without terminating the application right away.
<br></blockquote><div><br>But if you're already targeting specific impl=
ementations, then what the standard says is essentially irrelevant. What yo=
u want is an implementation that can guarantee the ability to throw. It'=
;s not clear why that behavior needs to be required by the standard, since =
you're willing to build your code on implementation-specific requiremen=
ts anyway.<br><br>This would simply be one more requirement.<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/abc032c7-0828-4060-82b1-c6039f706db5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/abc032c7-0828-4060-82b1-c6039f706db5=
%40isocpp.org</a>.<br />
------=_Part_1358_1005098631.1503590855762--
------=_Part_1357_594228243.1503590855762--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Thu, 24 Aug 2017 18:15:36 +0200
Raw View
--001a11352e1e82347605578223cc
Content-Type: text/plain; charset="UTF-8"
On Thu, Aug 24, 2017 at 10:37 AM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:
> Can you explain how your mechanism would handle a program like this one,
where there's more than one exception in flight at once?
> https://wandbox.org/permlink/G23Eqak3aYVufquA
> If you find that you *can* handle this program without heap-allocation,
then you should trumpet that solution to the world, regardless of whether
the proposal itself is a good idea or not.
That code compiles and runs just fine under MSVC, where every bad_alloc is
allocated on stack.
> If you don't propose a solution for (B), then you haven't really changed
the situation, have you?
I agree with Andrey on this one: this is an issue more general than
exception handling. The motivation in the proposal is to make exception
handling as reliable as error handling is in C. C is not immune to stack
overflows.
Cheers,
V.
--
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/CAA7YVg3PfJ%3DmgH%2B0yuvqxQUvCFKXONG29Wbqb2U%2Brz9T-v_W1w%40mail.gmail.com.
--001a11352e1e82347605578223cc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Aug 24, 2017 at 10:37 AM, Arthur O'Dwyer <span dir=3D"ltr"><<a h=
ref=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@=
gmail.com</a>></span> wrote:<br><div><br></div><div>> Can you explain=
how your mechanism would handle a program like this one, where there's=
more than one exception in flight at once?</div><div>>=C2=A0<a href=3D"=
https://wandbox.org/permlink/G23Eqak3aYVufquA" target=3D"_blank">https://wa=
ndbox.org/permlink/<wbr>G23Eqak3aYVufquA</a></div><div>> If you find tha=
t you <i>can</i> handle this program without heap-allocation, then you shou=
ld trumpet that solution to the world, regardless of whether the proposal i=
tself is a good idea or not.</div><div><br></div><div>That code compiles an=
d runs just fine under MSVC, where every bad_alloc is allocated on stack.<b=
r></div><div><br></div><div>> If you don't propose a solution for (B=
), then you haven't really changed the situation, have you?</div><div><=
br></div><div>I agree with Andrey on this one: this is an issue more genera=
l than exception handling. The motivation in the proposal is to make except=
ion handling as reliable as error handling is in C. C is not immune to stac=
k overflows.</div><div><br></div><div>Cheers,</div><div>V.</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/CAA7YVg3PfJ%3DmgH%2B0yuvqxQUvCFKXONG2=
9Wbqb2U%2Brz9T-v_W1w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3PfJ=
%3DmgH%2B0yuvqxQUvCFKXONG29Wbqb2U%2Brz9T-v_W1w%40mail.gmail.com</a>.<br />
--001a11352e1e82347605578223cc--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Thu, 24 Aug 2017 11:04:44 -0700 (PDT)
Raw View
------=_Part_1475_668414998.1503597884899
Content-Type: multipart/alternative;
boundary="----=_Part_1476_1285365711.1503597884900"
------=_Part_1476_1285365711.1503597884900
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Thursday, August 24, 2017 at 9:15:39 AM UTC-7, Viacheslav Usov wrote:
>
> On Thu, Aug 24, 2017 at 10:37 AM, Arthur O'Dwyer <arthur....@gmail.com=20
> <javascript:>> wrote:
>
> > Can you explain how your mechanism would handle a program like this one=
,=20
> where there's more than one exception in flight at once?
> > https://wandbox.org/permlink/G23Eqak3aYVufquA
> > If you find that you *can* handle this program without heap-allocation,=
=20
> then you should trumpet that solution to the world, regardless of whether=
=20
> the proposal itself is a good idea or not.
>
> That code compiles and runs just fine under MSVC, where every bad_alloc i=
s=20
> allocated on stack.
>
Is there a good resource for learning how MSVC does exceptions? (I don't=20
even have a Windows machine, so I'm looking more for blog posts and things=
=20
than for "dump this DLL and read it". :))
=20
> > If you don't propose a solution for (B), then you haven't really change=
d=20
> the situation, have you?
>
> I agree with Andrey on this one: this is an issue more general than=20
> exception handling. The motivation in the proposal is to make exception=
=20
> handling as reliable as error handling is in C. C is not immune to stack=
=20
> overflows.
>
That's fair.
So this is more about chipping away at the differences between C++ EH and=
=20
error codes, than about fixing up UB "holes" in C++. The holes are allowed=
=20
to remain, as long as the EH and no-EH sides have to deal with the *same*=
=20
holes. That's a fair point of view.
=E2=80=93Arthur
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/574ffdae-511b-49d7-a020-2129f8c8daae%40isocpp.or=
g.
------=_Part_1476_1285365711.1503597884900
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, August 24, 2017 at 9:15:39 AM UTC-7, Viachesl=
av Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote">On Thu, Aug 24, 2017 at 10:37 AM, Arthur O=
'Dwyer <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"L7hAJd5gCwAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D'javascript:';return true;" onclick=3D"this.href=3D'jav=
ascript:';return true;">arthur....@gmail.com</a>></span> wrote:<br><=
div><br></div><div>> Can you explain how your mechanism would handle a p=
rogram like this one, where there's more than one exception in flight a=
t once?</div><div>>=C2=A0<a href=3D"https://wandbox.org/permlink/G23Eqak=
3aYVufquA" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwandbox.org%2Fpermlink%2FG=
23Eqak3aYVufquA\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGuws0-XNuqXBBLTk4Hj=
kswwllWmw';return true;" onclick=3D"this.href=3D'https://www.google=
..com/url?q\x3dhttps%3A%2F%2Fwandbox.org%2Fpermlink%2FG23Eqak3aYVufquA\x26sa=
\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGuws0-XNuqXBBLTk4HjkswwllWmw';return=
true;">https://wandbox.org/<wbr>permlink/G23Eqak3aYVufquA</a></div><div>&g=
t; If you find that you <i>can</i> handle this program without heap-allocat=
ion, then you should trumpet that solution to the world, regardless of whet=
her the proposal itself is a good idea or not.</div><div><br></div><div>Tha=
t code compiles and runs just fine under MSVC, where every bad_alloc is all=
ocated on stack.<br></div></div></div></div></blockquote><div><br></div><di=
v>Is there a good resource for learning how MSVC does exceptions? (I don=
9;t even have a Windows machine, so I'm looking more for blog posts and=
things than for "dump this DLL and read it". :))</div><div><br><=
/div><div>=C2=A0</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 class=3D"gmail_quote"><div></div><div>> If you don't p=
ropose a solution for (B), then you haven't really changed the situatio=
n, have you?<br></div><div><br></div><div>I agree with Andrey on this one: =
this is an issue more general than exception handling. The motivation in th=
e proposal is to make exception handling as reliable as error handling is i=
n C. C is not immune to stack overflows.</div></div></div></blockquote><div=
><br></div><div>That's fair.</div><div>So this is more about chipping a=
way at the differences between C++ EH and error codes, than about fixing up=
UB "holes" in C++. The holes are allowed to remain, as long as t=
he EH and no-EH sides have to deal with the <i>same</i> holes. That's a=
fair point of view.</div><div><br></div><div>=E2=80=93Arthur</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/574ffdae-511b-49d7-a020-2129f8c8daae%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/574ffdae-511b-49d7-a020-2129f8c8daae=
%40isocpp.org</a>.<br />
------=_Part_1476_1285365711.1503597884900--
------=_Part_1475_668414998.1503597884899--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Thu, 24 Aug 2017 21:33:26 +0300
Raw View
On 08/24/17 19:07, Nicol Bolas wrote:
>
> But if you're already targeting specific implementations, then what the
> standard says is essentially irrelevant. What you want is an
> implementation that can guarantee the ability to throw. It's not clear
> why that behavior needs to be required by the standard, since you're
> willing to build your code on implementation-specific requirements anyway.
>
> This would simply be one more requirement.
Because currently the standard allows the implementation to abort the
application or deadlock, which is totally unhelpful. That behavior
typically cannot be changed, and can happen at any point in run time.
Generally, accounting for stack overflow is not a problem because that
limit is either reasonably high or at least known. Barring bugs, most
applications won't reach the stack size limit without any special
measures taken. That is not the case with OOM, and therefore this
problem is more critical.
--
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/ef835eda-989c-40a9-98bf-d51f952a19b6%40gmail.com.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 24 Aug 2017 13:14:48 -0700
Raw View
On Thursday, 24 August 2017 01:57:45 PDT Andrey Semashev wrote:
> We touched the stack overflow problem in the earlier discussion on
> std-discussion. IMO, stack overflow is a separate problem that may have
> a separate solution. This proposal focuses on the problem with throwing
> exceptions, and I think this is the right approach.
>
> Stack overflow happens when your program reaches a certain
> implementation-specific limit, and your program can be written in a way
> that this never happens (i.e. you can target specific implementations).
> OOM, on the other hand, can happen at any time regardless of how you
> write your program.
You can also have stack overflow *because* of OOM. If your application is well-
behaved and uses just a few kilobytes of stack, except for one particular
function that grows by (say) 128kB, you may not have faulted those extra 32
pages yet -- or they may have been reclaimed because the OS can get your stack
pointer in a context switch.
If the system is in OOM condition when you do fault them, the OS may not be
able to provide them.
So even a properly-written & stack-bounded application can OOM due to stack
overflow.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1583319.gYqCkEa9ry%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 24 Aug 2017 13:20:16 -0700
Raw View
On Thursday, 24 August 2017 11:04:44 PDT Arthur O'Dwyer wrote:
> Is there a good resource for learning how MSVC does exceptions? (I don't
> even have a Windows machine, so I'm looking more for blog posts and things
> than for "dump this DLL and read it".
Unfortunately, no. The Microsoft SEH (Structured Exception Handling) isn't
very documented (at all?) and was one of the big reasons why GCC/MinGW used
setjump/longjump exception handling on Windows for a long time.
Even to this day, you have to be careful about mixing libraries built for
SJLJ, SEH or DW2 exception handling. It might be the default for 32-bit MinGW
(but maybe not for 32-bit MinGW-w64).
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/100250911.1TEaBDO2OI%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 24 Aug 2017 13:34:47 -0700
Raw View
On Thursday, 24 August 2017 13:26:14 PDT Ray Hamel wrote:
> Could throw-expressions be extended to allow storage class specifiers?
>
> // Constructs exception object in-place, may fail
> throw std::runtime_error("foo");
>
> // Constructs exception object at thread/program start
> thread_local throw std::runtime_error("bar");
> static throw std::runtime_error("baz");
It wouldn't be too difficult for the compiler to record the object sizes for
every throw anyway.
For every translation unit, save the size of the largest object thrown.
During linking, the linker merges each object file's size and saves the maximum
(if the linker can't do it, just save each translation unit's size next to
each other in the same binary section).
During dynamic linking, the program loader find the maximum for each module
loaded and saves that in a global variable. It then reserves that space in a
thread-specific buffer.
During execution, if another library is loaded with a maximum higher than the
currently-reserved buffer, attempt to resize it for all running threads. If
that fails, fail to load the library with an OOM condition.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2180216.6Peda3kyM6%40tjmaciei-mobl1.
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Thu, 24 Aug 2017 14:02:57 -0700
Raw View
--94eb2c1959f82ff90e055786270d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Thu, Aug 24, 2017 at 1:34 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> On Thursday, 24 August 2017 13:26:14 PDT Ray Hamel wrote:
> > Could throw-expressions be extended to allow storage class specifiers?
> >
> > // Constructs exception object in-place, may fail
> > throw std::runtime_error("foo");
> >
> > // Constructs exception object at thread/program start
> > thread_local throw std::runtime_error("bar");
> > static throw std::runtime_error("baz");
>
> It wouldn't be too difficult for the compiler to record the object sizes
> for
> every throw anyway.
> For every translation unit, save the size of the largest object thrown.
> [...]
>
I don't think either of you have considered that there may be multiple
exceptions in-flight (or else I'm missing something fundamental that you're
both assuming implicitly).
Suppose we preallocate 16 bytes so that we can throw runtime_error... and
then we do throw it... and then, while unwinding the stack, we throw
*another* instance of runtime_error. Don't we now have to get *another* 16
bytes of storage from somewhere?
Not to mention, even if we only throw zero-byte objects, there's still a
certain amount of overhead just for the bookkeeping... I *think*. Please
let me know if I'm missing something here.
See my earlier reply in this thread, which included a program that has
about 100 exceptions in-flight at once.
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0KYHpSP0-M%2BUsw17-fH7L-0UoVJPRfesF%3DgD5_=
qg3JroA%40mail.gmail.com.
--94eb2c1959f82ff90e055786270d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Aug 24, 2017 at 1:34 PM, Thiago Macieira <span dir=
=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiag=
o@macieira.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Thurs=
day, 24 August 2017 13:26:14 PDT Ray Hamel wrote:<br>
> Could throw-expressions be extended to allow storage class specifiers?=
<br>
><br>
> // Constructs exception object in-place, may fail<br>
> throw std::runtime_error("foo");<br>
><br>
> // Constructs exception object at thread/program start<br>
> thread_local throw std::runtime_error("bar");<br>
> static throw std::runtime_error("baz");<br>
<br>
</span>It wouldn't be too difficult for the compiler to record the obje=
ct sizes for<br>
every throw anyway.<br>
For every translation unit, save the size of the largest object thrown. [..=
..]<br></blockquote><div><br></div><div>I don't think either of you have=
considered that there may be multiple exceptions in-flight (or else I'=
m missing something fundamental that you're both assuming implicitly).<=
/div><div><br></div><div>Suppose we preallocate 16 bytes so that we can thr=
ow runtime_error... and then we do throw it... and then, while unwinding th=
e stack, we throw <i>another</i> instance of runtime_error. Don't we no=
w have to get <i>another</i> 16 bytes of storage from somewhere?</div><div>=
Not to mention, even if we only throw zero-byte objects, there's still =
a certain amount of overhead just for the bookkeeping... I <i>think</i>. Pl=
ease let me know if I'm missing something here.</div><div><br></div><di=
v>See my earlier reply in this thread, which included a program that has ab=
out 100 exceptions in-flight at once.</div><div><br></div><div>=E2=80=93Art=
hur</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/CADvuK0KYHpSP0-M%2BUsw17-fH7L-0UoVJPR=
fesF%3DgD5_qg3JroA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0KYHpSP=
0-M%2BUsw17-fH7L-0UoVJPRfesF%3DgD5_qg3JroA%40mail.gmail.com</a>.<br />
--94eb2c1959f82ff90e055786270d--
.
Author: Ray Hamel <rayghamel@gmail.com>
Date: Thu, 24 Aug 2017 15:12:11 -0700 (PDT)
Raw View
------=_Part_1961_2123940079.1503612731814
Content-Type: multipart/alternative;
boundary="----=_Part_1962_37674747.1503612731814"
------=_Part_1962_37674747.1503612731814
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Thursday, August 24, 2017 at 5:03:01 PM UTC-4, Arthur O'Dwyer wrote:
>
> I don't think either of you have considered that there may be multiple=20
> exceptions in-flight (or else I'm missing something fundamental that you'=
re=20
> both assuming implicitly).
>
> Suppose we preallocate 16 bytes so that we can throw runtime_error... and=
=20
> then we do throw it... and then, while unwinding the stack, we throw=20
> *another* instance of runtime_error. Don't we now have to get *another*=
=20
> 16 bytes of storage from somewhere?
> Not to mention, even if we only throw zero-byte objects, there's still a=
=20
> certain amount of overhead just for the bookkeeping... I *think*. Please=
=20
> let me know if I'm missing something here.
>
> See my earlier reply in this thread, which included a program that has=20
> about 100 exceptions in-flight at once.
>
> =E2=80=93Arthur
>
Different idea; what about a function `set_oom_buffer` with the prototype
// allocates an implementation-defined global thread-safe buffer
template<std::size_t N>
void std::set_oom_buffer();
and/or
// registers a buffer (UB to access or deallocate after registering)
void std::set_oom_buffer(void *buffer, std::size_t n) noexcept;
The buffer may be used by the constructor of `std::exception` and=20
subclasses, and to construct other implementation (or user?)-defined=20
objects, in the event that normal allocation fails.
This has the advantage of (mostly) maintaining the "you don't pay for what=
=20
you don't use" principle, is relatively easy to implement and wouldn't=20
alter the semantics of existing programs.
-Ray
--=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/19c778a1-649e-48fd-ba1f-6d6c067d6d37%40isocpp.or=
g.
------=_Part_1962_37674747.1503612731814
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, August 24, 2017 at 5:03:01 PM UTC-4, Arthur O=
'Dwyer 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 don't think either of you have considered that there may be multi=
ple exceptions in-flight (or else I'm missing something fundamental tha=
t you're both assuming implicitly).<div><div class=3D"gmail_quote"><div=
><br></div><div>Suppose we preallocate 16 bytes so that we can throw runtim=
e_error... and then we do throw it... and then, while unwinding the stack, =
we throw <i>another</i> instance of runtime_error. Don't we now have to=
get <i>another</i> 16 bytes of storage from somewhere?</div><div>Not to me=
ntion, even if we only throw zero-byte objects, there's still a certain=
amount of overhead just for the bookkeeping... I <i>think</i>. Please let =
me know if I'm missing something here.</div><div><br></div><div>See my =
earlier reply in this thread, which included a program that has about 100 e=
xceptions in-flight at once.</div><div><br></div><div>=E2=80=93Arthur</div>=
</div></div></div></blockquote><div><br></div><div>Different idea; what abo=
ut a function `<span style=3D"font-family: courier new,monospace;">set_oom_=
buffer</span>` with the prototype</div><div><br></div><div><div style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"pre=
ttyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span s=
tyle=3D"color: #800;" class=3D"styled-by-prettify">// allocates an implemen=
tation-defined global thread-safe buffer</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: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">size_t N</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">void</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">set_oom_buffer</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>=
and/or<br></div><div><br></div><div><div style=3D"background-color: rgb(250=
, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-=
width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #800;"=
class=3D"styled-by-prettify">// registers a buffer (UB to access or deallo=
cate after registering)</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">set_oom_buffe=
r</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">buffer</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">,</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-pret=
tify">size_t n</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> noex=
cept</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n></div></code></div><br>The buffer may be used by the constructor of `<spa=
n style=3D"font-family: courier new,monospace;">std::exception</span>` and =
subclasses, and to construct other implementation (or user?)-defined object=
s, in the event that normal allocation fails.</div><div><br></div><div>This=
has the advantage of (mostly) maintaining the "you don't pay for =
what you don't use" principle, is relatively easy to implement and=
wouldn't alter the semantics of existing programs.<br></div><div><br><=
/div><div>-Ray<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/19c778a1-649e-48fd-ba1f-6d6c067d6d37%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/19c778a1-649e-48fd-ba1f-6d6c067d6d37=
%40isocpp.org</a>.<br />
------=_Part_1962_37674747.1503612731814--
------=_Part_1961_2123940079.1503612731814--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 24 Aug 2017 17:27:52 -0700
Raw View
On Thursday, 24 August 2017 14:02:57 PDT Arthur O'Dwyer wrote:
> On Thu, Aug 24, 2017 at 1:34 PM, Thiago Macieira <thiago@macieira.org>
>
> wrote:
> > On Thursday, 24 August 2017 13:26:14 PDT Ray Hamel wrote:
> > > Could throw-expressions be extended to allow storage class specifiers?
> > >
> > > // Constructs exception object in-place, may fail
> > > throw std::runtime_error("foo");
> > >
> > > // Constructs exception object at thread/program start
> > > thread_local throw std::runtime_error("bar");
> > > static throw std::runtime_error("baz");
> >
> > It wouldn't be too difficult for the compiler to record the object sizes
> > for
> > every throw anyway.
> > For every translation unit, save the size of the largest object thrown.
> > [...]
>
> I don't think either of you have considered that there may be multiple
> exceptions in-flight (or else I'm missing something fundamental that you're
> both assuming implicitly).
I thought you meant multiple as in "in multiple threads". That's why I made it
a thread-specific reservation.
I thought an exception throw during unwinding would cause std::terminate.
> Suppose we preallocate 16 bytes so that we can throw runtime_error... and
> then we do throw it... and then, while unwinding the stack, we throw
> *another* instance of runtime_error. Don't we now have to get *another* 16
> bytes of storage from somewhere?
See above. My lack of knowledge about exceptions.
Oh well, this won't work.
> Not to mention, even if we only throw zero-byte objects, there's still a
> certain amount of overhead just for the bookkeeping... I *think*. Please
> let me know if I'm missing something here.
Sure, but the overhead is usually known to the implementation, so that can be
added to the buffer size.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1706311.r2Qm9aVPCx%40tjmaciei-mobl1.
.
Author: crusader.mike@gmail.com
Date: Thu, 24 Aug 2017 18:02:54 -0700 (PDT)
Raw View
------=_Part_2067_622515724.1503622974460
Content-Type: multipart/alternative;
boundary="----=_Part_2068_844815263.1503622974460"
------=_Part_2068_844815263.1503622974460
Content-Type: text/plain; charset="UTF-8"
On Thursday, August 24, 2017 at 3:14:54 PM UTC-5, Thiago Macieira wrote:
>
> On Thursday, 24 August 2017 01:57:45 PDT Andrey Semashev wrote:
> > We touched the stack overflow problem in the earlier discussion on
> > std-discussion. IMO, stack overflow is a separate problem that may have
> > a separate solution. This proposal focuses on the problem with throwing
> > exceptions, and I think this is the right approach.
> >
> > Stack overflow happens when your program reaches a certain
> > implementation-specific limit, and your program can be written in a way
> > that this never happens (i.e. you can target specific implementations).
> > OOM, on the other hand, can happen at any time regardless of how you
> > write your program.
>
> You can also have stack overflow *because* of OOM. If your application is
> well-
> behaved and uses just a few kilobytes of stack, except for one particular
> function that grows by (say) 128kB, you may not have faulted those extra
> 32
> pages yet -- or they may have been reclaimed because the OS can get your
> stack
> pointer in a context switch.
>
> If the system is in OOM condition when you do fault them, the OS may not
> be
> able to provide them.
>
> So even a properly-written & stack-bounded application can OOM due to
> stack
> overflow.
>
I'd like to try to put this whole "no memory pages" argument to rest... I
touched it a little bit in my answer to Arthur, but I'll expand on that
here:
Our technology stack consists of multiple layers, where each layer below
gives certain guarantees to layer above: ((hardware -> OS) -> C++ runtime)
-> C++ code.
If memory controller discovers that it can't read a value at certain memory
bank (because of damage due to cosmic rays) -- do you expect OS to handle
that? No, you expect OS to stop immediately before it does any damage.
Same with C++ code -- if I allocated memory (or wrote a program that needs
128kb of stack) and that memory can't be provided by underlying layer -- it
is a situation that doesn't "require diagnostic" (on the level of C++
program). So from OS perspective it looks like "meh... we tried, but it did
work -- better kill it before it went nuts and formatted hard drive" (or
suspend it and wait until page becomes available). From C++ code
perspective -- time stops and universe ceases existing. It becomes
implementation problem -- I, as developer, write a program that needs
certain guarantees to base my own guarantees on. The guy who deploys my
program needs to configure system in such way that these guarantees are
provided. If he doesn't do that -- he better have a plan B (failover/etc).
So, yeah, my argument is basically that OOM on C++ level and OOM on OS
level are independent things and conflating them leads to unnecessary
confusion.
--
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
>
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/eb1357de-2bbc-40b5-9255-5d16c9aa2a4c%40isocpp.org.
------=_Part_2068_844815263.1503622974460
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, August 24, 2017 at 3:14:54 PM UTC-5, =
Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thurs=
day, 24 August 2017 01:57:45 PDT Andrey Semashev wrote:
<br>> We touched the stack overflow problem in the earlier discussion on
<br>> std-discussion. IMO, stack overflow is a separate problem that may=
have
<br>> a separate solution. This proposal focuses on the problem with thr=
owing
<br>> exceptions, and I think this is the right approach.
<br>>=20
<br>> Stack overflow happens when your program reaches a certain
<br>> implementation-specific limit, and your program can be written in =
a way
<br>> that this never happens (i.e. you can target specific implementati=
ons).
<br>> OOM, on the other hand, can happen at any time regardless of how y=
ou
<br>> write your program.
<br>
<br>You can also have stack overflow *because* of OOM. If your application =
is well-
<br>behaved and uses just a few kilobytes of stack, except for one particul=
ar=20
<br>function that grows by (say) 128kB, you may not have faulted those extr=
a 32=20
<br>pages yet -- or they may have been reclaimed because the OS can get you=
r stack=20
<br>pointer in a context switch.=20
<br>
<br>If the system is in OOM condition when you do fault them, the OS may no=
t be=20
<br>able to provide them.
<br>
<br>So even a properly-written & stack-bounded application can OOM due =
to stack=20
<br>overflow.
<br></blockquote><div><br></div><div>I'd like to try to put this whole =
"no memory pages" argument to rest... I touched it a little bit i=
n my answer to Arthur, but I'll expand on that here:</div><div>Our tech=
nology stack consists of multiple layers, where each layer below gives cert=
ain guarantees to layer above: ((hardware -> OS) -> C++ runtime) ->=
; C++ code.</div><div>If memory controller discovers that it can't read=
a value at certain memory bank (because of damage due to cosmic rays) -- d=
o you expect OS to handle that? No, you expect OS to stop immediately befor=
e it does any damage.</div><div><br></div><div>Same with C++ code -- if I a=
llocated memory (or wrote a program that needs 128kb of stack) and that mem=
ory can't be provided by underlying layer -- it is a situation that doe=
sn't "require diagnostic" (on the level of C++ program). So f=
rom OS perspective it looks like "meh... we tried, but it did work -- =
better kill it before it went nuts and formatted hard drive" (or suspe=
nd it and wait until page becomes available). From C++ code perspective -- =
time stops and universe ceases existing. It becomes implementation problem =
-- I, as developer, write a program that needs certain guarantees to base m=
y own guarantees on. The guy who deploys my program needs to configure syst=
em in such way that these guarantees are provided. If he doesn't do tha=
t -- he better have a plan B (failover/etc).</div><div><br></div><div><br><=
/div><div>So, yeah, my argument is basically that OOM on C++ level and OOM =
on OS level are independent things and conflating them leads to unnecessary=
confusion.</div><div>=C2=A0</div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/eb1357de-2bbc-40b5-9255-5d16c9aa2a4c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eb1357de-2bbc-40b5-9255-5d16c9aa2a4c=
%40isocpp.org</a>.<br />
------=_Part_2068_844815263.1503622974460--
------=_Part_2067_622515724.1503622974460--
.
Author: crusader.mike@gmail.com
Date: Thu, 24 Aug 2017 18:10:50 -0700 (PDT)
Raw View
------=_Part_2213_1072316797.1503623450488
Content-Type: multipart/alternative;
boundary="----=_Part_2214_789290867.1503623450488"
------=_Part_2214_789290867.1503623450488
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Thursday, August 24, 2017 at 1:04:45 PM UTC-5, Arthur O'Dwyer wrote:
>
> On Thursday, August 24, 2017 at 9:15:39 AM UTC-7, Viacheslav Usov wrote:
>>
>> On Thu, Aug 24, 2017 at 10:37 AM, Arthur O'Dwyer <arthur....@gmail.com>=
=20
>> wrote:
>>
>> > Can you explain how your mechanism would handle a program like this=20
>> one, where there's more than one exception in flight at once?
>> > https://wandbox.org/permlink/G23Eqak3aYVufquA
>> > If you find that you *can* handle this program without=20
>> heap-allocation, then you should trumpet that solution to the world,=20
>> regardless of whether the proposal itself is a good idea or not.
>>
>> That code compiles and runs just fine under MSVC, where every bad_alloc=
=20
>> is allocated on stack.
>>
>
> Is there a good resource for learning how MSVC does exceptions? (I don't=
=20
> even have a Windows machine, so I'm looking more for blog posts and thing=
s=20
> than for "dump this DLL and read it". :))
>
as far as I know (and I could be wrong) it works like this:
- exception gets allocated on stack
- unwinding mechanism goes up the stack and for each destructor call uses=
=20
portion of stack "below" exception
- for each nested throw this is repeated recursively -- i.e. we use=20
stack quite inefficiently and could end up with big 'holes'
- once we reach exception handler -- we execute it in same way, using=20
portion of stack "below" exception
- if we leave scope normally -- exception gets destroyed and large=20
chunk of stack suddenly becomes available
- if handle exits with another exception -- it gets constructed and=20
stack unwinding will start from this point (including destruction of prev=
=20
exception during unwinding)
- this obviously can lead to a very large 'hole' on the stack
I would appreciate if anyone corrects me if I am wrong.
=20
> If you don't propose a solution for (B), then you haven't really changed=
=20
>> the situation, have you?
>>
>> I agree with Andrey on this one: this is an issue more general than=20
>> exception handling. The motivation in the proposal is to make exception=
=20
>> handling as reliable as error handling is in C. C is not immune to stack=
=20
>> overflows.
>>
>
> That's fair.
> So this is more about chipping away at the differences between C++ EH and=
=20
> error codes, than about fixing up UB "holes" in C++.
>
Precisely.
=20
> The holes are allowed to remain, as long as the EH and no-EH sides have t=
o=20
> deal with the *same* holes. That's a fair point of view.
>
=E2=80=93Arthur
>
>>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/d50625cd-91e9-45af-b097-d44f2e9d7f9e%40isocpp.or=
g.
------=_Part_2214_789290867.1503623450488
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, August 24, 2017 at 1:04:45 PM UTC-5, =
Arthur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr">On Thursday, August 24, 2017 at 9:15:39 AM UTC-7, Viacheslav Us=
ov 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 Thu, Aug 24, 2017 at 10:37 AM, Arthur O'Dwyer=
<span dir=3D"ltr"><<a rel=3D"nofollow">arthur....@gmail.com</a>></sp=
an> wrote:<br><div><br></div><div>> Can you explain how your mechanism w=
ould handle a program like this one, where there's more than one except=
ion in flight at once?</div><div>>=C2=A0<a href=3D"https://wandbox.org/p=
ermlink/G23Eqak3aYVufquA" rel=3D"nofollow" target=3D"_blank" onmousedown=3D=
"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fwandbox.org=
%2Fpermlink%2FG23Eqak3aYVufquA\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGuws=
0-XNuqXBBLTk4HjkswwllWmw';return true;" onclick=3D"this.href=3D'htt=
ps://www.google.com/url?q\x3dhttps%3A%2F%2Fwandbox.org%2Fpermlink%2FG23Eqak=
3aYVufquA\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGuws0-XNuqXBBLTk4Hjkswwll=
Wmw';return true;">https://wandbox.org/<wbr>permlink/G23Eqak3aYVufquA</=
a></div><div>> If you find that you <i>can</i> handle this program witho=
ut heap-allocation, then you should trumpet that solution to the world, reg=
ardless of whether the proposal itself is a good idea or not.</div><div><br=
></div><div>That code compiles and runs just fine under MSVC, where every b=
ad_alloc is allocated on stack.<br></div></div></div></div></blockquote><di=
v><br></div><div>Is there a good resource for learning how MSVC does except=
ions? (I don't even have a Windows machine, so I'm looking more for=
blog posts and things than for "dump this DLL and read it". :))<=
/div></div></blockquote><div><br></div><div>as far as I know (and I could b=
e wrong) it works like this:</div><div>- exception gets allocated on stack<=
/div><div>- unwinding mechanism goes up the stack and for each destructor c=
all uses portion of stack "below" exception</div><div>=C2=A0 =C2=
=A0 =C2=A0- for each nested throw this is repeated recursively -- i.e. we u=
se stack quite inefficiently and could end up with big 'holes'</div=
><div>- once we reach exception handler -- we execute it in same way, using=
portion of stack "below" exception</div><div>=C2=A0 =C2=A0 =C2=
=A0- if we leave scope normally -- exception gets destroyed and large chunk=
of stack suddenly becomes available</div><div>=C2=A0 =C2=A0 =C2=A0- if han=
dle exits with another exception -- it gets constructed and stack unwinding=
will start from this point (including destruction of prev exception during=
unwinding)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - this obviously c=
an lead to a very large 'hole' on the stack</div><div><br></div><di=
v>I would appreciate if anyone corrects me if I am wrong.</div><div>=C2=A0<=
/div><div><br></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"><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 clas=
s=3D"gmail_quote"><div>> If you don't propose a solution for (B), th=
en you haven't really changed the situation, have you?<br></div><div><b=
r></div><div>I agree with Andrey on this one: this is an issue more general=
than exception handling. The motivation in the proposal is to make excepti=
on handling as reliable as error handling is in C. C is not immune to stack=
overflows.</div></div></div></blockquote><div><br></div><div>That's fa=
ir.</div><div>So this is more about chipping away at the differences betwee=
n C++ EH and error codes, than about fixing up UB "holes" in C++.=
</div></div></blockquote><div><br></div><div>Precisely.</div><div><br></div=
><div>=C2=A0</div><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"><div> The holes are allowed to remain, as long as the EH and no-EH sid=
es have to deal with the <i>same</i> holes. That's a fair point of view=
..</div></div></blockquote><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>=E2=80=93Arthur<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
</blockquote></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d50625cd-91e9-45af-b097-d44f2e9d7f9e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d50625cd-91e9-45af-b097-d44f2e9d7f9e=
%40isocpp.org</a>.<br />
------=_Part_2214_789290867.1503623450488--
------=_Part_2213_1072316797.1503623450488--
.
Author: crusader.mike@gmail.com
Date: Thu, 24 Aug 2017 18:48:29 -0700 (PDT)
Raw View
------=_Part_1987_1828629453.1503625709491
Content-Type: multipart/alternative;
boundary="----=_Part_1988_2067525511.1503625709491"
------=_Part_1988_2067525511.1503625709491
Content-Type: text/plain; charset="UTF-8"
On Thursday, August 24, 2017 at 3:57:51 AM UTC-5, Andrey Semashev wrote:
>
> On 08/24/17 11:37, Arthur O'Dwyer wrote:
> >
> >
> > On Thursday, August 24, 2017 at 12:04:09 AM UTC-7, crusad...@gmail.com
> > wrote:
> >
> > On Wednesday, August 23, 2017 at 5:31:45 PM UTC-5, Bryce Glover
> wrote:
> >
> >> On Aug 23, 2017, at 6:13 PM, std-pr...@isocpp.org wrote:
> >>
> >> Hi,
> >>
> >> I looked around this forum and realized that it is populated
> >> by the same
> >> people as discussion forum. Premises for this proposal were
> >> discussed there
> >> few days ago and some of you probably remember it. It makes my
> >> task a bit
> >> easier. :)
> >>
> >> Here is the draft:
> >> https://github.com/crusader-mike/misc/blob/master/D0770R0.md
> >> <https://github.com/crusader-mike/misc/blob/master/D0770R0.md>
> >
> >
> > Can you explain how your mechanism would handle a program like this one,
> > where there's more than one exception in flight at once?
> > https://wandbox.org/permlink/G23Eqak3aYVufquA
> > If you find that you /can/ handle this program without heap-allocation,
> > then you should trumpet that solution to the world, regardless of
> > whether the proposal itself is a good idea or not.
> > OTOH, if you find that you have no idea how to implement your proposal,
> > you probably shouldn't formally propose it. ;) Not that there's anything
> > wrong with starting a discussion on the topic.
> >
> > I'd rather see a paper that tackled either of the two really hard
> > problems that your paper tiptoes around:
> > (A) Exception handling mechanisms require(?) dynamic memory allocation,
> > and don't allow the programmer to specify a custom allocation mechanism
> > (B) C++ pretends that stack exhaustion is impossible, which is a big fat
> lie
> >
> > If you don't propose a solution for (B), then you haven't really changed
> > the situation, have you? The current situation is "Your program can
> > crash at any time, if it exhausts a resource that exists IRL but which
> > the Standard doesn't mention," and if you patch the standard according
> > to your proposal, the situation will still be "Your program can crash at
> > any time, if it exhausts a resource that exists IRL but which the
> > Standard doesn't mention."
> >
> > Do you actually see this failure mode in real code?
>
> We touched the stack overflow problem in the earlier discussion on
> std-discussion. IMO, stack overflow is a separate problem that may have
> a separate solution. This proposal focuses on the problem with throwing
> exceptions, and I think this is the right approach.
>
> Stack overflow happens when your program reaches a certain
> implementation-specific limit, and your program can be written in a way
> that this never happens (i.e. you can target specific implementations).
I suggest to look at this from another angle -- your code gives certain
guarantees but only if underlying layers provide it with guarantees it
itself requires. One of such guarantees is stack size (which can be (for
any implementation) calculated by analyzing code. If given environment
can't provide these guarantees -- it doesn't get guarantees provided by the
program.
> OOM, on the other hand, can happen at any time regardless of how you
> write your program.
Precisely. Language does not define any limits on dynamic storage -- it is
allowed to dry up at any moment (which reflects the fact that on modern OS
memory resources are shared between processes). And application should be
able to handle that gracefully -- we even have a dedicated exception for
that ;-)
> This means that SO can be considered an implementation limit and be
> largely ignored by the standard,
Isn't it completely ignored by standard as something that shouldn't happen?
(see my argument about pre-calculating stack size requirements).
> while OOM
> is a general possibility, and the language has to offer the user ways to
> handle it, preferably without terminating the application right away.
>
--
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/329ca95a-557b-4579-9653-f4866c8a1b30%40isocpp.org.
------=_Part_1988_2067525511.1503625709491
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, August 24, 2017 at 3:57:51 AM UTC-5, =
Andrey Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 08/24=
/17 11:37, Arthur O'Dwyer wrote:
<br>>=20
<br>>=20
<br>> On Thursday, August 24, 2017 at 12:04:09 AM UTC-7, <a>crusad...@gm=
ail.com</a>=20
<br>> wrote:
<br>>=20
<br>> =C2=A0 =C2=A0 On Wednesday, August 23, 2017 at 5:31:45 PM UTC-5, B=
ryce Glover wrote:
<br>>=20
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Aug 23, 2017, at 6:13 PM, <a>st=
d-pr...@isocpp.org</a> wrote:
<br>>>
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,
<br>>>
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 I looked around this forum and rea=
lized that it is populated
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 by the same
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 people as discussion forum. Premis=
es for this proposal were
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 discussed there
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 few days ago and some of you proba=
bly remember it. It makes my
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 task a bit
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 easier. :)
<br>>>
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Here is the draft:
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://github.com/crus=
ader-mike/misc/blob/master/D0770R0.md" target=3D"_blank" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%=
2Fgithub.com%2Fcrusader-mike%2Fmisc%2Fblob%2Fmaster%2FD0770R0.md\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNHFZk2ciNqn7OnemSbYmJiXT3625w';return true=
;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%=
2Fgithub.com%2Fcrusader-mike%2Fmisc%2Fblob%2Fmaster%2FD0770R0.md\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNHFZk2ciNqn7OnemSbYmJiXT3625w';return true=
;">https://github.com/crusader-<wbr>mike/misc/blob/master/D0770R0.<wbr>md</=
a>
<br>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"https://github.com/=
crusader-mike/misc/blob/master/D0770R0.md" target=3D"_blank" rel=3D"nofollo=
w" onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A=
%2F%2Fgithub.com%2Fcrusader-mike%2Fmisc%2Fblob%2Fmaster%2FD0770R0.md\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHFZk2ciNqn7OnemSbYmJiXT3625w';return =
true;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A=
%2F%2Fgithub.com%2Fcrusader-mike%2Fmisc%2Fblob%2Fmaster%2FD0770R0.md\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHFZk2ciNqn7OnemSbYmJiXT3625w';return =
true;">https://github.com/crusader-<wbr>mike/misc/blob/master/D0770R0.<wbr>=
md</a>>
<br>>=20
<br>>=20
<br>> Can you explain how your mechanism would handle a program like thi=
s one,=20
<br>> where there's more than one exception in flight at once?
<br>> <a href=3D"https://wandbox.org/permlink/G23Eqak3aYVufquA" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.go=
ogle.com/url?q\x3dhttps%3A%2F%2Fwandbox.org%2Fpermlink%2FG23Eqak3aYVufquA\x=
26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGuws0-XNuqXBBLTk4HjkswwllWmw';re=
turn true;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhtt=
ps%3A%2F%2Fwandbox.org%2Fpermlink%2FG23Eqak3aYVufquA\x26sa\x3dD\x26sntz\x3d=
1\x26usg\x3dAFQjCNGuws0-XNuqXBBLTk4HjkswwllWmw';return true;">https://w=
andbox.org/permlink/<wbr>G23Eqak3aYVufquA</a>
<br>> If you find that you /can/ handle this program without heap-alloca=
tion,=20
<br>> then you should trumpet that solution to the world, regardless of=
=20
<br>> whether the proposal itself is a good idea or not.
<br>> OTOH, if you find that you have no idea how to implement your prop=
osal,=20
<br>> you probably shouldn't formally propose it. ;) Not that there&=
#39;s anything=20
<br>> wrong with starting a discussion on the topic.
<br>>=20
<br>> I'd rather see a paper that tackled either of the two really h=
ard=20
<br>> problems that your paper tiptoes around:
<br>> (A) Exception handling mechanisms require(?) dynamic memory alloca=
tion,=20
<br>> and don't allow the programmer to specify a custom allocation =
mechanism
<br>> (B) C++ pretends that stack exhaustion is impossible, which is a b=
ig fat lie
<br>>=20
<br>> If you don't propose a solution for (B), then you haven't =
really changed=20
<br>> the situation, have you? The current situation is "Your progr=
am can=20
<br>> crash at any time, if it exhausts a resource that exists IRL but w=
hich=20
<br>> the Standard doesn't mention," and if you patch the stand=
ard according=20
<br>> to your proposal, the situation will still be "Your program c=
an crash at=20
<br>> any time, if it exhausts a resource that exists IRL but which the=
=20
<br>> Standard doesn't mention."
<br>>=20
<br>> Do you actually see this failure mode in real code?
<br>
<br>We touched the stack overflow problem in the earlier discussion on=20
<br>std-discussion. IMO, stack overflow is a separate problem that may have=
=20
<br>a separate solution. This proposal focuses on the problem with throwing=
=20
<br>exceptions, and I think this is the right approach.
<br>
<br>Stack overflow happens when your program reaches a certain=20
<br>implementation-specific limit, and your program can be written in a way=
=20
<br>that this never happens (i.e. you can target specific implementations).=
</blockquote><div><br></div><div>I suggest to look at this from another an=
gle -- your code gives certain guarantees but only if underlying layers pro=
vide it with guarantees it itself requires. One of such guarantees is stack=
size (which can be (for any implementation) calculated by analyzing code. =
If given environment can't provide these guarantees -- it doesn't g=
et guarantees provided by the program.</div><div><br></div><div><br></div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">OOM, on the ot=
her hand, can happen at any time regardless of how you=20
<br>write your program. </blockquote><div><br></div><div>Precisely. Languag=
e does not define any limits on dynamic storage -- it is allowed to dry up =
at any moment (which reflects the fact that on modern OS memory resources a=
re shared between processes). And application should be able to handle that=
gracefully -- we even have a dedicated exception for that ;-)</div><div><b=
r></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">This =
means that SO can be considered an implementation limit and be largely igno=
red by the standard,</blockquote><div><br></div><div>Isn't it completel=
y ignored by standard as something that shouldn't happen? (see my argum=
ent about pre-calculating stack size requirements).</div><div><br></div><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">while OOM=20
<br>is a general possibility, and the language has to offer the user ways t=
o=20
<br>handle it, preferably without terminating the application right away.
<br></blockquote><div><br></div><div>=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/329ca95a-557b-4579-9653-f4866c8a1b30%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/329ca95a-557b-4579-9653-f4866c8a1b30=
%40isocpp.org</a>.<br />
------=_Part_1988_2067525511.1503625709491--
------=_Part_1987_1828629453.1503625709491--
.
Author: crusader.mike@gmail.com
Date: Thu, 24 Aug 2017 19:02:26 -0700 (PDT)
Raw View
------=_Part_2105_1915166498.1503626546212
Content-Type: multipart/alternative;
boundary="----=_Part_2106_792816165.1503626546212"
------=_Part_2106_792816165.1503626546212
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Thursday, August 24, 2017 at 5:12:11 PM UTC-5, Ray Hamel wrote:
>
> On Thursday, August 24, 2017 at 5:03:01 PM UTC-4, Arthur O'Dwyer wrote:
>>
>> I don't think either of you have considered that there may be multiple=
=20
>> exceptions in-flight (or else I'm missing something fundamental that you=
're=20
>> both assuming implicitly).
>>
>> Suppose we preallocate 16 bytes so that we can throw runtime_error... an=
d=20
>> then we do throw it... and then, while unwinding the stack, we throw=20
>> *another* instance of runtime_error. Don't we now have to get *another*=
=20
>> 16 bytes of storage from somewhere?
>> Not to mention, even if we only throw zero-byte objects, there's still a=
=20
>> certain amount of overhead just for the bookkeeping... I *think*. Please=
=20
>> let me know if I'm missing something here.
>>
>> See my earlier reply in this thread, which included a program that has=
=20
>> about 100 exceptions in-flight at once.
>>
>> =E2=80=93Arthur
>>
>
> Different idea; what about a function `set_oom_buffer` with the prototype
>
> // allocates an implementation-defined global thread-safe buffer
> template<std::size_t N>
> void std::set_oom_buffer();
>
> and/or
>
> // registers a buffer (UB to access or deallocate after registering)
> void std::set_oom_buffer(void *buffer, std::size_t n) noexcept;
>
> The buffer may be used by the constructor of `std::exception` and=20
> subclasses, and to construct other implementation (or user?)-defined=20
> objects, in the event that normal allocation fails.
>
> This has the advantage of (mostly) maintaining the "you don't pay for wha=
t=20
> you don't use" principle, is relatively easy to implement and wouldn't=20
> alter the semantics of existing programs.
>
> -Ray
>
Problem is that in this case I need to correctly pre-calculate my=20
'exception memory' requirements for my program to be reliable. What is=20
proposed is to have a universal solution... which can be a "safety net" for=
=20
your proposal in case if buffer is too small or program is written in such=
=20
way that these requirements aren't bounded.
=20
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/25f81ffc-011d-4ba3-9eac-5e130638a03a%40isocpp.or=
g.
------=_Part_2106_792816165.1503626546212
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, August 24, 2017 at 5:12:11 PM UTC-5, =
Ray Hamel 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"lt=
r">On Thursday, August 24, 2017 at 5:03:01 PM UTC-4, Arthur O'Dwyer wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I don't thi=
nk either of you have considered that there may be multiple exceptions in-f=
light (or else I'm missing something fundamental that you're both a=
ssuming implicitly).<div><div class=3D"gmail_quote"><div><br></div><div>Sup=
pose we preallocate 16 bytes so that we can throw runtime_error... and then=
we do throw it... and then, while unwinding the stack, we throw <i>another=
</i> instance of runtime_error. Don't we now have to get <i>another</i>=
16 bytes of storage from somewhere?</div><div>Not to mention, even if we o=
nly throw zero-byte objects, there's still a certain amount of overhead=
just for the bookkeeping... I <i>think</i>. Please let me know if I'm =
missing something here.</div><div><br></div><div>See my earlier reply in th=
is thread, which included a program that has about 100 exceptions in-flight=
at once.</div><div><br></div><div>=E2=80=93Arthur</div></div></div></div><=
/blockquote><div><br></div><div>Different idea; what about a function `<spa=
n style=3D"font-family:courier new,monospace">set_oom_buffer</span>` with t=
he prototype</div><div><br></div><div><div style=3D"background-color:rgb(25=
0,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1p=
x"><code><div><span style=3D"color:#800">// allocates an implementation-def=
ined global thread-safe buffer</span><span style=3D"color:#000"><br></span>=
<span style=3D"color:#008">template</span><span style=3D"color:#660"><</=
span><span style=3D"color:#000">std</span><span style=3D"color:#660">::</sp=
an><span style=3D"color:#000">size_t N</span><span style=3D"color:#660">>=
;</span><span style=3D"color:#000"><br></span><span style=3D"color:#008">vo=
id</span><span style=3D"color:#000"> std</span><span style=3D"color:#660">:=
:</span><span style=3D"color:#000">set_oom_buffer</span><span style=3D"colo=
r:#660">();</span><span style=3D"color:#000"><br></span></div></code></div>=
<br>and/or<br></div><div><br></div><div><div style=3D"background-color:rgb(=
250,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:=
1px"><code><div><span style=3D"color:#800">// registers a buffer (UB to acc=
ess or deallocate after registering)</span><span style=3D"color:#000"><br><=
/span><span style=3D"color:#008">void</span><span style=3D"color:#000"> std=
</span><span style=3D"color:#660">::</span><span style=3D"color:#000">set_o=
om_buffer</span><span style=3D"color:#660">(</span><span style=3D"color:#00=
8">void</span><span style=3D"color:#000"> </span><span style=3D"color:#660"=
>*</span><span style=3D"color:#000">buffer</span><span style=3D"color:#660"=
>,</span><span style=3D"color:#000"> std</span><span style=3D"color:#660">:=
:</span><span style=3D"color:#000">size_t n</span><span style=3D"color:#660=
">)</span><span style=3D"color:#000"> noexcept</span><span style=3D"color:#=
660">;</span></div></code></div><br>The buffer may be used by the construct=
or of `<span style=3D"font-family:courier new,monospace">std::exception</sp=
an>` and subclasses, and to construct other implementation (or user?)-defin=
ed objects, in the event that normal allocation fails.</div><div><br></div>=
<div>This has the advantage of (mostly) maintaining the "you don't=
pay for what you don't use" principle, is relatively easy to impl=
ement and wouldn't alter the semantics of existing programs.<br></div><=
div><br></div><div>-Ray<br></div></div></blockquote><div><br></div><div>Pro=
blem is that in this case I need to correctly pre-calculate my 'excepti=
on memory' requirements for my program to be reliable. What is proposed=
is to have a universal solution... which can be a "safety net" f=
or your proposal in case if buffer is too small or program is written in su=
ch way that these requirements aren't bounded.</div><div><br></div><div=
>=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/25f81ffc-011d-4ba3-9eac-5e130638a03a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/25f81ffc-011d-4ba3-9eac-5e130638a03a=
%40isocpp.org</a>.<br />
------=_Part_2106_792816165.1503626546212--
------=_Part_2105_1915166498.1503626546212--
.