Why is context in sigaction handler a void pointer?

Question

In sigaction(2) man page:

The siginfo_t argument to a SA_SIGINFO handler
   When the SA_SIGINFO flag is specified in act.sa_flags, the signal
   handler address is passed via the act.sa_sigaction field.  This han‐
   dler takes three arguments, as follows:

       void
       handler(int sig, siginfo_t *info, void *ucontext)
       {
           ...
       }

Why is ucontext a void * when the man page states that it is a ucontext_t *?

ucontext
          This is a pointer to a ucontext_t structure, cast to void *.
          The structure pointed to by this field contains signal context
          information that was saved on the user-space stack by the ker‐
          nel; for details, see sigreturn(2).  Further information about
          the ucontext_t structure can be found in getcontext(3).  Com‐
          monly, the handler function doesn't make any use of the third
          argument.

Which `sigaction(2)` page are you referring to? One from a generic specification, or describing the behavior of a specific operating system? — aschepler, Aug 02 '18 at 00:39

paxdiablo · Accepted Answer · 2018-08-02T02:31:28.523

2

POSIX actually requires this to be a void *, the third argument to sigaction is:

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

Additionally, since a void * can be freely cast to and from any other sort of data pointer, there's little reason not to use the general case in a situation where you may want to seamlessly add different types in future.

edited Aug 02 '18 at 02:31

answered Aug 02 '18 at 00:58

paxdiablo

854,327
234
1,573
1,953

1

Wouldn't that be an argument for never using the pointer for a type you know ahead of time? Why not always use void * then? – Adam Thompson Aug 02 '18 at 01:09
2

@Adam: because, in the general case, using `void *` prevents the compiler from catching type errors. For example, if you pass a pointer-to-four-byte-int to a function that treats it as an pointer-to-eight-byte-double and plays around with the underlying memory, you're going to get hit with undefined behaviour. The idea is to *prefer* type safety but just go around it when you need a pointer-to-arbitrary-type. – paxdiablo Aug 02 '18 at 02:27
1

This answer seems to just push the question back a level - why does POSIX require the third argument to be `void *` instead of `ucontext_t *`? Is there any concrete reason why the POSIX committee thought this specific argument needed type flexibility? – zwol Aug 02 '18 at 19:37
@zwol pretty much, especially when it is specified that it _will_ be type `ucontext_t *`. – Adam Thompson Aug 02 '18 at 19:45

Why is context in sigaction handler a void pointer?

1 Answers1