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: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: 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:25:30 -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>
On Wed, Jun 8, 2016 at 4:57 PM, Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> On 08/06/2016 17:15, Zack Weinberg wrote:
>> On Tue, Jun 7, 2016 at 10:21 AM, Adhemerval Zanella
>> <adhemerval.zanella@linaro.org> wrote:
>>> On 07/06/2016 10:31, Zack Weinberg wrote:
>>>>
>>>> send/recv(m)msg are kernel primitives, and the fundamental basis of my
>>>> objection is that I think the C library should always faithfully expose
>>>> all the true kernel interfaces, *even if they are in some way wrong*.
...
>> You are going to have a very hard time persuading me to change my
>> position, and this ain't gonna do it. This is circular logic. "We
>> should follow POSIX because we should follow POSIX."
>>
>> I would consider a real (not made up for the purpose, and ideally,
>> already existing) program that is broken by not having these types be
>> as POSIX specifies to be a *valid argument* for changing the types,
>> but even that might not be a *persuasive* argument for changing the
>> types[.]
...
>> 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.
This is not a response to my argument.
I said that I consider faithfully exposing all the true kernel
interfaces to be MORE IMPORTANT than following POSIX. I also told you
what I would consider to be a valid (but not necessarily persuasive)
argument against my position: exhibit a real program that is broken by
this conformance deviation.
You respond by reiterating that following POSIX is important in the
abstract. Sure, but I still think that faithfully exposing all the
true kernel interfaces is *more* important. You give a reason why
it's important in the abstract: to provide compatibility with other
systems. Sure, but for that to have any persuasive force at all, you
need to exhibit a real program that cares.
And I would still like to know what could persuade *you* to agree with
*me*; maybe then I could actually present that.
> And the breakage Florian has pointed (and I replied) is a very
> specific one that also require the interposing library to know a
> very deal of the interposed library. This kind of tooling is highly
> coupled with implementation and there are various hacks and slight
> breakages that minor GLIBC changes already incurred (for instance
> on libsanitizer, every TCB size change needs to be explicit take
> in account).
I'm sorry, I have not been able to make any sense whatsoever out of
this paragraph.
> And I do not see the tooling breakage as compelling reason to break
> interface changes and fixes.
If you're trying to say that you think the breakage Florian cited is
too unusual to worry about, I cannot agree with that. We're bending
over backward to keep old Emacs binaries working that depended on
glibc-specific details of the malloc implementation -- interposition
of network APIs is commonplace by comparison.
(I also suspect that this *can't* be easily papered over by messing
with the semantics of dlsym() -- see upcoming reply to Carlos.)
>> You clearly still don't get it. It's not about the buffer being in a
>> racy condition. It's that the *address might be part of the message.*
>> "Nobody should do that" is NOT a valid objection, because this is an
>> arbitrarily extensible interface.
>>
>> Let me try again with another example.
[...]
> This very interface does not make sense
What part of '"Nobody should do that" is NOT a valid objection' was
unclear?
zw