In my interpretation that means that only one function is not behaving properly, namely the one turning an id3v2-tag into a Perl hash which is a good thing. Still I am now condemned to wait for my login for Sourceforge's compile farm to try this beast under several other operating systems, including MacOSX, FreeBSD and different flavours of Sparcs.

I can already log into the OS-switch menu, but my account doesn't yet seem to have propagated to the actual machines behind that. I can only hope that they have Perl and vim installed.

Also, the above tests were made using gcc instead of Sun's legacy compiler. The available compilers is yet another uncertainty.

Yet, I have the hope that once my module works fine under two operating systems, changes should increase that it also works under the third and fourth and so on.

How do other people ensure interoperability for various OSs? Do they have accounts for different machines or is it programmer's experience that makes the thing work on most platforms?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Please Log In to Continue

How do other people ensure interoperability for various OSs? Do they have accounts for different machines or is it programmer's experience that makes the thing work on most platforms?

A bit of both. There's no substitute for testing on different machines (and with different compilers), but you'll have a lot less problems if the first place once you become experienced in what is and isn't portable

Part of the problem with portability is that the most common platform (x86) is one of the most forgiving (littl

For example, your module is also failing its tests on PPC linux, so I'd suspect that it's an endian-ness bug somewhere (your code, or the included library), as both sparc and PPC are big endian.

Seems more and more reasonable to me to suspect byte order. Just browsed through mplib and did in fact find a lot of bitshift operations in mp_get_id3v2_tag (the id3v2-reading was the stuff that failed in the tests) but not in the corresponding mp_get_id3v1_tag.

parrot is compiled with -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return -Winline -W -Wno-unused -Wsign-compare -Wformat-nonliteral -Wformat-security -Wpacked -Wpadded -Wdisabled-optimization on gcc 3.2. Some of those are specific to various recent versions of gcc - take a look at parrot's config/auto/gcc.pl for how it chooses its bondage preferences based on gcc version. How