I'm trying to add "genric" #signal handling to #poser. Ultimate goal is to provide a way for #swad to handle #SIGHUP, although signal handling must be done in poser's main event loop (signals are only ever unblocked while waiting for file descriptor events).

Okay, I could just add explicit handling for SIGHUP. But a generic solution would be nicer. Just for example, a consumer might be interested in #SIGINFO which doesn't even exist on all platforms ...

Now, #POSIX specs basically just say signal constants are "integer values". Not too helpful here. Is it safe to assume an upper bound for signal numbers on "real world" OS implementations, e.g. 64 like on #Linux? Should I check #NSIG and, if not defined, just define it to 64?

Next #swad improvement: Make sure to #wipe #passwords from RAM directly after used. That's more of a #security precaution, because there *should* be no way how an attacker can access a running process' memory, but you never know which bugs surface .

Unexpectedly, that posed #portability issues. #C11 has #memset_s ... a pretty weird function, but suitable for wiping. It's there on #FreeBSD and on #OpenBSD. Not on #NetBSD though. But NetBSD offers the much saner #C23 function #memset_explicit. Looking at #Linux, there's neither. But there is the (non-standard!) #explicit_bzero .. and with glibc, it requires _DEFAULT_SOURCE to be defined as soon as you compile with a C standard version given to the compiler. This function exists on some other systems as well, but there's confusion whether it should be declared in string.h or strings.h.

Here's the full set of compile-tests I'm now doing, only to find the best way to really erase memory:
https://github.com/Zirias/swad/blob/master/src/bin/swad/swad.mk#L6

And if none of these functions is found, swad uses the "hacky" way that most likely works as well: Access the normal memset function via a volatile pointer.