sigaction don't support SIGRTMIN only when linking with libc

[patryk4815]

Zig Version

0.13.0

Steps to Reproduce and Observed Behavior

SIGRTMIN Is needed for catching signal eg. from timer_create
Example C code using here:
https://man7.org/linux/man-pages/man2/timer_create.2.html#EXAMPLES

const std = @import("std");
const posix = std.posix;
const testing = std.testing;

test "bug sigaction" {
  const sig = 32;  // SIGRTMIN eg. for timer_create / POSIX.1-2008
  try std.posix.sigaction(sig, null, null);
}

Without LIBC:

# zig test ./bugs/bugs.zig 
All 1 tests passed.

With LIBC:

# zig test -lc ./bugs/bugs.zig 
1/1 bugs.test.bug sigaction...FAIL (OperationNotSupported)
/nix/store/ni7kxhi72zipa3m071rpgqbqjw9capdm-zig-0.13.0/lib/zig/std/posix.zig:5641:27: 0x1039855 in sigaction (test)
        .INVAL, .NOSYS => return error.OperationNotSupported,
                          ^
/work/bugs/bugs.zig:7:3: 0x103979f in test.bug sigaction (test)
  try std.posix.sigaction(sigBigerThen31, null, null);
  ^
0 passed; 0 skipped; 1 failed.

Expected Behavior

Crash on both. Or supported or both.

SIGRTMIN = 34/35 with libc
SIGRTMIN = 32 without libc

[patryk4815]

The Linux kernel supports a range of 33 different real-time
signals, numbered 32 to 64. However, the glibc POSIX threads
implementation internally uses two (for NPTL) or three (for
LinuxThreads) real-time signals (see pthreads(7)), and adjusts
the value of SIGRTMIN suitably (to 34 or 35). Because the range
of available real-time signals varies according to the glibc
threading implementation (and this variation can occur at run
time according to the available kernel and glibc), and indeed the
range of real-time signals varies across UNIX systems, programs
should never refer to real-time signals using hard-coded numbers,
but instead should always refer to real-time signals using the
notation SIGRTMIN+n, and include suitable (run-time) checks that
SIGRTMIN+n does not exceed SIGRTMAX.

adjusts the value of SIGRTMIN suitably (to 34 or 35). Because the range of available real-time signals varies according to the glibc threading implementation
^ looks like when linking with libc 34+ or 35+ should be supported

[alexrp]

To be clear then, the issue is just the lack of SIG.RTMIN and SIG.RTMAX fields in std.c and std.os.linux (and by extension std.posix), yes?

[patryk4815]

@alexrp yes!

[alexrp]

Turns out this is complicated by glibc's way of defining these on some architectures:

zig/lib/libc/include/generic-glibc/signal.h

Lines 382 to 388 in 4ceefca

	/* Return number of available real-time signal with highest priority. */
	extern int __libc_current_sigrtmin (void) __THROW;
	/* Return number of available real-time signal with lowest priority. */
	extern int __libc_current_sigrtmax (void) __THROW;
	#define SIGRTMIN (__libc_current_sigrtmin ())
	#define SIGRTMAX (__libc_current_sigrtmax ())

I'm actually not sure how we would expose this in Zig. We'd probably have to make SIG.RT(MIN,MAX) functions instead of constants for all targets; doing it just for glibc would make it unnecessarily hard to write portable code.