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] |
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] |