This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/2] jmpbuf: Add paddings for target specific usage
On 11/13/2017 03:05 PM, H.J. Lu wrote:
On Mon, Nov 13, 2017 at 5:09 AM, Florian Weimer <fweimer@redhat.com> wrote:
On 11/08/2017 07:27 PM, H.J. Lu wrote:
+/* The biggest signal number + 1 */
+#define _JUMP_BUF_SIGSET_NSIG 257
+/* Number of longs to hold all signals. */
+#define _JUMP_BUF_SIGSET_NWORDS \
+ ((_JUMP_BUF_SIGSET_NSIG - 1 + 7) / (8 * sizeof (unsigned long int)))
Where does 257 come from? 65 or 129 I would understand considering the
kernel sources, but 257 is odd.
Oh. I'm not sure if we should put this into installed header.
Maybe we can use a different approach? Something similar to the pthread
types? Or just not change the external type at all and just ad some
internal space reuse mechanism?
We had problems with people poking at supposedly invisible jmpbuf
contents in the past, and I'm worried that adding even __ members will
encourage that.
I think it would be clearer to hard-code the array sizes and explain why the
values where chosen in that way.
We also need a test that setprocmask does not read from the previously
Did you mean "sigprocmask"?
Right.
unused part. I can move the existing next_to_fault bits to support/ if that
would help.
Yes, please.
Okay, I'll move it to support/ soon.
Thanks,
Florian