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.
