4 ms·

That reminds me of when I got a bug report that my C library crashed on SPARC. It was a library related to audio. I said, that's ok let's try to fix it, but i

That reminds me of when I got a bug report that my C library crashed on SPARC. It was a library related to audio. I said, that's ok let's try to fix it, but it seems this requires changing our memory layout which is a big thing to ask since the memory layout is based on the data format we are processing, and I can't reproduce the error because it doesn't crash on any machine I have access to. Are you really using this library on SPARC? And it turns out no, he was just adamant about portability and testing lots of libraries on various architectures. I said, do you have a use case for doing audio on SPARC, is _anyone_ doing audio on SPARC? And he wouldn't let it go even though he couldn't cite a single reason I should care about this platform so I had to just ignore it. He eventually suggested a fix but it was a huge change to the code that wasn't backwards compatible, so I had to reject. I'm sad my library won't work on SPARC.. but.. Portability is a virtuous goal but one has to be pragmatic.

Filligree 8y ago
However, if your program crashed on SPARC then it probably contains undefined behaviour. And if that's the case, then at any time a new GCC release might make it fail.
- radarsat1 8y ago
  Indeed. And I'll fix it as soon as that happens ;) But I can't really fix something I can't reproduce. At least, I draw the line there if it requires massive changes. For example, how am I to know that my fixes won't introduce further undetectable problems? That last thing you want as a maintainer is to rely on one single user who reported a problem to help you out with testing and maintaining the fix forever..
spc476 8y ago
I still have to deal with SPARC at work, and the only major differences between it and x86, with respect to C, are: * It's big-endian * unaligned reads will fail (if you have to read packed structures, you need to declare the structure as packed and the compiler will generate code to do unaligned reads) Given you mention "memory layout" it seems you are expecting possibly a little-endian system, and maybe unaligned reads.
- radarsat1 8y ago
  Yes, it was to do with unaligned reads. Blows my mind that that crashes the program on some architecture, but until I'm personally using such an architecture or have an easy test rig for it, I have a hard time caring. (I did try on qemu.. doesn't crash.)

Filligree 8y ago

However, if your program crashed on SPARC then it probably contains undefined behaviour. And if that's the case, then at any time a new GCC release might make it fail.

radarsat1 8y ago
Indeed. And I'll fix it as soon as that happens ;) But I can't really fix something I can't reproduce. At least, I draw the line there if it requires massive changes. For example, how am I to know that my fixes won't introduce further undetectable problems? That last thing you want as a maintainer is to rely on one single user who reported a problem to help you out with testing and maintaining the fix forever..

spc476 8y ago

I still have to deal with SPARC at work, and the only major differences between it and x86, with respect to C, are: * It's big-endian * unaligned reads will fail (if you have to read packed structures, you need to declare the structure as packed and the compiler will generate code to do unaligned reads) Given you mention "memory layout" it seems you are expecting possibly a little-endian system, and maybe unaligned reads.

radarsat1 8y ago
Yes, it was to do with unaligned reads. Blows my mind that that crashes the program on some architecture, but until I'm personally using such an architecture or have an easy test rig for it, I have a hard time caring. (I did try on qemu.. doesn't crash.)