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

[jnqnfe at gmail.com]

On Wed, 2018-07-04 at 11:46 +0300, Tanu Kaskinen wrote:
> On Mon, 2018-07-02 at 17:58 +0100, jnqnfe at gmail.com wrote:
> > 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:
> > > > 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 ...
> 
> Patch 4 changes the callback signatures.

Right, but only in the mainloop api vtable, which user's only read
values from, so I wasn't expecting that to be an issue.

I've tested with gcc with `-Wall`, hacking the change into my locally
installed headers and recompiling a test program which utilises
`time_new`. No warnings resulted.