[bug #49023] glibc - hurd_safe_{copyin, copyout, memmove, memset} broken

Update of bug #49023 (project hurd): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #6: Done so in

[bug #49023] glibc - hurd_safe_{copyin, copyout, memmove, memset} broken

Follow-up Comment #5, bug #49023 (project hurd): Hint: use codesearch.debian.net ;) ___ Reply to this item at: ___ Message sent via/by Savannah

[bug #49023] glibc - hurd_safe_{copyin, copyout, memmove, memset} broken

Follow-up Comment #4, bug #49023 (project hurd): Yes, that's what I meant. The relation is that HURD_PREEMPT_SIGNAL_P's first argument is a struct hurd_signal_preemptor, so we'd be effectively changing how that structure is interpreted. Its "first, last" range would now be compared against

[bug #49023] glibc - hurd_safe_{copyin, copyout, memmove, memset} broken

Follow-up Comment #3, bug #49023 (project hurd): I don't see the relation with HURD_PREEMPT_SIGNAL_P. Did you mean "is there some code which relies on the previous semantic of detail->code?" ? ___ Reply to this item at:

[bug #49023] glibc - hurd_safe_{copyin, copyout, memmove, memset} broken

Follow-up Comment #2, bug #49023 (project hurd): Is the signal preemption code used anywhere outside the C library? If not, changing the parameter to HURD_PREEMPT_SIGNAL_P sounds like a good solution. ___ Reply to this item at:

[bug #49023] glibc - hurd_safe_{copyin, copyout, memmove, memset} broken

Follow-up Comment #1, bug #49023 (project hurd): Hello, Wouldn't the solution be to pass detail->exc_subcode to HURD_PREEMPT_SIGNAL_P instead of detail->code? How to reproduce the issue easily btw? ___ Reply to this item at:

[bug #49023] glibc - hurd_safe_{copyin, copyout, memmove, memset} broken

URL: Summary: glibc - hurd_safe_{copyin, copyout, memmove, memset} broken Project: The GNU Hurd Submitted by: baccala Submitted on: Wed 07 Sep 2016 09:02:09 PM GMT Category: glibc