stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <>
Subject RE: svn commit: r565959 - /incubator/stdcxx/trunk/etc/config/src/EXTERN_C_EXCEPTIONS.cpp
Date Tue, 21 Aug 2007 21:41:34 GMT


>Martin Sebor wrote:
>Farid Zaripov wrote:
>> I've just tried to declare and define __rw_once with throw(...)
>> exception specification and compiler doesn't issues warning in
>> that case.

Yes, but the documentation linked to explicitly says...

  Explicit exception specifications are not allowed on C functions.

I tested, it does compile, and the destructors are getting called as
they should when an explicit throw(...) spec is added to the C linkage
function. That said, I cringe at the thought relying on behavior that is
documented to not work or is not supported.

Maybe when the documentation is referring to C functions it means
functions that are compiled as C source [x.c instead of x.cpp] and not
functions with C linkage?

>Good to know! We still need to decide how to handle this in
>the general case (for compilers that behave like MSVC, if
>there are any) but we can certainly start using this extension
>to silence the MSVC warnings.

Is the goal really to just squelch the warnings? I hope not.

So back at square one, I have another question. Lets assume a program
will abort() if an exception is thrown through a C function. This
characterization test will fail, and the build framework will probably
set a preprocessor flag _RWSTD_NO_EXTERN_C_EXCEPTIONS. What exactly
would we do to prevent this from being a problem? I can think of two

  1. Add a try/catch block inside every once function definition
     that might throw.
  2. Implement our own pthread_once() type function that has C++
     linkage and use it with all configurations on all platforms.

Both solutions are compatible with all systems, and would eliminate the
warning on MSVC as a side effect. Obviously the first option isn't that
pleasant because there is no _good_ way I can see to communicate a
failure back to the application. Is there something wrong with the
second option?


View raw message