POSIX API and SOLID design principles

Although SOLID design principles are mainly applied to object-oriented systems, there are some SOLID concepts that can be applied to procedural programming, such as SRP or DIP. But when I studied some functions that are available in the POSIX API, I noticed that some principles are not respected, even though it could be so.

I'll take as an example SRP, and the system call sigaction :

SRP states that, in our case, a function must have a single responsibility, which means that changes in a single part of the specifications of our system is the one thing that could change the specifications of the function.
sigaction is a system call used to change the action taken by a process when it receives a signal.

sigaction can be used to install a basic handler of the form :

void (*sa_handler)(int)

Meaning that the handler receives just the number of the signal to perform its action. The system call can also be used to install a handler of the form :

void (*sa_sigaction)(int, siginfo_t*, void*)

Which let us gain more information about the handled signal. Both forms are installed with the same system call, thanks to flags that are placed by the caller.

In my point of view, sigaction violates the SRP principle, because it has the responsibility to implement both types of handler installation.

So my question is : does POSIX API violates SOLID principles, if so, why ?

Solution

With all due respect, I think your example is on thin ice (it also ignores the D in SOLID).

POSIX might be violating the SOLID principles (or it might not)... but on the other hand, POSIX has a mature understanding of what can be separated and what belongs together (an understanding that comes from practical use).

In other words, the question is about the scope of "what is a single responsibility?", and POSIX has decades of experience that help it draw the line.

In your example, you state that sigaction has to implement both types of something, but that is a fallacy.

sigaction has a single responsibility - it needs to register a callback. The callback type is irrelevant really, since the responsibility is in the "registering".

If an Array push function would be type agnostic, would it violate the SRP principle? No. It would handle a single responsibility - pushing to the Array. Same here.

If I were to follow your logic, implementing a different function per callback type, I will find myself writing the same code over and over with slight variations - this is a violation of the DRY principle and it's a clear sign that these functions share the same responsibility and should be unified.