Hope I'm not being to stupid here, but I think there's a portability problem with these functions for anything other than byte oriented data because the endian mode in memory is system dependent whereas for files it will depend on the format specified for the file.
Personally, I don't see a problem here. hPutBuf is defined to write a sequence of bytes to a file, and that's exactly what it does: the interpretation of the sequence of bytes is an orthogonal issue. We should certainly also provide ways to write binary data into a file in a portable way... but IMO that should be part of the Binary library which is currently being worked on.
I would like to suggest additional functions.. hPutBuf<N><E> hGetBuf<N><E> where N=16,32,64 and E=L(ittle),B(ig)
The endian mode refers to the file format and necessary conversion to/from the systems "native" mode is done automatically.
It would be nice to have similar functions for reading and writing individual Words too.
There would be a similar problem with hPutArray and hGetArray if they were used for reading writing arrays of words other than Word8 (using castIOUArray perhaps?)
hPutArray and hGetArray do indeed generate non-portable files, and they should be documented as such. Cheers, SImon