Does the C++ standard mandate that C-linkage functions are `noexcept`?

Question

I can't find anything in the standard that forces functions declared with extern "C" to be noexcept, either implicitly or explicitly.

Yet, it should be clear that C calling conventions cannot support exceptions... or is it?

Does the standard mention this, somewhere that I've missed? If not, why not? Is it simply left as an implementation detail of sorts?

Answer 1

As far as I can tell there is no guarantee that function defined with "C" linkage will not throw exceptions. The standard allows a C++ program both to call an external function with "C" language linkage, and to define functions written in C++ that have "C" language linkage. Therefore there is nothing to prevent a C++ program from calling a function with "C" language linkage that is actually written in C++ (in another compilation unit maybe, although even this is not necessary). It would be a strange thing to do, but it is hard to rule out. Also I don't see where in the standard it says that doing so would lead to undefined behavior (in fact since the Standard cannot define the bahavior of function not written in C++, this would be the only usage where there is not formally undefined behavior).

As a consequence I think it would be an error to assume that "C" linkage implies noexcept.

Answer 2

Um, I assume extern "C" just use C-linkage, not C function. It prevents the compiler from doing C++ name mangling.

More directly - Suppose this code.

// foo.cpp
extern "C" void foo()
{
    throw 1;
}

// bar.cpp
extern "C" void foo();
void bar()
{
    try
    {
        foo();
    }
    catch (int)
    {
        // yeah!
    }
}

Answer 3

There is nothing anywhere that says that extern "C" functions are noexcept. On the other hand, almost all C standard library functions are noexcept unless you do something strange. Typically, this boils down to invoking undefined behavior, but there are a few other cases. These should be all of them:

• The function pointer argument to qsort() can throw; therefore qsort() can throw.
• The same is true of bsearch().
• You are allowed to replace malloc(), realloc(), and free(). If you do, these may throw.
• In the previous case, calloc(), fopen(), fclose(), freopen(), system(), and strdup() may also throw. (strdup() is defined but not guaranteed to exist.)
• setjmp() and catch(...) don't mix. At least one platform implemented longjmp() as the logical equivalent of throw jmp_buf, causing catch(...) to catch it.
• Undefined behavior may throw. Some systems actually do implement *NULL as throw exception that can be caught by catch(...) even when compiling C code. If you execute undefined behavior anywhere, the entire program is undefined as soon as the code path is irrevocably committed to reaching undefined behavior, so this can cause C standard library functions to throw.