[rfc] fix libstdc++/10606

Benjamin Kosnik bkoz@redhat.com
Tue Jan 4 21:54:00 GMT 2005


>> "From the data array it seems that Richard chose to implement a
>slightly> different behavior than what's being proposed in issue 475:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#475
>> According to bullet (4) of the proposed resolution, data[1] in the
>> test program should be { 1, 0, true }. I.e., uncaught_exception()
>> should return true immediately after completing the evaluation of
>> the operand of throw.
>
>If that's the semantics we want, I suppose it would be possible to
>increment the unhandled exception count in __cxa_allocate_exception.

For the record: I agree with Martin, in that I agree the test program is
correct as presently written. 

I don't have access to the LWG discussion at the moment. However,
looking carefully at the testcase, I think I understand what Martin is
saying.

Namely, from the testcase here:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01998.html

+      try
+	{
+	  S s0;
+	  throw s0;	// s1 is the exception object

we want

+  { 1, 0, false },	

for the s1 temporary object test data. I think this is correct because
this test occurs in the temporary object's ctor body, before the the
object is considered complete. I don't think it makes sense to have
uncaught_exception return true here, since the "uncaught exception
object" in question hasn't yet been (fully) constructed.

However, i'm uncertain if that means that the present DR wording is
incorrect. Does "completing evaluation of the throw object" (para 4)
mean that the the thrown object is completely constructed? If so, then
everybody's happy. If not, then I think the proposed resolution needs
some adjustment.

>It would make me feel better if this were'nt an open DR though.

Yeah, well. This is an improvement over the current state of things.

Can you check this in to 3.4.x and mainline? It seems as if the
consensus opinion of the GNU maintainers, at least, is in accordance
with this patch.

-benjamin



More information about the Libstdc++ mailing list