Topic: Proposal: Change the specified behavior when
Author: "T. C." <rs2740@gmail.com>
Date: Wed, 3 Feb 2016 00:59:17 -0800 (PST)
Raw View
------=_Part_52_578603283.1454489957183
Content-Type: multipart/alternative;
boundary="----=_Part_53_647923020.1454489957183"
------=_Part_53_647923020.1454489957183
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 2, 2016 at 7:15:03 PM UTC-5, chris beck wrote:
2) The C standard specifies this as undefined behavior -- C++ should do so
> also for compatibility.
>
This is undefined in C only if the value of the function call is used by
the caller (N1570 6.9.1/12). If it's not used, it's well-defined.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_53_647923020.1454489957183
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 2, 2016 at 7:15:03 PM UTC-5, chris be=
ck wrote:<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">2) The C standard specifies this as undefined behavior -- C++ sh=
ould do so also for compatibility. </div></blockquote><div><br></div><div>T=
his is undefined in C only if the value of the function call is used by the=
caller (N1570 6.9.1/12). If it's not used, it's well-defined.</div=
><div>=C2=A0</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_53_647923020.1454489957183--
------=_Part_52_578603283.1454489957183--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 03 Feb 2016 07:02:50 -0500
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">Since it is currently undefined behaviour, you could ask your c=
ompiler vendor to offer it as a compiler option, and then we could get some=
experience as to how valuable it is. </div> =
=
<div style=3D"width: 100%; font-size: initial; f=
ont-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73=
, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br sty=
le=3D"display:initial"></div> =
=
<=
div style=3D"font-size: initial; font-family: Calibri, 'Slate Pro', sans-se=
rif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-c=
olor: rgb(255, 255, 255);">Sent from my BlackBerry port=
able Babbage Device</div> =
=
<table width=
=3D"100%" style=3D"background-color:white;border-spacing:0px;"> <tbody><tr>=
<td colspan=3D"2" style=3D"font-size: initial; text-align: initial; backgro=
und-color: rgb(255, 255, 255);"> <div style=3D"bo=
rder-style: solid none none; border-top-color: rgb(181, 196, 223); border-t=
op-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', =
'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>chris beck</div><div><b>=
Sent: </b>Tuesday, February 2, 2016 7:15 PM</div><div><b>To: </b>ISO C++ St=
andard - Future Proposals</div><div><b>Reply To: </b>std-proposals@isocpp.o=
rg</div><div><b>Subject: </b>[std-proposals] Proposal: Change the specified=
behavior when control flow reaches the end of non-void functions</div></di=
v></td></tr></tbody></table><div style=3D"border-style: solid none none; bo=
rder-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-size: initi=
al; text-align: initial; background-color: rgb(255, 255, 255);"></div><br><=
div id=3D"_originalContent" style=3D""><div dir=3D"ltr">In the C++14 standa=
rd, the behavior when control flow reaches the end of a non-void function i=
s described as follows:<br><br>[stmt.return][6.6.3 The `return` statement]<=
br> ... Flowing off the end of a function is equivalent t=
o a return with no value; this results in undefined<br>behavior in a value-=
returning function.<br><br>I propose that the standard should be amended as=
follows:<br><br> ... Flowing off the end of a function i=
s equivalent to a return with no value; if this occurs in a function whose<=
br>return type is not `void`, `std::terminate` is called.<br><br>The reason=
for this is to make it easier to catch this undefined behavior by requirin=
g the program to fail fast.<br>In practice, it *seems* that gcc and clang g=
enerally do something like return an indeterminate value when they fall off=
<br>the end of a non-void function, and tracking down such bugs can be very=
difficult and time-consuming.<br>In C++ code written in a modern style, th=
is seems to be one of the easiest ways that an uninitialized value can occu=
r in<br>real code.<br><br>Most programmers deal with the situation by dilig=
ently paying attention to compiler warnings -- gcc will issue a warning<br>=
when it can see that control flow can reach the end of a non-void function.=
However, this is not an excellent solution.<br>It only works when gcc can =
actually prove that the end of the function is reachable, and this depends =
on the<br>optimization level used, and on the optimizations that succeed. I=
f the function is sufficiently complicated that gcc<br>can't be sure the en=
d is reachable, gcc won't issue a warning even if the end can be reached, t=
o avoid giving a<br>"false-positive" warning, which would limit the utility=
of the warning. Determining for sure if the end is reachable is<br>equival=
ent to the halting problem, so this approach is inherently limited.<br><br>=
By simply requiring the compiler to emit a call to `std::terminate` (instea=
d of potentially returning an undefined<br>value when this happens), we can=
catch the problem at run-time 100% of the time without having to solve the=
halting<br>problem. Moreover, in many real cases the compiler can prove th=
at the "end" is not reachable and that the function does<br>properly return=
, and then it may eliminate the `std::terminate` call.<br><br>The main argu=
ments that I anticipate against this proposal are<br>1) Potentially emittin=
g extra calls to `std::terminate` may bloat code, which without this change=
wouldn't need it, and<br>would work fine.<br><br> My belief is that =
the overhead would be low -- I would anticipate that "small" functions can =
usually be proved to<br>return correctly, and then the `std::terminate` cal=
l is optimized out. For large functions, an extra call at the end<br>repres=
ents only a marginal increase. However I don't have any data.<br><br>2) The=
C standard specifies this as undefined behavior -- C++ should do so also f=
or compatibility. Potentially, there<br>may be programs which technically h=
ave undefined behavior by way of returning an indeterminate value in this w=
ay, but in<br>fact the indeterminate value is then ignored in the caller an=
d so it doesn't cause problems and runs fine. Such programs<br>would now be=
terminated instead, breaking previously "working" code.<br><br> My h=
ope would be that more programs will be fixed by catching the indeterminate=
values before they cause havoc, than<br>would be broken in this manner -- =
likely, even the programs which break due to this change would benefit from=
being<br>refactored to avoid this problem. Anyways, it seems that the stan=
dard committee recently has been willing to make<br>breaking changes that i=
mprove maintainability in the long term, for instance, with the changes reg=
arding throwing<br>exceptions from destructors which became standard in C++=
11.<br>So perhaps the standards committee has an appetite for this also.<br=
><br>3.) The impact of this change may vary widely from compiler to compile=
r. Some compilers with very mature dead-code<br>elimination may be able to =
tolerate a change like this with few spurious `std::terminate` calls result=
ing in their code,<br>but others whose optimization tech is engineered diff=
erently may struggle to eliminate those calls -- requiring much<br>work fro=
m developers of those compilers to avoid this overhead.<br><br> It's =
difficult for one individual to survey the entire body of C++ compilers and=
the optimization techniques they use,<br>I am only actually familiar with =
a few compilers. My impression is that dead-code elimination is one of the =
most<br>important optimizations and that all modern compilers do this very =
aggressively, but if you know a popular compiler that<br>you think might st=
ruggle with eliminating function calls injected at the end of functions lik=
e I proposed in a large<br>program, I would be interested to investigate an=
d perhaps run some tests.<br><br><br><br>I would very much appreciate any t=
houghts or feedback regarding this idea. If there have been previous propos=
als of<br>this which have been rejected, I would appreciate a reference, I =
was not able to find such.<br><br>Best Regards,<br>Chris Beck</div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 03 Feb 2016 13:02:41 -0500
Raw View
On 2016-02-02 19:15, chris beck wrote:
> In the C++14 standard, the behavior when control flow reaches the end of a
> non-void function is described as follows:
>
> [stmt.return][6.6.3 The `return` statement]
> ... Flowing off the end of a function is equivalent to a return with no
> value; this results in undefined
> behavior in a value-returning function.
>
> I propose that the standard should be amended as follows:
>
> ... Flowing off the end of a function is equivalent to a return with no
> value; if this occurs in a function whose
> return type is not `void`, `std::terminate` is called.
>
> The reason for this is to make it easier to catch this undefined behavior
> by requiring the program to fail fast.
I previously proposed to make falling off a function be ill-formed:
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/zu7IxDnnrNA/YqjifANZtVsJ.
I strongly encourage you to read that thread, as much of the same ground
has been covered already.
> Most programmers deal with the situation by diligently paying attention to
> compiler warnings
....or you could just compile with -Werror=return-type. No diligence
required; your code won't build and you'll *have* to fix it.
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 03 Feb 2016 10:21:41 -0800
Raw View
On quarta-feira, 3 de fevereiro de 2016 13:02:41 PST Matthew Woehlke wrote:
> > The reason for this is to make it easier to catch this undefined behavior
> > by requiring the program to fail fast.
>
> I previously proposed to make falling off a function be ill-formed:
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/zu7IxDnnrNA/Yqjif
> ANZtVsJ. I strongly encourage you to read that thread, as much of the same
> ground has been covered already.
There's a big difference with the two proposals. To make it ill-formed, you
require the compiler to have absolutely no false positives or negatives. To
make it call std::terminate(), we're only defining previously undefined
behaviour and we don't need a 100% success rate.
Code expansion won't be big either and it may be even reduce code size.
> > Most programmers deal with the situation by diligently paying attention to
> > compiler warnings
>
> ...or you could just compile with -Werror=return-type. No diligence
> required; your code won't build and you'll *have* to fix it.
As Chris said in his OP, this does not catch everything due to false positives
and false negatives. The compiler is allowed to give up if it can't prove one
way or the other, so it often opts for assuming you know what you've done.
--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 03 Feb 2016 13:36:59 -0500
Raw View
On 2016-02-03 13:21, Thiago Macieira wrote:
> On quarta-feira, 3 de fevereiro de 2016 13:02:41 PST Matthew Woehlke wrote:
>>> The reason for this is to make it easier to catch this undefined behavior
>>> by requiring the program to fail fast.
>>
>> I previously proposed to make falling off a function be ill-formed:
>> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/zu7IxDnnrNA/Yqjif
>> ANZtVsJ. I strongly encourage you to read that thread, as much of the same
>> ground has been covered already.
>
> There's a big difference with the two proposals. To make it ill-formed, you
> require the compiler to have absolutely no false positives or negatives.
Calling std::terminate was also brought up in that thread. Also, those
issues can be addressed with standard 'not reachable' annotation, which
is valuable in its own right.
> To make it call std::terminate(), we're only defining previously
> undefined behaviour and we don't need a 100% success rate.
....except now you're changing behavior if I *meant* to flow off the end
(e.g. because I'm doing something tricksy) to cause my program to fail
at runtime, rather than being able to detect at compile time that the
compiler wants to mangle my code.
>> ...or you could just compile with -Werror=return-type. No diligence
>> required; your code won't build and you'll *have* to fix it.
>
> As Chris said in his OP, this does not catch everything due to false positives
> and false negatives.
Do you actually have an example of a false positive? I've *never* seen
one, and I'm curious what such an example looks like...
> The compiler is allowed to give up if it can't prove one way or the
> other, so it often opts for assuming you know what you've done.
If the compiler can't prove an issue, does it still insert a
std::terminate? Why would it not also warn in such cases? I would
really, really hope that the compiler has a warning for any time it
inserts a std::terminate for this reason... but in that case, the value
of requiring it to insert the std::terminate becomes dubious.
This approach (terminate at run-time rather than compile-time) feels
like a cop-out to me... and yes, "perfect is the enemy of good" and all
that, but here it feels too much like laziness.
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 3 Feb 2016 11:41:39 -0800 (PST)
Raw View
------=_Part_7712_275069644.1454528499408
Content-Type: multipart/alternative;
boundary="----=_Part_7713_2017654023.1454528499408"
------=_Part_7713_2017654023.1454528499408
Content-Type: text/plain; charset=UTF-8
On Wednesday, February 3, 2016 at 1:37:18 PM UTC-5, Matthew Woehlke wrote:
>
> On 2016-02-03 13:21, Thiago Macieira wrote:
> > On quarta-feira, 3 de fevereiro de 2016 13:02:41 PST Matthew Woehlke
> wrote:
> >>> The reason for this is to make it easier to catch this undefined
> behavior
> >>> by requiring the program to fail fast.
> >>
> >> I previously proposed to make falling off a function be ill-formed:
> >>
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/zu7IxDnnrNA/Yqjif
> >> ANZtVsJ. I strongly encourage you to read that thread, as much of the
> same
> >> ground has been covered already.
> >
> > There's a big difference with the two proposals. To make it ill-formed,
> you
> > require the compiler to have absolutely no false positives or negatives.
>
> Calling std::terminate was also brought up in that thread. Also, those
> issues can be addressed with standard 'not reachable' annotation, which
> is valuable in its own right.
>
> > To make it call std::terminate(), we're only defining previously
> > undefined behaviour and we don't need a 100% success rate.
>
> ...except now you're changing behavior if I *meant* to flow off the end
> (e.g. because I'm doing something tricksy) to cause my program to fail
> at runtime,
Do people actually do that? More to the point, do we need to support people
who are relying on undefined behavior?
> rather than being able to detect at compile time that the
> compiler wants to mangle my code.
>
> >> ...or you could just compile with -Werror=return-type. No diligence
> >> required; your code won't build and you'll *have* to fix it.
> >
> > As Chris said in his OP, this does not catch everything due to false
> positives
> > and false negatives.
>
> Do you actually have an example of a false positive? I've *never* seen
> one, and I'm curious what such an example looks like...
>
A false positive would be any time the compiler flags code that is actually
functional, where control flow through the execution of the program doesn't
reach the end of that function. And we know that it is *impossible* to do
this correctly, because it's identical to the halting problem.
So either you will get false negatives or false positives. Currently, C++
compilers err on the side of false negatives. And that is as it should be.
> The compiler is allowed to give up if it can't prove one way or the
> > other, so it often opts for assuming you know what you've done.
>
> If the compiler can't prove an issue, does it still insert a
> std::terminate?
Yes. It's functionally no different from sticking `std::terminate` at the
end of any function that returns a value which doesn't end in a `return`
statement. If the code never reaches it, no problem.
If the compiler can prove that it never gets there, then it can easily
insert nothing, based on the "as if" rule.
> Why would it not also warn in such cases?
Because "not proven" isn't the same thing as "*guilty*". Warning about
functioning code is simply adding noise to the list of warnings, making it
more likely the user will ignore genuinely useful ones.
I would
> really, really hope that the compiler has a warning for any time it
> inserts a std::terminate for this reason... but in that case, the value
> of requiring it to insert the std::terminate becomes dubious.
>
If I'm writing code where a set of conditions is always supposed to be
true, such that no runtime codepath can ever reach the end of the function,
and I *screw this up* in some way, `std::terminate` has value. It causes my
program to blow up when that runtime state is reached.
Your way prevents me from writing it *even if* I do it correctly. The fact
that I could have screwed it up doesn't mean I *did*.
This approach (terminate at run-time rather than compile-time) feels
> like a cop-out to me... and yes, "perfect is the enemy of good" and all
> that, but here it feels too much like laziness.
>
Walking off the end of a function is only a runtime problem. So failing at
compile time is the wrong way to handle it. Your way is not "perfect"; it's
stopping people from writing perfectly functional code.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_7713_2017654023.1454528499408
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, February 3, 2016 at 1:37:18 PM UTC-5, Matthe=
w Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-02-03 =
13:21, Thiago Macieira wrote:
<br>> On quarta-feira, 3 de fevereiro de 2016 13:02:41 PST Matthew Woehl=
ke wrote:
<br>>>> The reason for this is to make it easier to catch this und=
efined behavior
<br>>>> by requiring the program to fail fast.
<br>>>
<br>>> I previously proposed to make falling off a function be ill-fo=
rmed:
<br>>> <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-pr=
oposals/zu7IxDnnrNA/Yqjif" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msg/std-propo=
sals/zu7IxDnnrNA/Yqjif';return true;" onclick=3D"this.href=3D'https=
://groups.google.com/a/isocpp.org/d/msg/std-proposals/zu7IxDnnrNA/Yqjif'=
;;return true;">https://groups.google.com/a/<wbr>isocpp.org/d/msg/std-<wbr>=
proposals/zu7IxDnnrNA/Yqjif</a>
<br>>> ANZtVsJ. I strongly encourage you to read that thread, as much=
of the same
<br>>> ground has been covered already.
<br>>=20
<br>> There's a big difference with the two proposals. To make it il=
l-formed, you=20
<br>> require the compiler to have absolutely no false positives or nega=
tives.
<br>
<br>Calling std::terminate was also brought up in that thread. Also, those
<br>issues can be addressed with standard 'not reachable' annotatio=
n, which
<br>is valuable in its own right.
<br>
<br>> To make it call std::terminate(), we're only defining previous=
ly
<br>> undefined behaviour and we don't need a 100% success rate.
<br>
<br>...except now you're changing behavior if I *meant* to flow off the=
end
<br>(e.g. because I'm doing something tricksy) to cause my program to f=
ail
<br>at runtime,</blockquote><div><br>Do people actually do that? More to th=
e point, do we need to support people who are relying on undefined behavior=
?<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">rather than b=
eing able to detect at compile time that the
<br>compiler wants to mangle my code.
<br>
<br>>> ...or you could just compile with -Werror=3Dreturn-type. No di=
ligence
<br>>> required; your code won't build and you'll *have* to f=
ix it.
<br>>=20
<br>> As Chris said in his OP, this does not catch everything due to fal=
se positives=20
<br>> and false negatives.
<br>
<br>Do you actually have an example of a false positive? I've *never* s=
een
<br>one, and I'm curious what such an example looks like...<br></blockq=
uote><div><br>A false positive would be any time the compiler flags code th=
at is actually functional, where control flow through the execution of the =
program doesn't reach the end of that function. And we know that it is =
<i>impossible</i> to do this correctly, because it's identical to the h=
alting problem.<br><br>So either you will get false negatives or false posi=
tives. Currently, C++ compilers err on the side of false negatives. And tha=
t is as it should be.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
> The compiler is allowed to give up if it can't prove one way or th=
e
<br>> other, so it often opts for assuming you know what you've done=
..
<br>
<br>If the compiler can't prove an issue, does it still insert a
<br>std::terminate?</blockquote><div><br>Yes. It's functionally no diff=
erent from sticking `std::terminate` at the end of any function that return=
s a value which doesn't end in a `return` statement. If the code never =
reaches it, no problem.<br><br>If the compiler can prove that it never gets=
there, then it can easily insert nothing, based on the "as if" r=
ule.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Why would =
it not also warn in such cases?</blockquote><div><br>Because "not prov=
en" isn't the same thing as "<i>guilty</i>". Warning abo=
ut functioning code is simply adding noise to the list of warnings, making =
it more likely the user will ignore genuinely useful ones.<br><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">I would
<br>really, really hope that the compiler has a warning for any time it
<br>inserts a std::terminate for this reason... but in that case, the value
<br>of requiring it to insert the std::terminate becomes dubious.<br></bloc=
kquote><div><br>If I'm writing code where a set of conditions is always=
supposed to be true, such that no runtime codepath can ever reach the end =
of the function, and I <i>screw this up</i> in some way, `std::terminate` h=
as value. It causes my program to blow up when that runtime state is reache=
d.<br><br>Your way prevents me from writing it <i>even if</i> I do it corre=
ctly. The fact that I could have screwed it up doesn't mean I <i>did</i=
>.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
This approach (terminate at run-time rather than compile-time) feels
<br>like a cop-out to me... and yes, "perfect is the enemy of good&quo=
t; and all
<br>that, but here it feels too much like laziness.<br></blockquote><div><b=
r>Walking off the end of a function is only a runtime problem. So failing a=
t compile time is the wrong way to handle it. Your way is not "perfect=
"; it's stopping people from writing perfectly functional code. <b=
r></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_7713_2017654023.1454528499408--
------=_Part_7712_275069644.1454528499408--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 03 Feb 2016 15:22:28 -0500
Raw View
On 2016-02-03 14:41, Nicol Bolas wrote:
> If I'm writing code where a set of conditions is always supposed to be
> true, such that no runtime codepath can ever reach the end of the function,
> and I *screw this up* in some way, `std::terminate` has value. It causes my
> program to blow up when that runtime state is reached.
>
> Your way prevents me from writing it *even if* I do it correctly. The fact
> that I could have screwed it up doesn't mean I *did*.
Wrong; you can write such code by inserting an explicit std::terminate.
This ends up working *exactly* like John is proposing, but with the
added benefit that the code has been visibly annotated. (Better would be
to have a standardized "unreachable" annotation; all the same benefits,
*plus* compiler optimization opportunities, on top of said annotation
having additional use cases.)
This is what I mean by laziness... we all know (at least, I hope) that
it's better to catch errors at compile time rather than run time. The
only reason I see to have an implicit terminate rather than a compile
error is because *we are too lazy* to a) standardize unreachability and
b) make use of the same.
(Somewhat off-topic; it may be reasonable for unused - and not visible
outside the TU - functions to be exempt from these checks. Although
probably this is best handled per compiler by suppressing problems from
such "orphan" functions, besides a warning about them being orphans.)
> Your way is not "perfect"
No, and I didn't mean to imply that it was. It's just "better". Same end
result, but code is annotated and mistakes can be caught at compile
time, not run time. Moreover, if the compiler *can* prove that code
annotated unreachable can in fact be reached, it can make that a compile
error as well.
To reiterate a point I made previously, I consider it unacceptable that
this code is valid:
int foo() {} // note empty body
Any proposal that does not make this ill-formed has (IMO) not gone far
enough.
"Marginally adequate" can *also* be the enemy of "good".
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 03 Feb 2016 13:51:18 -0800
Raw View
On quarta-feira, 3 de fevereiro de 2016 13:36:59 PST Matthew Woehlke wrote:
> > There's a big difference with the two proposals. To make it ill-formed,
> > you
> > require the compiler to have absolutely no false positives or negatives.
>
> Calling std::terminate was also brought up in that thread. Also, those
> issues can be addressed with standard 'not reachable' annotation, which
> is valuable in its own right.
That requires a modification of the source code.
> > To make it call std::terminate(), we're only defining previously
> > undefined behaviour and we don't need a 100% success rate.
>
> ...except now you're changing behavior if I *meant* to flow off the end
> (e.g. because I'm doing something tricksy) to cause my program to fail
> at runtime, rather than being able to detect at compile time that the
> compiler wants to mangle my code.
No, you never meant to fall off the edge because that's undefined behaviour.
You may have been relying on it, which is a bug.
Or you were in a "proprietary agreement" with your compiler by using some
compiler switch. If you are, then your code is not portable anyway and there's
nothing wrong with the compiler keeping the switch for a little longer, even
though it violates the standard.
> >> ...or you could just compile with -Werror=return-type. No diligence
> >> required; your code won't build and you'll *have* to fix it.
> >
> > As Chris said in his OP, this does not catch everything due to false
> > positives and false negatives.
>
> Do you actually have an example of a false positive? I've *never* seen
> one, and I'm curious what such an example looks like...
False positives are very easy. Just call a function that doesn't exit by
returning and not mark with an unreachable annotation.
Qt 4 example (because in Qt5, qFatal is Q_NORETURN -- except with MSVC):
int f()
{
qFatal("Goodbye, cruel world!");
}
This will most likely produce a warning, when the function does not return and
therefore making it ill-formed would have made valid code fail to compile.
False negatives are more difficult, but here's an example:
enum E { V, V2 = 10 };
struct S { S(E); };
S f(E e)
{
switch (e) {
case V:
case V2:
return e;
}
}
The above triggers a warning with GCC and ICC, but not with Clang.
> > The compiler is allowed to give up if it can't prove one way or the
> > other, so it often opts for assuming you know what you've done.
>
> If the compiler can't prove an issue, does it still insert a
> std::terminate? Why would it not also warn in such cases? I would
> really, really hope that the compiler has a warning for any time it
> inserts a std::terminate for this reason... but in that case, the value
> of requiring it to insert the std::terminate becomes dubious.
I would say yes, it can insert the std::terminate, but it need not warn if it
can't be sure, because it can assume you meant to write it that way. See the
cases above. The extra call to std::terminate is not a big deal: if your code
is really bad and falls off the edge of the function, we now have a well-
defined termination; if it was fine before and never reached that point, you've
got a bit of dead code now.
More importantly, making it ill-formed makes the situation worse, because you
can ignore warnings, but you can't ignore a compilation error.
> This approach (terminate at run-time rather than compile-time) feels
> like a cop-out to me... and yes, "perfect is the enemy of good" and all
> that, but here it feels too much like laziness.
I'm not saying I agree with it. You're right, it is a cop-out: since we can't
make it ill-formed, let's go for the next best thing.
--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 03 Feb 2016 14:00:53 -0800
Raw View
On quarta-feira, 3 de fevereiro de 2016 13:51:18 PST Thiago Macieira wrote:
> enum E { V, V2 = 10 };
> struct S { S(E); };
> S f(E e)
> {
> switch (e) {
> case V:
> case V2:
> return e;
> }
> }
>
> The above triggers a warning with GCC and ICC, but not with Clang.
By the way, inserting a call to std::terminate() at the bottom pessimises the
above code. Clang assumes today that you meant what you'd written, which is to
say that you don't have undefined behaviours in your code like returning
without a value. That means the switching isn't necessary, as the only two
possible values are V and V2.
By inserting the std::terminate() call there (implicitly or explicitly), the
compiler will need to do the checks.
If you insert a __builtin_unreachable() at the end, GCC produces the same code
as Clang, whereas ICC keeps the comparisons but will fall off the edge if the
value of e isn't one of the expected ones.
--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Thu, 4 Feb 2016 01:30:51 +0300
Raw View
On Wed, Feb 3, 2016 at 3:15 AM, chris beck <render787@gmail.com> wrote:
> In the C++14 standard, the behavior when control flow reaches the end of a
> non-void function is described as follows:
>
> [stmt.return][6.6.3 The `return` statement]
> ... Flowing off the end of a function is equivalent to a return with no
> value; this results in undefined
> behavior in a value-returning function.
>
> I propose that the standard should be amended as follows:
>
> ... Flowing off the end of a function is equivalent to a return with no
> value; if this occurs in a function whose
> return type is not `void`, `std::terminate` is called.
This would incur unnecessary overhead for functions that do not return
normally when the compiler is unable to see that. For example:
void throw_an_exception(const char* descr);
int make_int(bool f)
{
if (f)
return 42;
throw_an_exception("f must be true");
}
throw_an_exception here does not return normally but the compiler
doesn't know that unless it has access to its body. This is a quite
common scenario when the code is written to reduce binary size.
> The main arguments that I anticipate against this proposal are
> 1) Potentially emitting extra calls to `std::terminate` may bloat code,
> which without this change wouldn't need it, and
> would work fine.
>
> My belief is that the overhead would be low -- I would anticipate that
> "small" functions can usually be proved to
> return correctly, and then the `std::terminate` call is optimized out. For
> large functions, an extra call at the end
> represents only a marginal increase. However I don't have any data.
Given that _every_ returning function has the potential to be
augmented this way, I believe the overhead will be significant. Also,
addition of a function call may affect inlineability of an otherwise
small and simple function.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 3 Feb 2016 15:01:49 -0800 (PST)
Raw View
------=_Part_1362_1312802222.1454540509763
Content-Type: multipart/alternative;
boundary="----=_Part_1363_2132159210.1454540509763"
------=_Part_1363_2132159210.1454540509763
Content-Type: text/plain; charset=UTF-8
On Wednesday, February 3, 2016 at 5:30:53 PM UTC-5, Andrey Semashev wrote:
>
> On Wed, Feb 3, 2016 at 3:15 AM, chris beck <rend...@gmail.com
> <javascript:>> wrote:
> > In the C++14 standard, the behavior when control flow reaches the end of
> a
> > non-void function is described as follows:
> >
> > [stmt.return][6.6.3 The `return` statement]
> > ... Flowing off the end of a function is equivalent to a return with
> no
> > value; this results in undefined
> > behavior in a value-returning function.
> >
> > I propose that the standard should be amended as follows:
> >
> > ... Flowing off the end of a function is equivalent to a return with
> no
> > value; if this occurs in a function whose
> > return type is not `void`, `std::terminate` is called.
>
> This would incur unnecessary overhead for functions that do not return
> normally when the compiler is unable to see that. For example:
>
> void throw_an_exception(const char* descr);
>
> int make_int(bool f)
> {
> if (f)
> return 42;
> throw_an_exception("f must be true");
> }
>
> throw_an_exception here does not return normally but the compiler
> doesn't know that unless it has access to its body. This is a quite
> common scenario when the code is written to reduce binary size.
>
Actually, we have an annotation for that: `[[noreturn]]`. Any function so
marked is expressly stated to not return control to the caller. So any code
written after such a call should never be executed, and the compiler will
know that.
>
> > The main arguments that I anticipate against this proposal are
> > 1) Potentially emitting extra calls to `std::terminate` may bloat code,
> > which without this change wouldn't need it, and
> > would work fine.
> >
> > My belief is that the overhead would be low -- I would anticipate that
> > "small" functions can usually be proved to
> > return correctly, and then the `std::terminate` call is optimized out.
> For
> > large functions, an extra call at the end
> > represents only a marginal increase. However I don't have any data.
>
> Given that _every_ returning function has the potential to be
> augmented this way, I believe the overhead will be significant.
That's not even remotely true. Even looking at functions that return
values, the plurality of such functions end in a return statement. And
therefore, even for the dumbest of compilers, they would need no such
terminus.
Similarly, a function that *statically* returns a value from all control
paths will likewise not need such a terminal statement. And compilers do
that kind of checking anyway, since they often warn about all control paths
not returning values.
So the only cases where this would even appear would be functions where not
all static control paths return a value.
> Also,
> addition of a function call may affect inlineability of an otherwise
> small and simple function.
>
Now *that's* actually a good point. Kinda.
I highly doubt it will make a function un-inlinable which otherwise could
be inlined. The concern is more that it will make the code generated by the
inliner more complex, having to always jump around this `std::terminate`
call, rather than just flowing naturally.
It could have a negative effect in tight loops.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1363_2132159210.1454540509763
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, February 3, 2016 at 5:30:53 PM 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 Wed, Feb 3,=
2016 at 3:15 AM, chris beck <<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"7qPV8jlhHAAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D'javascript:';return true;" onclick=3D"this.href=3D'jav=
ascript:';return true;">rend...@gmail.com</a>> wrote:
<br>> In the C++14 standard, the behavior when control flow reaches the =
end of a
<br>> non-void function is described as follows:
<br>>
<br>> [stmt.return][6.6.3 The `return` statement]
<br>> =C2=A0 =C2=A0 ... Flowing off the end of a function is equivalent =
to a return with no
<br>> value; this results in undefined
<br>> behavior in a value-returning function.
<br>>
<br>> I propose that the standard should be amended as follows:
<br>>
<br>> =C2=A0 =C2=A0 ... Flowing off the end of a function is equivalent =
to a return with no
<br>> value; if this occurs in a function whose
<br>> return type is not `void`, `std::terminate` is called.
<br>
<br>This would incur unnecessary overhead for functions that do not return
<br>normally when the compiler is unable to see that. For example:
<br>
<br>=C2=A0 void throw_an_exception(const char* descr);
<br>
<br>=C2=A0 int make_int(bool f)
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 if (f)
<br>=C2=A0 =C2=A0 =C2=A0 return 42;
<br>=C2=A0 =C2=A0 throw_an_exception("f must be true");
<br>=C2=A0 }
<br>
<br>throw_an_exception here does not return normally but the compiler
<br>doesn't know that unless it has access to its body. This is a quite
<br>common scenario when the code is written to reduce binary size.<br></bl=
ockquote><div><br>Actually, we have an annotation for that: `[[noreturn]]`.=
Any function so marked is expressly stated to not return control to the ca=
ller. So any code written after such a call should never be executed, and t=
he compiler will know that.<br>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;">
<br>> The main arguments that I anticipate against this proposal are
<br>> 1) Potentially emitting extra calls to `std::terminate` may bloat =
code,
<br>> which without this change wouldn't need it, and
<br>> would work fine.
<br>>
<br>> =C2=A0 My belief is that the overhead would be low -- I would anti=
cipate that
<br>> "small" functions can usually be proved to
<br>> return correctly, and then the `std::terminate` call is optimized =
out. For
<br>> large functions, an extra call at the end
<br>> represents only a marginal increase. However I don't have any =
data.
<br>
<br>Given that _every_ returning function has the potential to be
<br>augmented this way, I believe the overhead will be significant.</blockq=
uote><div><br>That's not even remotely true. Even looking at functions =
that return values, the plurality of such functions end in a return stateme=
nt. And therefore, even for the dumbest of compilers, they would need no su=
ch terminus.<br><br>Similarly, a function that <i>statically</i> returns a =
value from all control paths will likewise not need such a terminal stateme=
nt. And compilers do that kind of checking anyway, since they often warn ab=
out all control paths not returning values.<br><br>So the only cases where =
this would even appear would be functions where not all static control path=
s return a value.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;">Also,
<br>addition of a function call may affect inlineability of an otherwise
<br>small and simple function.<br></blockquote><div><br>Now <i>that's</=
i> actually a good point. Kinda.<br><br>I highly doubt it will make a funct=
ion un-inlinable which otherwise could be inlined. The concern is more that=
it will make the code generated by the inliner more complex, having to alw=
ays jump around this `std::terminate` call, rather than just flowing natura=
lly.<br><br>It could have a negative effect in tight loops.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_1363_2132159210.1454540509763--
------=_Part_1362_1312802222.1454540509763--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Thu, 4 Feb 2016 02:19:25 +0300
Raw View
On Thu, Feb 4, 2016 at 2:01 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, February 3, 2016 at 5:30:53 PM UTC-5, Andrey Semashev wrote:
>>
>> On Wed, Feb 3, 2016 at 3:15 AM, chris beck <rend...@gmail.com> wrote:
>> > In the C++14 standard, the behavior when control flow reaches the end of
>> > a
>> > non-void function is described as follows:
>> >
>> > [stmt.return][6.6.3 The `return` statement]
>> > ... Flowing off the end of a function is equivalent to a return with
>> > no
>> > value; this results in undefined
>> > behavior in a value-returning function.
>> >
>> > I propose that the standard should be amended as follows:
>> >
>> > ... Flowing off the end of a function is equivalent to a return with
>> > no
>> > value; if this occurs in a function whose
>> > return type is not `void`, `std::terminate` is called.
>>
>> This would incur unnecessary overhead for functions that do not return
>> normally when the compiler is unable to see that. For example:
>>
>> void throw_an_exception(const char* descr);
>>
>> int make_int(bool f)
>> {
>> if (f)
>> return 42;
>> throw_an_exception("f must be true");
>> }
>>
>> throw_an_exception here does not return normally but the compiler
>> doesn't know that unless it has access to its body. This is a quite
>> common scenario when the code is written to reduce binary size.
>
> Actually, we have an annotation for that: `[[noreturn]]`. Any function so
> marked is expressly stated to not return control to the caller. So any code
> written after such a call should never be executed, and the compiler will
> know that.
That means that the previously fine code is now not optimal unless
modified (i.e. marked with the attribute or somehow rearranged). I
wouldn't like that.
>> Given that _every_ returning function has the potential to be
>> augmented this way, I believe the overhead will be significant.
>
> That's not even remotely true. Even looking at functions that return values,
> the plurality of such functions end in a return statement. And therefore,
> even for the dumbest of compilers, they would need no such terminus.
>
> Similarly, a function that statically returns a value from all control paths
> will likewise not need such a terminal statement. And compilers do that kind
> of checking anyway, since they often warn about all control paths not
> returning values.
>
> So the only cases where this would even appear would be functions where not
> all static control paths return a value.
Yes, and I see such functions more often than I'd like.
>> Also,
>> addition of a function call may affect inlineability of an otherwise
>> small and simple function.
>
> Now that's actually a good point. Kinda.
>
> I highly doubt it will make a function un-inlinable which otherwise could be
> inlined. The concern is more that it will make the code generated by the
> inliner more complex, having to always jump around this `std::terminate`
> call, rather than just flowing naturally.
Even if the augmented function gets inlined, the negative effect is
still there. It is merely transferred to all inline targets - the
caller functions themselves become heavier and less likely to be
inlined. The effect is multiplied with every augmented function that
is inlined.
> It could have a negative effect in tight loops.
Right.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Thu, 4 Feb 2016 02:36:22 +0300
Raw View
On Thu, Feb 4, 2016 at 2:19 AM, Andrey Semashev
<andrey.semashev@gmail.com> wrote:
> On Thu, Feb 4, 2016 at 2:01 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>> On Wednesday, February 3, 2016 at 5:30:53 PM UTC-5, Andrey Semashev wrote:
>>>
>>> This would incur unnecessary overhead for functions that do not return
>>> normally when the compiler is unable to see that. For example:
>>>
>>> void throw_an_exception(const char* descr);
>>>
>>> int make_int(bool f)
>>> {
>>> if (f)
>>> return 42;
>>> throw_an_exception("f must be true");
>>> }
>>>
>>> throw_an_exception here does not return normally but the compiler
>>> doesn't know that unless it has access to its body. This is a quite
>>> common scenario when the code is written to reduce binary size.
>>
>> Actually, we have an annotation for that: `[[noreturn]]`. Any function so
>> marked is expressly stated to not return control to the caller. So any code
>> written after such a call should never be executed, and the compiler will
>> know that.
>
> That means that the previously fine code is now not optimal unless
> modified (i.e. marked with the attribute or somehow rearranged). I
> wouldn't like that.
I'll expand on this. What I don't like about this idea is that the
change forces the compiler to insert its voodoo magic without me
asking for it. It's as if there was 'throw()' specification for every
function by default. I want the language, in its simplest and lower
layer form, to be as close as reasonable to C. If anything, this
behavior should be optional and enabled with an attribute (i.e.
requested by the developer). I know that the argument will be that it
will be easy to forget the attribute and because of that the
usefullness of this addition will be close to zero. That is probably
true, and this is why I don't think there is point in changing the
language.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Thu, 4 Feb 2016 02:57:30 -0800 (PST)
Raw View
------=_Part_1253_803925918.1454583450835
Content-Type: multipart/alternative;
boundary="----=_Part_1254_936790487.1454583450835"
------=_Part_1254_936790487.1454583450835
Content-Type: text/plain; charset=UTF-8
On Wednesday, 3 February 2016 12:02:55 UTC, Tony V E wrote:
>
> Since it is currently undefined behaviour, you could ask your compiler
> vendor to offer it as a compiler option, and then we could get some
> experience as to how valuable it is.
>
Both clang and gcc have this in ubsan (-fsanitize=undefined), specifically
as -fsanitize=return (clang's implementation seems better than gcc's).
They don't turn it on by default as it pessimizes valid code. Thiago has
already given examples; here's another that comes up fairly often:
enum e { a, b, c };
enum E { A, B, C };
E f(e v) {
switch (v) {
case a: return A;
case b: return B;
case c: return C;
}
}
Currently clang compiles this to mov edi, eax; ret.
With -fsanitize=return the instruction count quadruples, including a branch.
The proposal would be worse than the current ubsan offering, not just in
making it compulsory but also because calling std::terminate discards
information on the nature and location of the error; ubsan outputs the
source location and describes the error: "main.c:3:3: missing return
statement", or some such.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1254_936790487.1454583450835
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>On Wednesday, 3 February 2016 12:02:55 UTC, Tony V E =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left=
-style: solid; padding-left: 1ex;"><div lang=3D"en-US" style=3D"line-height=
: initial;"><div style=3D"width: 812.40625px; font-size: initial; font-fami=
ly: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73=
, 125); text-align: initial;">Since it is currently undefined behaviour, yo=
u could ask your compiler vendor to offer it as a compiler option, and then=
we could get some experience as to how valuable it is.</div></div></blockq=
uote><div><br></div><div>Both clang and gcc have this in ubsan (-fsanitize=
=3Dundefined), specifically as -fsanitize=3Dreturn (clang's implementat=
ion seems better than gcc's).</div><div><br></div><div>They don't t=
urn it on by default as it pessimizes valid code. Thiago has already given =
examples; here's another that comes up fairly often:</div></div><div><b=
r></div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187,=
187); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code =
class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #=
008;" class=3D"styled-by-prettify">enum</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> e </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> a</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> b=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> c </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">enum</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> E </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> A</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> B=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> C </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>E f</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">e v</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">sw=
itch</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">v</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">case</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> a</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> A</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">case</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> b</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> B</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">case</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> c</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> C</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span></div></code></div><div><br>Currently clang compiles t=
his to mov edi, eax; ret. With=C2=A0-fsanitize=3Dreturn=C2=A0the instructio=
n count quadruples, including a branch.</div><div><br></div><div>The propos=
al would be worse than the current ubsan offering, not just in making it co=
mpulsory but also because calling std::terminate discards information on th=
e nature and location of the error; ubsan outputs the source location and d=
escribes the error: "main.c:3:3: missing return statement", or so=
me such.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_1254_936790487.1454583450835--
------=_Part_1253_803925918.1454583450835--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 04 Feb 2016 14:33:41 -0800
Raw View
On quinta-feira, 4 de fevereiro de 2016 02:57:30 PST Edward Catmur wrote:
> The proposal would be worse than the current ubsan offering, not just in
> making it compulsory but also because calling std::terminate discards
> information on the nature and location of the error; ubsan outputs the
> source location and describes the error: "main.c:3:3: missing return
> statement", or some such.
The information loss is not a requirement. The runtime could print the reason
for termination before termination.
--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 4 Feb 2016 22:58:24 +0000
Raw View
--047d7b3a9712ff5e03052af9aba9
Content-Type: text/plain; charset=UTF-8
On Thu, Feb 4, 2016 at 10:33 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> On quinta-feira, 4 de fevereiro de 2016 02:57:30 PST Edward Catmur wrote:
> > The proposal would be worse than the current ubsan offering, not just in
> > making it compulsory but also because calling std::terminate discards
> > information on the nature and location of the error; ubsan outputs the
> > source location and describes the error: "main.c:3:3: missing return
> > statement", or some such.
>
> The information loss is not a requirement. The runtime could print the
> reason
> for termination before termination.
>
How? std::terminate_handler is specified as void(*)() so there's nowhere to
pass in the reason. Existing terminate_handlers look at
std::current_exception, so I suppose you could smuggle it in there, but
then you might as well throw that exception directly.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b3a9712ff5e03052af9aba9
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, Feb 4, 2016 at 10:33 PM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">On quinta-feira, 4 de fe=
vereiro de 2016 02:57:30 PST Edward Catmur wrote:<br>
> The proposal would be worse than the current ubsan offering, not just =
in<br>
> making it compulsory but also because calling std::terminate discards<=
br>
> information on the nature and location of the error; ubsan outputs the=
<br>
> source location and describes the error: "main.c:3:3: missing ret=
urn<br>
> statement", or some such.<br>
<br>
The information loss is not a requirement. The runtime could print the reas=
on<br>
for termination before termination.<br></blockquote><div><br></div><div>How=
? std::terminate_handler is specified as void(*)() so there's nowhere t=
o pass in the reason. Existing terminate_handlers look at std::current_exce=
ption, so I suppose you could smuggle it in there, but then you might as we=
ll throw that exception directly.</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--047d7b3a9712ff5e03052af9aba9--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 04 Feb 2016 15:18:47 -0800
Raw View
On quinta-feira, 4 de fevereiro de 2016 22:58:24 PST 'Edward Catmur' via ISO C
++ Standard - Future Proposals wrote:
> > The information loss is not a requirement. The runtime could print the
> > reason
> > for termination before termination.
>
> How? std::terminate_handler is specified as void(*)() so there's nowhere to
> pass in the reason. Existing terminate_handlers look at
> std::current_exception, so I suppose you could smuggle it in there, but
> then you might as well throw that exception directly.
Because the compiler does not need to directly call std::terminate. It can
call a function of its own that prints the information, then calls
std::terminate.
--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 4 Feb 2016 23:25:50 +0000
Raw View
--001a1135e2381a9a76052afa0ef2
Content-Type: text/plain; charset=UTF-8
On Thu, Feb 4, 2016 at 11:18 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> On quinta-feira, 4 de fevereiro de 2016 22:58:24 PST 'Edward Catmur' via
> ISO C
> ++ Standard - Future Proposals wrote:
> > > The information loss is not a requirement. The runtime could print the
> > > reason
> > > for termination before termination.
> >
> > How? std::terminate_handler is specified as void(*)() so there's nowhere
> to
> > pass in the reason. Existing terminate_handlers look at
> > std::current_exception, so I suppose you could smuggle it in there, but
> > then you might as well throw that exception directly.
>
> Because the compiler does not need to directly call std::terminate. It can
> call a function of its own that prints the information, then calls
> std::terminate.
Thereby requiring that all C++ programs have a console attached, and
denying them control over what is output to that console?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1135e2381a9a76052afa0ef2
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, Feb 4, 2016 at 11:18 PM, Thiago Macieira <span dir=3D"ltr"><<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">On quinta-feira, 4 de fe=
vereiro de 2016 22:58:24 PST 'Edward Catmur' via ISO C<br>
<span class=3D"">++ Standard - Future Proposals wrote:<br>
> > The information loss is not a requirement. The runtime could prin=
t the<br>
> > reason<br>
> > for termination before termination.<br>
><br>
> How? std::terminate_handler is specified as void(*)() so there's n=
owhere to<br>
> pass in the reason. Existing terminate_handlers look at<br>
> std::current_exception, so I suppose you could smuggle it in there, bu=
t<br>
> then you might as well throw that exception directly.<br>
<br>
</span>Because the compiler does not need to directly call std::terminate. =
It can<br>
call a function of its own that prints the information, then calls<br>
std::terminate.</blockquote><div><br></div><div>Thereby requiring that all =
C++ programs have a console attached, and denying them control over what is=
output to that console?</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a1135e2381a9a76052afa0ef2--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 5 Feb 2016 01:32:52 +0200
Raw View
On 5 February 2016 at 01:25, 'Edward Catmur' via ISO C++ Standard -
Future Proposals >> > > The information loss is not a requirement. The
runtime could print the
>> > > reason
>> > > for termination before termination.
>> >
>> > How? std::terminate_handler is specified as void(*)() so there's nowhere
>> > to
>> > pass in the reason. Existing terminate_handlers look at
>> > std::current_exception, so I suppose you could smuggle it in there, but
>> > then you might as well throw that exception directly.
>>
>> Because the compiler does not need to directly call std::terminate. It can
>> call a function of its own that prints the information, then calls
>> std::terminate.
> Thereby requiring that all C++ programs have a console attached, and denying
> them control over what is output to that console?
Doing that does not in any way require a console to be attached, and various
tools have been outputting such diagnostics into the standard error output many
years. I don't quite grasp what you think is the problem here.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 4 Feb 2016 23:47:35 +0000
Raw View
--001a113ea6c2e47c55052afa5b6a
Content-Type: text/plain; charset=UTF-8
On Thu, Feb 4, 2016 at 11:32 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 5 February 2016 at 01:25, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals >> > > The information loss is not a requirement. The
> runtime could print the
> >> > > reason
> >> > > for termination before termination.
> >> >
> >> > How? std::terminate_handler is specified as void(*)() so there's
> nowhere
> >> > to
> >> > pass in the reason. Existing terminate_handlers look at
> >> > std::current_exception, so I suppose you could smuggle it in there,
> but
> >> > then you might as well throw that exception directly.
> >>
> >> Because the compiler does not need to directly call std::terminate. It
> can
> >> call a function of its own that prints the information, then calls
> >> std::terminate.
> > Thereby requiring that all C++ programs have a console attached, and
> denying
> > them control over what is output to that console?
>
>
> Doing that does not in any way require a console to be attached, and
> various
> tools have been outputting such diagnostics into the standard error output
> many
> years. I don't quite grasp what you think is the problem here.
Those tools are optional; they are not mandated by the standard. The
problem is that you're proposing to terminate a program without giving the
program itself any indication of why the termination is occurring; the only
indication is a diagnostic emitted to a standard error output that may be
discarded if it even exists at all.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113ea6c2e47c55052afa5b6a
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, Feb 4, 2016 at 11:32 PM, Ville Voutilainen <span dir=3D"ltr"><<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 5 Fe=
bruary 2016 at 01:25, 'Edward Catmur' via ISO C++ Standard -<br>
Future Proposals >> > > The information loss is not a requireme=
nt. The<br>
<span class=3D"">runtime could print the<br>
>> > > reason<br>
>> > > for termination before termination.<br>
>> ><br>
>> > How? std::terminate_handler is specified as void(*)() so ther=
e's nowhere<br>
>> > to<br>
>> > pass in the reason. Existing terminate_handlers look at<br>
>> > std::current_exception, so I suppose you could smuggle it in =
there, but<br>
>> > then you might as well throw that exception directly.<br>
>><br>
>> Because the compiler does not need to directly call std::terminate=
.. It can<br>
>> call a function of its own that prints the information, then calls=
<br>
>> std::terminate.<br>
> Thereby requiring that all C++ programs have a console attached, and d=
enying<br>
> them control over what is output to that console?<br>
<br>
<br>
</span>Doing that does not in any way require a console to be attached, and=
various<br>
tools have been outputting such diagnostics into the standard error output =
many<br>
years. I don't quite grasp what you think is the problem here.</blockqu=
ote><div><br></div><div>Those tools are optional; they are not mandated by =
the standard. The problem is that you're proposing to terminate a progr=
am without giving the program itself any indication of why the termination =
is occurring; the only indication is a diagnostic emitted to a standard err=
or output that may be discarded if it even exists at all.</div></div></div>=
</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a113ea6c2e47c55052afa5b6a--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 5 Feb 2016 03:20:13 +0200
Raw View
On 5 February 2016 at 01:47, 'Edward Catmur' via ISO C++ Standard -
Future Proposals >> >> Because the compiler does not need to directly
call std::terminate. It
>> >> can
>> >> call a function of its own that prints the information, then calls
>> >> std::terminate.
>> > Thereby requiring that all C++ programs have a console attached, and
>> > denying
>> > them control over what is output to that console?
>>
>>
>> Doing that does not in any way require a console to be attached, and
>> various
>> tools have been outputting such diagnostics into the standard error output
>> many
>> years. I don't quite grasp what you think is the problem here.
> Those tools are optional; they are not mandated by the standard. The problem
I wouldn't expect the technique Thiago describes to be mandated by the standard.
> is that you're proposing to terminate a program without giving the program
I'm not proposing anything, my strong preference is to leave the status quo
alone.
> itself any indication of why the termination is occurring; the only
> indication is a diagnostic emitted to a standard error output that may be
> discarded if it even exists at all.
How is that different from any other case of terminating a program?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 04 Feb 2016 21:59:58 -0800
Raw View
On quinta-feira, 4 de fevereiro de 2016 23:47:35 PST 'Edward Catmur' via ISO C
++ Standard - Future Proposals wrote:
> Those tools are optional; they are not mandated by the standard. The
> problem is that you're proposing to terminate a program without giving the
> program itself any indication of why the termination is occurring; the only
> indication is a diagnostic emitted to a standard error output that may be
> discarded if it even exists at all.
The proposal in question is that the program be terminated. Nothing in it says
that it needs to be a silent termination. Nor does it require a diagnostic.
What the compiler may want to implement is its own business, so long as it
terminates the program by eventually calling std::terminate.
--
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 5 Feb 2016 09:07:36 +0000
Raw View
--001a113ea6c2b2954b052b022e91
Content-Type: text/plain; charset=UTF-8
On Fri, Feb 5, 2016 at 1:20 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> > itself any indication of why the termination is occurring; the only
> > indication is a diagnostic emitted to a standard error output that may be
> > discarded if it even exists at all.
> How is that different from any other case of terminating a program?
>
When std::terminate is invoked in a manner prescribed by the standard,
there is a current exception available to the terminate handler.
On Fri, Feb 5, 2016 at 5:59 AM, Thiago Macieira <thiago@macieira.org> wrote:
> On quinta-feira, 4 de fevereiro de 2016 23:47:35 PST 'Edward Catmur' via
> ISO C
> ++ Standard - Future Proposals wrote:
> > Those tools are optional; they are not mandated by the standard. The
> > problem is that you're proposing to terminate a program without giving
> the
> > program itself any indication of why the termination is occurring; the
> only
> > indication is a diagnostic emitted to a standard error output that may be
> > discarded if it even exists at all.
>
> The proposal in question is that the program be terminated. Nothing in it
> says
> that it needs to be a silent termination. Nor does it require a diagnostic.
>
And then you're throwing away information that existing implementations
have shown is readily available.
> What the compiler may want to implement is its own business, so long as it
> terminates the program by eventually calling std::terminate.
>
I strongly believe that is the wrong mechanism. std::terminate is a
facility "... for coping with errors related to the exception handling
mechanism ..." [except.special]; falling off the end of a value-returning
function has absolutely nothing to do with exceptions. If ubsan is to be
standardized (and I'm broadly in favor of that, given suitable opt-outs) it
should happen through an appropriate mechanism, not be shoehorned into the
exception handling mechanism.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113ea6c2b2954b052b022e91
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 F=
ri, Feb 5, 2016 at 1:20 AM, Ville Voutilainen=C2=A0<span dir=3D"ltr"><<a=
href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutil=
ainen@gmail.com</a>></span>=C2=A0wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> itself =
any indication of why the termination is occurring; the only<br>> indica=
tion is a diagnostic emitted to a standard error output that may be<br>>=
discarded if it even exists at all.<br>How is that different from any othe=
r case of terminating a program?<br></blockquote></div><div class=3D"gmail_=
quote"><br></div><div class=3D"gmail_quote">When std::terminate is invoked =
in a manner prescribed by the standard, there is a current exception availa=
ble to the terminate handler.</div><div class=3D"gmail_quote"><br></div><di=
v class=3D"gmail_quote">On Fri, Feb 5, 2016 at 5:59 AM, Thiago Macieira <sp=
an dir=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank"=
>thiago@macieira.org</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On quinta-fe=
ira, 4 de fevereiro de 2016 23:47:35 PST 'Edward Catmur' via ISO C<=
br>
<span class=3D"">++ Standard - Future Proposals wrote:<br>
> Those tools are optional; they are not mandated by the standard. The<b=
r>
</span>> problem is that you're proposing to terminate a program wit=
hout giving the<br>
> program itself any indication of why the termination is occurring; the=
only<br>
<span class=3D"">> indication is a diagnostic emitted to a standard erro=
r output that may be<br>
> discarded if it even exists at all.<br>
<br>
</span>The proposal in question is that the program be terminated. Nothing =
in it says<br>
that it needs to be a silent termination. Nor does it require a diagnostic.=
<br></blockquote><div><br></div><div>And then you're throwing away info=
rmation that existing implementations have shown is readily available.</div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex">
What the compiler may want to implement is its own business, so long as it<=
br>
terminates the program by eventually calling std::terminate.<br></blockquot=
e><div><br></div><div>I strongly believe that is the wrong mechanism. std::=
terminate is a facility "...=C2=A0for coping with errors related to th=
e exception handling mechanism ..." [except.special]; falling off the =
end of a value-returning function has absolutely nothing to do with excepti=
ons. If ubsan is to be standardized (and I'm broadly in favor of that, =
given suitable opt-outs) it should happen through an appropriate mechanism,=
not be shoehorned into the exception handling mechanism.</div></div></div>=
</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a113ea6c2b2954b052b022e91--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Fri, 5 Feb 2016 12:24:14 +0300
Raw View
On 2016-02-05 12:07, 'Edward Catmur' via ISO C++ Standard - Future
Proposals wrote:
> On Fri, Feb 5, 2016 at 5:59 AM, Thiago Macieira <thiago@macieira.org
> <mailto:thiago@macieira.org>> wrote:
>
> On quinta-feira, 4 de fevereiro de 2016 23:47:35 PST 'Edward Catmur'
> via ISO C
> ++ Standard - Future Proposals wrote:
> > Those tools are optional; they are not mandated by the standard. The
> > problem is that you're proposing to terminate a program without
> giving the
> > program itself any indication of why the termination is
> occurring; the only
> > indication is a diagnostic emitted to a standard error output that may be
> > discarded if it even exists at all.
>
> The proposal in question is that the program be terminated. Nothing
> in it says
> that it needs to be a silent termination. Nor does it require a
> diagnostic.
>
> And then you're throwing away information that existing implementations
> have shown is readily available.
The way it terminates the program is not important. You may encourage
implementations to provide diagnostic output, the same way it is done
for assert. It may leave that to implementers altogether. At least gcc
is able to print diagnostic output when std::terminate is called because
of uncaught exception. I see no problem with this part.
Any means to terminate the program leaves you with less than desired
unless you can obtain the backtrace that led to the termination, and if
you can do that the console output becomes mostly unneeded.
> What the compiler may want to implement is its own business, so long
> as it
> terminates the program by eventually calling std::terminate.
>
>
> I strongly believe that is the wrong mechanism. std::terminate is a
> facility "... for coping with errors related to the exception handling
> mechanism ..." [except.special]; falling off the end of a
> value-returning function has absolutely nothing to do with exceptions.
> If ubsan is to be standardized (and I'm broadly in favor of that, given
> suitable opt-outs) it should happen through an appropriate mechanism,
> not be shoehorned into the exception handling mechanism.
No tool should ever be standardized.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 5 Feb 2016 11:53:18 +0200
Raw View
On 5 February 2016 at 11:07, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> On Fri, Feb 5, 2016 at 1:20 AM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>>
>> > itself any indication of why the termination is occurring; the only
>> > indication is a diagnostic emitted to a standard error output that may
>> > be
>> > discarded if it even exists at all.
>> How is that different from any other case of terminating a program?
>
>
> When std::terminate is invoked in a manner prescribed by the standard, there
> is a current exception available to the terminate handler.
None of what we have described changes any of that.
>> The proposal in question is that the program be terminated. Nothing in it
>> says
>> that it needs to be a silent termination. Nor does it require a
>> diagnostic.
> And then you're throwing away information that existing implementations have
> shown is readily available.
I fail to see what information we would supposedly throw away.
>> What the compiler may want to implement is its own business, so long as it
>> terminates the program by eventually calling std::terminate.
> I strongly believe that is the wrong mechanism. std::terminate is a facility
> "... for coping with errors related to the exception handling mechanism ..."
> [except.special]; falling off the end of a value-returning function has
> absolutely nothing to do with exceptions. If ubsan is to be standardized
> (and I'm broadly in favor of that, given suitable opt-outs) it should happen
> through an appropriate mechanism, not be shoehorned into the exception
> handling mechanism.
I fail to see what you're talking about. We have been describing ways to provide
diagnostics when terminate() is called, and that is not related to the exception
handling mechanism.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 5 Feb 2016 11:30:30 +0000
Raw View
--001a1140f750b3071e052b042d59
Content-Type: text/plain; charset=UTF-8
On Fri, Feb 5, 2016 at 9:53 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 5 February 2016 at 11:07, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
> > On Fri, Feb 5, 2016 at 1:20 AM, Ville Voutilainen
> >> How is that different from any other case of terminating a program?
> > When std::terminate is invoked in a manner prescribed by the standard,
> there
> > is a current exception available to the terminate handler.
>
> None of what we have described changes any of that.
>
I'm not suggesting a change; I'm pointing out that terminate is not an
appropriate mechanism for terminating the program in cases that do not
involve the exception handling mechanism.
> >> The proposal in question is that the program be terminated. Nothing in
> it
> >> says
> >> that it needs to be a silent termination. Nor does it require a
> >> diagnostic.
> > And then you're throwing away information that existing implementations
> have
> > shown is readily available.
>
> I fail to see what information we would supposedly throw away.
Source location and nature of the error causing termination.
> >> What the compiler may want to implement is its own business, so long as
> it
> >> terminates the program by eventually calling std::terminate.
> > I strongly believe that is the wrong mechanism. std::terminate is a
> facility
> > "... for coping with errors related to the exception handling mechanism
> ..."
> > [except.special]; falling off the end of a value-returning function has
> > absolutely nothing to do with exceptions. If ubsan is to be standardized
> > (and I'm broadly in favor of that, given suitable opt-outs) it should
> happen
> > through an appropriate mechanism, not be shoehorned into the exception
> > handling mechanism.
>
> I fail to see what you're talking about. We have been describing ways to
> provide
> diagnostics when terminate() is called, and that is not related to the
> exception
> handling mechanism.
But terminate() *is* part of the exception handling mechanism; it is not a
general error handling mechanism.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1140f750b3071e052b042d59
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 F=
ri, Feb 5, 2016 at 9:53 AM, Ville Voutilainen <span dir=3D"ltr"><<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 5 Feb=
ruary 2016 at 11:07, 'Edward Catmur' via ISO C++ Standard -<br>
Future Proposals <<a href=3D"mailto:std-proposals@isocpp.org">std-propos=
als@isocpp.org</a>> wrote:<br>
<span class=3D"">> On Fri, Feb 5, 2016 at 1:20 AM, Ville Voutilainen<br>=
</span>>> How is that different from any other case of terminating a =
program?<br>> When std::terminate is invoked in a manner prescribed by t=
he standard, there<br>
> is a current exception available to the terminate handler.<br>
<br>
None of what we have described changes any of that.<span class=3D""><br></s=
pan></blockquote><div><br></div><div>I'm not suggesting a change; I'=
;m pointing out that terminate is not an appropriate mechanism for terminat=
ing the program in cases that do not involve the exception handling mechani=
sm.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">
>> The proposal in question is that the program be terminated. Nothin=
g in it<br>
>> says<br>
>> that it needs to be a silent termination. Nor does it require a<br=
>
>> diagnostic.<br>
> And then you're throwing away information that existing implementa=
tions have<br>
> shown is readily available.<br>
<br>
</span>I fail to see what information we would supposedly throw away.</bloc=
kquote><div><br></div><div>Source location and nature of the error causing =
termination.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><sp=
an class=3D"">
>> What the compiler may want to implement is its own business, so lo=
ng as it<br>
>> terminates the program by eventually calling std::terminate.<br>
> I strongly believe that is the wrong mechanism. std::terminate is a fa=
cility<br>
> "... for coping with errors related to the exception handling mec=
hanism ..."<br>
> [except.special]; falling off the end of a value-returning function ha=
s<br>
> absolutely nothing to do with exceptions. If ubsan is to be standardiz=
ed<br>
> (and I'm broadly in favor of that, given suitable opt-outs) it sho=
uld happen<br>
> through an appropriate mechanism, not be shoehorned into the exception=
<br>
> handling mechanism.<br>
<br>
</span>I fail to see what you're talking about. We have been describing=
ways to provide<br>
diagnostics when terminate() is called, and that is not related to the exce=
ption<br>
handling mechanism.</blockquote><div><br></div><div>But terminate() *is* pa=
rt of the exception handling mechanism; it is not a general error handling =
mechanism.</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a1140f750b3071e052b042d59--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 5 Feb 2016 13:52:38 +0200
Raw View
On 5 February 2016 at 13:30, 'Edward Catmur' via ISO C++ Standard -
Future Proposals >> > When std::terminate is invoked in a manner
prescribed by the standard,
>> > there
>> > is a current exception available to the terminate handler.
>> None of what we have described changes any of that.
> I'm not suggesting a change; I'm pointing out that terminate is not an
> appropriate mechanism for terminating the program in cases that do not
> involve the exception handling mechanism.
The standard disagrees with you, because terminate is also used in cases
where an exception cannot be thrown, which is the same situation as we
would have with a non-void function falling of its end.
>> >> The proposal in question is that the program be terminated. Nothing in
>> >> it
>> >> says
>> >> that it needs to be a silent termination. Nor does it require a
>> >> diagnostic.
>> > And then you're throwing away information that existing implementations
>> > have
>> > shown is readily available.
>> I fail to see what information we would supposedly throw away.
> Source location and nature of the error causing termination.
There's no reason why that information would be thrown away, if it existed
in the first place, which is not always the case in a terminate handler.
> But terminate() *is* part of the exception handling mechanism; it is not a
> general error handling mechanism.
That first part is incorrect, and the second part is debatable.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 5 Feb 2016 15:02:57 +0000
Raw View
--001a113fec6c864928052b072527
Content-Type: text/plain; charset=UTF-8
On Fri, Feb 5, 2016 at 11:52 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 5 February 2016 at 13:30, 'Edward Catmur' via ISO C++ Standard -
> Future Proposals >> > When std::terminate is invoked in a manner
> prescribed by the standard,
> >> > there
> >> > is a current exception available to the terminate handler.
> >> None of what we have described changes any of that.
> > I'm not suggesting a change; I'm pointing out that terminate is not an
> > appropriate mechanism for terminating the program in cases that do not
> > involve the exception handling mechanism.
>
> The standard disagrees with you, because terminate is also used in cases
> where an exception cannot be thrown,
What are those cases? The only use of std::terminate that is not (always)
in response to an exception being thrown (or rethrown) is
std::thread::~thread; there, it's less that an exception cannot be thrown
and rather that the standard has decided that it will usually occur during
stack unwinding and so would end up calling std::terminate anyway.
> which is the same situation as we
> would have with a non-void function falling of its end.
>
Why shouldn't a missing return handler throw an exception? Actually, this
would be another reason not to use std::terminate, as it's nothrow.
> >> >> The proposal in question is that the program be terminated. Nothing
> in
> >> >> it
> >> >> says
> >> >> that it needs to be a silent termination. Nor does it require a
> >> >> diagnostic.
> >> > And then you're throwing away information that existing
> implementations
> >> > have
> >> > shown is readily available.
> >> I fail to see what information we would supposedly throw away.
> > Source location and nature of the error causing termination.
>
> There's no reason why that information would be thrown away, if it existed
> in the first place, which is not always the case in a terminate handler.
It is available to a missing return handler; at least, it is for Clang's
missing return handler. Now we have std::experimental::source_location,
wouldn't you want to make that available to a missing return handler?
> > But terminate() *is* part of the exception handling mechanism; it is not
> a
> > general error handling mechanism.
>
> That first part is incorrect, and the second part is debatable.
[except.special]:
The functions std::terminate() (15.5.1) and std::unexpected() (15.5.2) are
used by the exception handling mechanism for coping with errors related to
the exception handling mechanism itself.
[except.terminate]:
In some situations exception handling must be abandoned for less subtle
error handling techniques. [...]
In such cases, std::terminate() is called. [...]
[terminate]:
Remarks: Called by the implementation when exception handling must be
abandoned for any of several reasons (15.5.1), in effect immediately after
throwing the exception. May also be called directly by the program.
Seems like part of the exception handling mechanism to me.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113fec6c864928052b072527
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 F=
ri, Feb 5, 2016 at 11:52 AM, Ville Voutilainen <span dir=3D"ltr"><<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex">On 5 February 2016 at=
13:30, 'Edward Catmur' via ISO C++ Standard -<br>
Future Proposals >> > When std::terminate is invoked in a manner<b=
r>
<span class=3D"">prescribed by the standard,<br>
>> > there<br>
>> > is a current exception available to the terminate handler.<br=
>
>> None of what we have described changes any of that.<br>
> I'm not suggesting a change; I'm pointing out that terminate i=
s not an<br>
> appropriate mechanism for terminating the program in cases that do not=
<br>
> involve the exception handling mechanism.<br>
<br>
</span>The standard disagrees with you, because terminate is also used in c=
ases<br>
where an exception cannot be thrown, </blockquote><div><br></div><div>What =
are those cases? The only use of std::terminate that is not (always) in res=
ponse to an exception being thrown (or rethrown) is std::thread::~thread; t=
here, it's less that an exception cannot be thrown and rather that the =
standard has decided that it will usually occur during stack unwinding and =
so would end up calling std::terminate anyway.</div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex">which is the same situation as we<br>
would have with a non-void function falling of its end.<span class=3D""><br=
></span></blockquote><div><br></div><div>Why shouldn't a missing return=
handler throw an exception? Actually, this would be another reason not to =
use std::terminate, as it's nothrow.</div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex"><span class=3D"">
>> >> The proposal in question is that the program be terminate=
d. Nothing in<br>
>> >> it<br>
>> >> says<br>
>> >> that it needs to be a silent termination. Nor does it req=
uire a<br>
>> >> diagnostic.<br>
>> > And then you're throwing away information that existing i=
mplementations<br>
>> > have<br>
>> > shown is readily available.<br>
>> I fail to see what information we would supposedly throw away.<br>
> Source location and nature of the error causing termination.<br>
<br>
</span>There's no reason why that information would be thrown away, if =
it existed<br>
in the first place, which is not always the case in a terminate handler.</b=
lockquote><div><br></div><div>It is available to a missing return handler; =
at least, it is for Clang's missing return handler. Now we have std::ex=
perimental::source_location, wouldn't you want to make that available t=
o a missing return handler?</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span cl=
ass=3D"">
> But terminate() *is* part of the exception handling mechanism; it is n=
ot a<br>
> general error handling mechanism.<br>
<br>
</span>That first part is incorrect, and the second part is debatable.</blo=
ckquote><div><br></div><div>[except.special]:</div><div>The functions std::=
terminate() (15.5.1) and std::unexpected() (15.5.2) are used by the excepti=
on handling
mechanism for coping with errors related to the exception handling mechanis=
m itself.<br></div><div><br></div><div>[except.terminate]:</div><div>In som=
e situations exception handling must be abandoned for less subtle error han=
dling techniques. [...]<br></div><div>In such cases, std::terminate() is ca=
lled. [...]<br></div><div><br></div><div>[terminate]:<br></div><div>Remarks=
: Called by the implementation when exception handling must be abandoned fo=
r any of several
reasons (15.5.1), in effect immediately after throwing the exception. May a=
lso be called directly by the
program.<br></div><div><br></div><div>Seems like part of the exception hand=
ling mechanism to me.</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a113fec6c864928052b072527--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 5 Feb 2016 17:18:20 +0200
Raw View
On 5 February 2016 at 17:02, 'Edward Catmur' via ISO C++ Standard -
Future Proposals >> The standard disagrees with you, because terminate
is also used in cases
>> where an exception cannot be thrown,
> What are those cases? The only use of std::terminate that is not (always) in
> response to an exception being thrown (or rethrown) is std::thread::~thread;
The uses of terminate() in threads and condition variables are cases
where an exception cannot
be thrown. Sure, the notes suggest that for condition variables,
terminate() is invoked
as a response to an exception having been thrown (and caught).
> there, it's less that an exception cannot be thrown and rather that the
> standard has decided that it will usually occur during stack unwinding and
> so would end up calling std::terminate anyway.
In other words, an exception cannot be thrown. It's not just because
it will invoke
terminate anyway that the thread destructor doesn't throw.
>> which is the same situation as we
>> would have with a non-void function falling of its end.
> Why shouldn't a missing return handler throw an exception? Actually, this
> would be another reason not to use std::terminate, as it's nothrow.
A "return handler"? Well, if you want to propose that the standard provides
a specific handler for such cases, by all means. A non-void function that fails
to return a value should IMHO not become a throwing function so easily if
it wasn't before. It's a logic error, and throwing an exception that
the programmer
didn't is less likely to be a safe solution than terminating is.
>> There's no reason why that information would be thrown away, if it existed
>> in the first place, which is not always the case in a terminate handler.
> It is available to a missing return handler; at least, it is for Clang's
> missing return handler. Now we have std::experimental::source_location,
> wouldn't you want to make that available to a missing return handler?
I might consider it nice-to-have, but not something fundamental.
>> > But terminate() *is* part of the exception handling mechanism; it is not
>> > a
>> > general error handling mechanism.
>> That first part is incorrect, and the second part is debatable.
> [except.special]:
> The functions std::terminate() (15.5.1) and std::unexpected() (15.5.2) are
> used by the exception handling mechanism for coping with errors related to
> the exception handling mechanism itself.
>
> [except.terminate]:
> In some situations exception handling must be abandoned for less subtle
> error handling techniques. [...]
> In such cases, std::terminate() is called. [...]
>
> [terminate]:
> Remarks: Called by the implementation when exception handling must be
> abandoned for any of several reasons (15.5.1), in effect immediately after
> throwing the exception. May also be called directly by the program.
>
> Seems like part of the exception handling mechanism to me.
You seem to read that text selectively, perhaps in a way suitable for your
local style guide and personal preference, but the
"May also be called directly by the program." part and the fact that
the standard
facilities themself use terminate() when they can't throw disagree
with your view.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "'Edward Catmur' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 5 Feb 2016 16:50:39 +0000
Raw View
--047d7b3a9712a7fdfe052b08a6ab
Content-Type: text/plain; charset=UTF-8
On Fri, Feb 5, 2016 at 3:18 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> In other words, an exception cannot be thrown. It's not just because
> it will invoke
> terminate anyway that the thread destructor doesn't throw.
>
There's nothing in the language preventing ~thread throwing; it could e.g.
move itself into an exception object, avoiding leaks while giving a handler
an opportunity to properly wait on or detach the thread. But in the vast
majority of cases you'd just end up with terminate being called anyway,
similarly to how Hans Boehm says on http://wg21.cmeerw.net/lwg/issue2135.
> >> which is the same situation as we
> >> would have with a non-void function falling of its end.
> > Why shouldn't a missing return handler throw an exception? Actually, this
> > would be another reason not to use std::terminate, as it's nothrow.
>
> A "return handler"? Well, if you want to propose that the standard provides
> a specific handler for such cases, by all means. A non-void function that
> fails
> to return a value should IMHO not become a throwing function so easily if
> it wasn't before. It's a logic error, and throwing an exception that
> the programmer
> didn't is less likely to be a safe solution than terminating is.
Every function not marked nothrow is potentially a throwing function,
especially if it allocates memory or interacts with the system in any way.
I don't see any reason to consider a missing return an irrecoverable error;
it's no worse than calling value() on an empty optional. There is after all
a whole class hierarchy in <stdexcept> for logic errors. The language
throws exceptions to signify recoverable errors in plenty of places:
bad_alloc, bad_cast, bad_typeid.
> Seems like part of the exception handling mechanism to me.
>
> You seem to read that text selectively, perhaps in a way suitable for your
> local style guide and personal preference, but the
> "May also be called directly by the program." part and the fact that
> the standard
> facilities themself use terminate() when they can't throw disagree
> with your view.
When they can't throw - it's a fallback for the exception handling
mechanism.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b3a9712a7fdfe052b08a6ab
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 F=
ri, Feb 5, 2016 at 3:18 PM, Ville Voutilainen <span dir=3D"ltr"><<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">In other words, an exc=
eption cannot be thrown. It's not just because<br>
it will invoke<br>
terminate anyway that the thread destructor doesn't throw.<span class=
=3D""><br></span></blockquote><div><br></div><div>There's nothing in th=
e language preventing ~thread throwing; it could e.g. move itself into an e=
xception object, avoiding leaks while giving a handler an opportunity to pr=
operly wait on or detach the thread. But in the vast majority of cases you&=
#39;d just end up with terminate being called anyway, similarly to how Hans=
Boehm says on=C2=A0<a href=3D"http://wg21.cmeerw.net/lwg/issue2135">http:/=
/wg21.cmeerw.net/lwg/issue2135</a>.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<span class=3D"">
>> which is the same situation as we<br>
>> would have with a non-void function falling of its end.<br>
> Why shouldn't a missing return handler throw an exception? Actuall=
y, this<br>
> would be another reason not to use std::terminate, as it's nothrow=
..<br>
<br>
</span>A "return handler"? Well, if you want to propose that the =
standard provides<br>
a specific handler for such cases, by all means. A non-void function that f=
ails<br>
to return a value should IMHO not become a throwing function so easily if<b=
r>
it wasn't before. It's a logic error, and throwing an exception tha=
t<br>
the programmer<br>
didn't is less likely to be a safe solution than terminating is.</block=
quote><div><br></div><div>Every function not marked nothrow is potentially =
a throwing function, especially if it allocates memory or interacts with th=
e system in any way. I don't see any reason to consider a missing retur=
n an irrecoverable error; it's no worse than calling value() on an empt=
y optional. There is after all a whole class hierarchy in <stdexcept>=
for logic errors. The language throws exceptions to signify recoverable er=
rors in plenty of places: bad_alloc, bad_cast, bad_typeid.</div><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex"><span class=3D"">> Seems like part of the exception=
handling mechanism to me.<br>
<br>
</span>You seem to read that text selectively, perhaps in a way suitable fo=
r your<br>
local style guide and personal preference, but the<br>
"May also be called directly by the program." part and the fact t=
hat<br>
the standard<br>
facilities themself use terminate() when they can't throw disagree<br>
with your view.</blockquote><div><br></div><div>When they can't throw -=
it's a fallback for the exception handling mechanism.</div></div></div=
></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--047d7b3a9712a7fdfe052b08a6ab--
.