I had a minor complaint some time back about the lack of consistency amongst the various windows APIs, they seemed to be written by people who chose one mechanism one day, and another the other day. The reality is that in such a large company as Microsoft, the different groups were consistent amongst themselves, the problem was that they were not consistent amongst each other.
This brings me to the rant du jour. When one finds oneself reading/writing assembly language, the code is platform consistent. For example on x86 the format is: operator parameters,destination. So, mov 0xffffffff, %eax means put the value 0xffffffff into the register eax. On Sparc the parameter and destinations are reversed so mov %l0,0x110011 means put the value 0x110011 into the register l0. It’s quite easy to see one from the other because you are aware of what platform you are on. Sun, for reasons best known to themselves reversed the order of the parameters – probably to make them more like the Solaris ‘native’ format and easier for their developers to follow.
All very fine and well, Sun are entitled to confuse native x86 developers all they want, and besides which, because of the consistency, it is a really easy switch.
My mini bugbear is of course, the bcopy function. It performs a block copy from a source to a destination. It’s part of libc, it’s simple, it’s easy to use, the only problem is that it is in the reverse order from all the string routines (dest, source), memmove (dest, src). If you look up the definition of bcopy it generally asserts that it is implemented in terms of memmove, and if you look at most implementations you find that bcopy just swaps the in and out parameters and then invokes memmove (I believe the exception is sparc, where this is the opposite). This is why bcopy is officially off my list of functions to use. It’s simply the one lone voice of dissent amongst all the consistency that libc affords.
Who made bcopy then?
If it wasn't for carbon-14, I wouldn't date at all