On Wed, Jun 1, 2016 at 2:48 AM, John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> wrote: > Control: reopen -1 > Control: severity -1 normal > >> Closing because liblo is no longer in sparc, and will not be built again >> there. > > Re-opening because in Debian we don't "fix bugs" by sweeping them under the > carpet. Also, we're currently making sparc64 fit for release and there is > a very active upstream.
That's a good attitude, currently I don't know anyone using sparc64 with liblo nor do I have access to such a machine, so reproducing and testing, and therefore fixing, this bug is not possible for me. So, I look forward to your contribution. >> It appears the problem is that in sparc, you can't just say >> *(datatype*)data. Depending on datatype, 'data' has to be aligned at a >> certain number of bytes from the original block (4 for int, 8 for >> int64): > > Which is absolutely not specific to SPARC. The moment you are recasting > a pointer that way, you are leaving the territory of the C99 specification > which explicitly states that declarations which refer to the same object must > have compatible types, otherwise the behavior is undefined (C99, 6.2.7/2) [1]. It is a good point. If you have some examples where this fails it would be a good contribution to our unit testing. (testlo.c) At the moment no one has actually complained about this bug, and therefore I can only assume it has not actually been encountered and remains an entirely theoretical bug, but I do welcome ideas for how to fix it nonetheless, because compatibility with future architectures is certainly a desirable goal. > The code in question is therefore buggy and has to be fixed anyway as there > is otherwise no guarantee it will work on future architectures or compilers. > > I'll have a look at this issue, it's a common programming mistake. Unfortunately one that seems to be baked into the liblo API, but perhaps there is a way to fix it without sacrificing efficiency, at least on unaffected architectures. If not, perhaps it can be fixed in a future API-breaking version of liblo. Proposals welcome. Steve