[klysm]

Sounds reasonable, but since the language layer has no knowledge of signal handlers or what that means, it would be a separation of concerns problem. I'm sure you could get clang to do it, but still a tricky thing to design around.

Ultimately it's an example of an invariant where it's clear that programmers can't be trusted to uphold it. In this case, the consequences can be very significant.

[Joker_vD]

> the language layer has no knowledge of signal handlers or what that means

Despite the fact that there is explicit runtime support for signal handlers in the language runtime (i.e. libc).

[ori_b]

Libc isn't the language runtime. The runtime is '/use/lib/crt*.o', which has no concept at all of signal handling.

Libc isn't particularly intrinsic to the language, and outside of some assembly to make syscalls, you can implement an alternative with a completely different interface, purely in C.

[SAI_Peregrinus]

The language standard library does, however, contain explicit support for signal handling, as specified in ISO/IEC 1989:2023 section 7.14 Signal handling <signal.h>. The cross-platform bits of libc are specified in the C standard. The POSIX-specific bits are specified by the Open Group in the POSIX standard. The OS-specific bits are specified by the OS and implemented by whoever is writing the libc in question. A libc is a sort of statically linked combination of the C standard library and some OS-specific standard library extensions.

[Joker_vD]

I am fairly certain that glibc uses SA_RESTORER in its sigaction wrapper and implements a suitable sigreturn() function which is provided as the sa_restorer argument.

[ori_b]

Sure, as can any library.

[sqeaky]

Yep, such is C.