Commit Graph

4 Commits

Author SHA1 Message Date
Elliott Hughes
c5d028fc91 Only have one copy of the kernel_sigset_t hack, and add more tests.
Change-Id: I377522fcba6fb4b5fd2754ab15b091014bd7c16f
2013-01-10 14:42:14 -08:00
Elliott Hughes
fb5e5cbdd4 Fix an off-by-one error in the sigset_t function error handling.
Spotted while running the tests on MIPS, where sigset_t is
actually large enough. The bits in sigset_t are used such that
signal 1 is represented by bit 0, so the range of signals is
actually [1, 8*sizeof(sigset_t)]; it seems clearer to reword
the code in terms of valid bit offsets [0, 8*sizeof(sigset_t)),
which leads to the usual bounds checking idiom.

Change-Id: Id899c288e15ff71c85dd2fd33c47f8e97aa1956f
2013-01-07 13:58:49 -08:00
Chris Dearman
d8a5a6f513 Use pthread_kill() in raise()
raise() should use pthread_kill() in a pthreads environment.
For bionic this means it should always be used.

Change-Id: Ic679272b664d2b8a7068b628fb83a9f7395c441f
2012-12-10 11:20:57 -08:00
Elliott Hughes
da73f655fc Add argument checking to sigemptyset(3) and friends.
You could argue that this is hurting people smart enough to have manually
allocated a large-enough sigset_t, but those people are smart enough to
implement their own sigset functions too.

I wonder whether our least unpleasant way out of our self-inflicted 32-bit
cesspool is to have equivalents of _FILE_OFFSET_BITS such as _SIGSET_T_BITS,
so calling code could opt in? You'd have to be careful passing sigset_t
arguments between code compiled with different options.

Bug: 5828899
Change-Id: I0ae60ee8544835b069a2b20568f38ec142e0737b
2012-11-30 16:40:55 -08:00