This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/3] network: recvmsg and sendmsg standard compliance (BZ#16919)
- From: Zack Weinberg <zackw at panix dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, GNU C Library <libc-alpha at sourceware dot org>, Florian Weimer <fweimer at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>
- Date: Thu, 9 Jun 2016 09:35:41 -0400
- Subject: Re: [PATCH 2/3] network: recvmsg and sendmsg standard compliance (BZ#16919)
- Authentication-results: sourceware.org; auth=none
- References: <1459175641-12520-1-git-send-email-adhemerval dot zanella at linaro dot org> <1459175641-12520-3-git-send-email-adhemerval dot zanella at linaro dot org> <a963950f-bb21-be79-bddd-8379b588378a at panix dot com> <5756D873 dot 1000701 at linaro dot org> <CAKCAbMgk7vtMFoXKJ45TwnFv7gqNesNk0AuSRHvg58XMSMaQTg at mail dot gmail dot com> <575886C8 dot 8000401 at linaro dot org> <5758DFF7 dot 5020800 at redhat dot com>
On Wed, Jun 8, 2016 at 11:18 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 06/08/2016 04:57 PM, Adhemerval Zanella wrote:
>> On 08/06/2016 17:15, Zack Weinberg wrote:
>>> What would persuade you to accept *my* position on this issue?
>>
>> I am stating we follow POSIX to very reason we follow other technical
>> standard: to provide libc compatibility.
>
> There are some places where POSIX and Linux disagree.
> In as much as we possibly can we should try to standardize on POSIX.
Right, so as I have been saying all along, I don't agree with this; I
think it is *more important* to faithfully reflect the semantics of
each supported kernel. If that means that glibc-on-Linux has
different semantics than glibc-on-FreeBSD (for instance), well, that
was probably unavoidable anyway.
The reason for this is that POSIX is very slow, and the C library
should not stand in the way of *improvements* to the kernel interface.
The case we're arguing about is relatively minor, but maybe someone
has an actual need for size_t-sized ancillary data buffers - I don't
think we should be judging whether that is a valid use case.
(A much more significant issue here is the ridiculous delays in adding
things like gettid() and getrandom().)
> Each decision should be done on a case-by-base basis, and I think in
> this case of recvmsg/sendmsg it is possible to comply with POSIX without
> serious problems. I've only seen rare examples of theoretical breakage,
> and the reported dlsym issue simply needs fixing in the dynamic loader.
I do not think the reported dlsym issue is a simple matter to fix. I
haven't sat down and worked it out, but I am fairly sure it is
possible, for most symbols that glibc exposes multiple versions of, to
construct a pair of interposition modules which are black-box
indistinguishable except that one of them needs version A and the
other needs version B -- which is to say, whatever dlsym("name",
RTLD_NEXT) does, it's going to be wrong for one of them. Which is why
there is dlvsym()... but changing the semantics of dlsym() strikes me
as asking for much greater breakage.
zw