Re: [liblo] Bug#721617: pyliblo: FTBFS on sparc: testSendOthers (unit.ServerTestCase) ... Bus error (core dumped)
On Wed, Jun 1, 2016 at 2:48 AM, John Paul Adrian Glaubitz
<glaubitz@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
Reply to: