Recently, I’ve had the (mis)fortune to work on a driver for an unnamed hardware device. The device in question was little endian, and as long as the driver was working on Intel platforms (which are little endian), all was well and good with the world. Except for the usual hardware woes[1][2][3], which will be elaborated upon in a separate entry. The day came when we had to port the driver to PowerPC, which is a much nicer architecture in general. Alas, it is also big endian. This is where the fun starts.
– The endianness support was added in such a manner, that whenever looking at any given value, you never knew if it was little endian or big endian. No consistency whatsoever. This makes the code, of course, impossible to maintain.
– In some cases, the conversion depended on the platform the code was running on. In other cases, the conversion needed to be absolute (always convert from little endian to big endian, and vice versa). The same macros (hideously named HOST_TO_FOOCARD_XX, FOOCARD_TO_HOST_XX, etc, rather than the sensible Linux cpu_to_le_xx) were used in both cases. This is, of course, buggy.
– This device had registers for programmers to frob. Some of the bits in those registers were reserved (must never be changed by the programmer), and some of them were supposed to be turned on or off occasionally. An unnamed programmer created masks for those bits:
#define MASK_FOR_SOME_BIT 0x80000000
And then used this mask in her code:
U32 val = readl(card->someoffset); /* read value from register at offset */ val |= MASK_FOR_SOME_BIT; writel(val, card->someoffset); /* write it back */
Can you spot the bug here? think of the endianness of the value read from the card, and the endianness of the mask, and which bit actually gets changed, and enlightenment shall come.
[1] Insufficient documentation.
[2] Wrong documentation.
[3] No way to figure out why the device doesn’t like what we write to it, except for the documentation. See [1] and [2].
Muli Ben-Yehuda's journal 
Ugh. 😦
Bytesex problems are the worst. Especially since an even number of bugs is undetectable — and it always turns out that if it’s an even or odd number of bugs depends on codepaths…
Comment by moshez — December 20, 2003 @ 3:06 AM |
recently, some programmers we are collaborating with said in a phone conference “oh, our code is almost done, we just need to make it endian clean. That shouldn’t be too hard”. Hysterical laughter broke out at our end of the line (after we put the phone on mute, of course).
Say, how do you respond so quickly to posts? what do you use for RSS aggregration?
Comment by mulix — December 20, 2003 @ 3:21 AM |
centericq
It’s decent enough, supports ICQ, IRC, AIM, LJ (which means I don’t have to add manually RSS feeds for my friends) and raw RSS.
Comment by moshez — December 20, 2003 @ 4:26 AM
yup, I’ve installed it and it’s fairly cute. Thanks!
Comment by mulix — December 20, 2003 @ 1:19 PM
Oh, i found it 🙂
Comment by ideawerkz — December 20, 2003 @ 6:15 PM
It’s surprising how many people don’t know where the terms ‘big endian’ and ‘little endian’ come from.
Comment by 77azkkr — December 20, 2003 @ 7:09 AM |
Indeed.
When I teach network programming, I always make a point of explaining the origin. Because you do have to be careful not to bruise your thumb.
Comment by moshez — December 20, 2003 @ 7:19 AM |
When I was taking Machine Language and Assembly as a sophomore, someone in the class asked where those terms came from and the instructor didn’t know. When I explained, everyone in the class laughed !!!
It’s like Bridget Fonda’s line in that movie about the giant Alligator. The sheriff wonders out loud how something could happen and when she instantly gives the answer, he goes, “how do you know that ?”
Her response… “they conceal information like that in books !!”
LOL
Comment by 77azkkr — December 20, 2003 @ 7:31 AM