On Sat, Nov 06, 2021 at 06:28:31PM +0000, Jon Chesterfield wrote:
> That's a compiler bug, surely. A C function that takes no callbacks is not
> going to throw.
I don't think the compiler can prove that. As far as I know the extern
"C" {} that C headers get wrapped in for C++ just means the compiler
doesn't type-mangle function names. The function itself can not only
throw by itself but it can also call other functions that throw as part
of its implementation.
That's correct. In general, extern "C" functions are allowed to throw.
If there's a compiler bug here it would have to be that it discards
knowledge about C standard functions that can indeed not throw. I don't
know if that's the case here, or if it's just nonstandard functions that
are affected.
Some of the common standard functions are detected and treated specially by compilers. Such libc functions that have special-casing are already generally treated as non-throwing by both GCC and Clang. However, there are a _lot_ of libc functions, both standard and nonstandard, that the compiler doesn't hardcode any knowledge about.
FWIW I don't think musl should tag any functions with anything just to
make C++ marginally faster. This seems like a case of C++ getting
hoisted by its own petard.
I have no horse in this race, but that really seems not a very helpful attitude. There's a large number of users of libc who are using C++ rather than C -- and many (most?) of them are compiling with exceptions enabled. If adding minor cruft to all of the libc function declarations will make a meaningful difference to all of that code's performance, that seems well worth considering, regardless of anyone's opinions regarding decisions about how to implement exceptions in C++ that were made 30 years ago.
Glibc defines macros for this purpose, which expand into "throw()" in C++ and "__attribute__((__nothrow__))" in GCC-C. The latter is only useful in conjunction with an extremely-rarely-used feature, C code built with -fexceptions enabled, and is thus probably ignorable.