On Wed, 16 Nov 2016 08:55:47 +0100 picca <pi...@synchrotron-soleil.fr> wrote: > Source: zeromq3 > Severity: important > > Dear Maintainer, > > It seems that zeromq 4.2.0 brakes the tango package. > this is why I fill an important bug in orer to block migration testing. > > You can have a look here > > http://lists.zeromq.org/pipermail/zeromq-dev/2016-November/031093.html > > thanks > > Fred
Hi Fred, This is very unfortunate, but as explained on the mailing list, this behaviour was an unintentional internal side effect. I didn't quite realise it was there, and so most other devs. In general we do our best to keep track of our public API/ABI, and lately a large effort has gone into making the management of these better. Recently for example an ABI-breaking bugfix was fixed up to be ABI-compatible. But when it comes to internal, undocumented implementation details I hope you realise it's much, much harder. I understand this is not much consolation when it means some work for application/clients maintainers/developers, and I am sorry for the trouble it could cause, but I do think the right thing in this specific case is to avoid relying on what essentially is undefined behaviour, if possible. How much work would it be to change tango to avoid relying on aligned internal recv buffers? The only alternative would be for the maintainer to revert all or part of this pull request and any subsequent fixes: https://github.com/zeromq/libzmq/pull/1466 But I would recommend against it. Of course a pull request that would restore the aligned side effect while maintaining the new decoder implementation with one less memcopy would be very welcome! Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
