Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 11 Nov 2014 09:28:56 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Nonstandard functions with callbacks

On Tue, Nov 11, 2014 at 03:56:12PM +0200, Timo Teras wrote:
> On Tue, 11 Nov 2014 08:46:53 -0500
> Rich Felker <dalias@...c.org> wrote:
> 
> > While of course I can't make the decision for you, I'd really
> > encourage distros not to add to or change the public API in musl in
> > ways that are not expected to ever make it upstream. The result is
> > application binaries that have an undocumented dependency on your
> > distro-specific version of musl and that won't work elsewhere, which
> > is not so much of an issue for your own distro binaries, but is a
> > potential gotcha for anyone compiling their own binaries on your dist
> > and expecting them to work on other musl-based systems. Up to now I've
> > been trying to reduce and hopefully eliminate the Alpine patches to
> > musl that affect public interfaces and I think we're almost there.
> 
> Yes, we are not doing hasty decisions. So it's on hold for the time
> being. I filed bug against Asterisk to see what happens. They are
> supposed supporting Solaris and Mingw, which both lack this
> functionality. It seems to have broken on Asterisk 13. Well TLS will
> not work without that, but in Asterisk 13 they broke regular non-TLS
> tcp connections...

Sounds like a mess, but this is good from our standpoint in that it
means they have a real problem they need to solve (regressions on
their side) rather than it just being compatibility with musl (which
they might not particularly care about).

> > Have you looked at what other programs do as a fallback when there's
> > no fopencookie? I don't think it's possible to match the API 100% with
> > this approach (seeking won't work, for instance), but it seems
> > possible to do a fallback implementation based on pthread_create and
> > socketpair that doesn't depend on implementation internals of stdio,
> > so that it could go into the application or a shim library.
> 
> No. This is not simple. The read and write callbacks take timer
> value from cookie, and they block up until specific timeout. So yeah,
> it goes basically even weirder.

That's not a problem. You can do timeouts in many other ways, like
applying the timeout to the socketpair with setsockopt or simply
having the helper thread close the socket when you want it to timeout.
However this kind of thing is likely best done in application specific
code rather than via a fake fopencookie.

> They modify semantics of fread() and
> fwrite() which is kinda nasty.

How so? Are you talking about the timeouts or something else?

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.