Should abort_handler_s() be async-signal safe ? There is no direct answer to the question in the standard, but intent is clearly to allow for almost mechanical replacement of the 'unsafe' (they are not, but I have no better term) functions by a 'safe' function (again, they are not).

memset(3) is async-signal safe, so we perhaps want the memset_s() to be useful in a signal context or be safe against cancellation.

abort() has contradictory requirements already, on the one hand C11 and POSIX claim that it must be async-signal safe, on the other hand POSIX says 'may include an attempt to effect fclose( ) on all open streams' and then admits that it is somewhat silly.

Our implementation of abort does try to call FILEs flush. More, __throw_constrain_handler_s() locks a mutex. Still, I am not sure that this is a good reason to add more async-signal unsafe code.

TL;DR version: I would very much prefer this fprintf call to be replaced with two write(2) calls.

You do not need braces there.

Yes, this is what I mean.

I would write this the '18' s line as

{
    static const char msg[] = "abort_hand.... : ";
...
   (void) _write(STDERR_FILENO, msg, sizeof(msg) - 1);
...