This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Signal handler arguments


The only standards per se is what Ulrich cited.  That is, the SA_SIGINFO
signature you already have and all that's required is the first argument
for the no-SA_SIGINFO case.  So by the standards, it would always be fine
to just pass the SA_SIGINFO form.  What really matters though is existing
practice on your platform.  The traditional signature before SA_SIGINFO was
invented was (int sig, long code, struct sigcontext *) i.e. compatible
with what you cited.  For signals like SIGSEGV/SIGBUS the CODE parameter is
something useful like an address.  If it's really always been 0 on mips for
all signals, then there can't be anything expecting a useful value.
The struct sigcontext parameter might be another story.  But if you are
breaking binary compatibility with the struct sigcontext format anyway,
then you don't care.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]