On Fri, 2018-06-29 at 16:06 +0300, Tanu Kaskinen wrote: > 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. Ok > > 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. Sure > Therefore the only patch that I could > apply is the first one. But the types aren't changed until #19/26 ...
