use Perl

1) big-endian

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[20] + (buf[21]<<8);
        format->channels = buf[22] + (buf[23]<<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.

2) Solaris

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 .dbx files into the tarball and let the *.t files work on these. But what to do if (at least the special Folders.dbx) is almost always beyond 1meg in size? Surely I can't pollute the CPAN with that much data. It's just not balanced if you consider that Dbx.xs is just 7K in size and Dbx.pm only contains POD and no Perl code by me at all. I guess I'll have to see how far I can trim down the .dbx files with Outlook Express because tests are absolutely necessary for this module.