Yesterday (in a long and wild C-session) I was able to make libdbx run on big-endian machines. Looking back I am quite grateful that I occupied myself with it since I learnt a lot of useful things with respect to making code portable. I noticed that libdbx doesn't use any bitshift operations (except for the byte-swap mmacros that I use for the endian-conversions). As with any binary files, integers are expressed using 2 or 4 bytes. If the file has the same byteorder than your machine one can simply fread() a block into a structure.
This has some useful consequences for me. In my sparetime I've been working on something I call libpcm: reading wav files, creating basic waveforms and playing back all this through OSS. I have a lot of lines going like that:
format->wav_format = buf + (buf<<8);
format->channels = buf + (buf<<8);
That's unefficient and error-prone because both wav files and my machine are little-endian. That means I can just
fread(&header, sizeof(pcm_header), 1, file). For big-endian, I later just need to apply the corresponding macros to the members of the structure.
On with something less pleasant: Don't these things simply belong in the bin?
I was testing Mail::Transport::Dbx on of those scary Solaris machines just to realize that once again I had to work with a broken terminal. Mind you, I never observed such a lack of proper administration on Mac OS X, *BSD or Linux.
Additionally, SUN's compiler wasn't able to understand libdbx's macro definitions. It didn't like variable-length argument lists, nor was it able to properly deal with ##.
After having worked around all this it was incapable of parsing the Perl-headers to link against libperl which put my attempts to fix it to an abrupt end.
I still hope that this was only because the particular Solaris I was working on was seriously screwed up. Surely, ucbcc should be able to compile XS and link it against perl.
So now I have a Perl module that works on machines with the two most common byteorders. I just wasn't able to make it run with Solaris' legacy compiler so people will have to use gcc.
3) designing test-cases
Doing that for Mail::Transport::Dbx is causing a slight headache. It looks pretty straightforward actually: Stuff two or three