[pulseaudio-discuss] [patches] constification round #4 (pa_mainloop_api)

[jnqnfe at gmail.com]

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 ...