On Thu, 2018-06-28 at 04:08 +0100, jnqnfe at gmail.com wrote: > constification round #4 (pa_mainloop_api) > > 26 patches in total. I attached a zipped copy also. > > The first 19 avoid (client) API change; the final 7 do not and will > have to wait until ready and happy to do an API bump. > > I'm not certain if there's a public API for 3rd-party modules, but if > so then I can anticipate issue being taken with respect to > pa_iochannel_get_mainloop_api() in #14. Unpicking that though would not > be so easy :/ There's no public API for modules. > It's possible for patches #21, #23 and #24 to be bumped down before the > API change of #20, but as things are they are blocked by it and it > would require a temporary hack... #23 and #24 (utils) depend upon > pa_signal_init(), done in #21 which involves changing the underlying > static; this depends upon changing pa_signal_destroy_cb_t (#20), > because of the way pa_signal_free() works (passing that static api ref > to the destroy callback which requires non-const). Getting around this > would require injecting a temporary hack into pa_signal_free() giving > alternate means of obtaining a non-const api pointer - i.e. api > function pointer comparison would be necessary to tell us which > mainloop is in use, to then get what we need using the correct > *_get_api() with api->userdata. We can't change the signatures of publicly declared callback types. That will cause incompatibilities (compiler warnings at least, which is bad enough) in applications. Therefore the only patch that I could apply is the first one. -- Tanu https://liberapay.com/tanuk https://www.patreon.com/tanuk
