My case is pretty simple: I want my C++ program to deal with Unix signals. To do so, glibc provides a function in signal.h called sigaction, which expects to re
My question is: is the
extern "C"linkage specifier necessary?
For maximum portability, yes; the C++ standard only guarantees interoperability with C via functions declared extern "C".
Practically, no; most sensible ABIs (including the GNU ABI used by glibc) will use the same calling convention for C and C++ non-member (and static member) functions, so that extern "C" is only needed to share the function name between languages.
Bonus question: can
uponSignalbe declared static?
Yes. External linkage is only needed to access the function by name from other translation units; it's not necessary to call the function via a function pointer.
extern C is only necessary if you export your symbols from your binary or import them from another binary (typically in both cases, a shared library), in order to avoid name mangling.
Here this is not the case, you're not linking uponSignal across various binaries so you don't need extern C. All you're doing is pass your function's address to sigaction from a function that already knows uponSignal's address since they are (apparently) part of the same translation unit, or at the very least of the same binary.
Bonus question: can
uponSignalbe declaredstatic?
Sure if you want. uponSignal doesn't need external linkage anyway.