[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH glibc v2 26/34] hurd: Remove __hurd_local_reply_port
From: |
Sergey Bugaev |
Subject: |
Re: [RFC PATCH glibc v2 26/34] hurd: Remove __hurd_local_reply_port |
Date: |
Thu, 13 Apr 2023 16:20:50 +0300 |
On Thu, Apr 13, 2023 at 4:12 PM Samuel Thibault <samuel.thibault@gnu.org> wrote:
at ../sysdeps/mach/hurd/dl-sysdep.c:241
> 241 __mig_dealloc_reply_port (MACH_PORT_NULL);
Uhh, who deallocs a reply port like that :| You can't pass random crap
into __mig_dealloc_reply_port and rely on its particular
implementation, which *happened* to deallocate the current port.
Apparently FATAL_PREPARE in dl-sysdep.h is also defined to do the same.
I'd rather fix these both to do
__mig_dealloc_reply_port (__mig_get_reply_port ());
but we can also explicitly support passing MACH_PORT_NULL to mean
"dealloc whatever you have stored", i.e. the previous behavior.
Which one would you prefer?
Sergey
- Re: [RFC PATCH glibc 26/34] hurd: Remove __hurd_local_reply_port, Samuel Thibault, 2023/04/10
- Re: [RFC PATCH glibc 26/34] hurd: Remove __hurd_local_reply_port, Samuel Thibault, 2023/04/10
- Re: [RFC PATCH glibc 26/34] hurd: Remove __hurd_local_reply_port, Sergey Bugaev, 2023/04/11
- Re: [RFC PATCH glibc v2 26/34] hurd: Remove __hurd_local_reply_port, Samuel Thibault, 2023/04/14
- Re: [RFC PATCH glibc v2 26/34] hurd: Remove __hurd_local_reply_port, Sergey Bugaev, 2023/04/14
- Re: [RFC PATCH glibc v2 26/34] hurd: Remove __hurd_local_reply_port, Samuel Thibault, 2023/04/15
- Re: [RFC PATCH glibc v2 26/34] hurd: Remove __hurd_local_reply_port, Sergey Bugaev, 2023/04/15
- Re: [RFC PATCH glibc v2 26/34] hurd: Remove __hurd_local_reply_port, Samuel Thibault, 2023/04/15