[patches] constification round #4 (pa_mainloop_api)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux