|
Message-ID: <20141111134653.GH22465@brightrain.aerifal.cx> Date: Tue, 11 Nov 2014 08:46:53 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Nonstandard functions with callbacks On Tue, Nov 11, 2014 at 09:22:53AM +0200, Timo Teras wrote: > On Mon, 10 Nov 2014 23:50:46 -0500 > Rich Felker <dalias@...c.org> wrote: > > > The topic of fopencookie has just come up on #musl again in regards to > > Asterisk's dependence on it (or the similar funopen function), and in > > response I'd like to offer a few ideas on this kind of function in > > general. > > > > Supporting nonstandard functions is always a potential pitfall. Unlike > > functions with a rigorous or semi-rigorous specification in one or > > more standards documents, they inevitably have all sorts of > > underspecified or unspecified corner cases that some software ends up > > depending on. And when they come from a single origin (e.g. glibc) > > rather than various historical systems that all had their own quirks, > > it's arguably reasonable for applications to expect the exact behavior > > of the original (e.g. glibc) implementation. > > Understand. Especially for musl which aims to be mostly ABI compatible. IMO ABI is only a small part of the issue; the issue of source-level compatibility when an apparently API-compatible function is provided matters more. > > My feeling is that "involves callbacks" should be an indication for > > exclusion of nonstandard functions. In terms of what I've written > > above, I think this follows from the existing principles of exclusion > > based on cost of implementation complexity and high risk of > > compatibility issues with applications. > > As distribution, we want things to work. And we can limit support to > certain applications that use the specific API. And as we compile > everything against musl, we can also make additional ABI > considerations. So I think we'll still consider doing fopencookie() or > funopen() as distro-mainted patch. These are additional constraints we > can live with - compared to musl upstream which is committed to > maintain ABI between releases. > > Though, we'll probably also file portability bugs against those apps > that rely on this. 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. 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. 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.