By bnitz on Dec 05, 2008
A few days ago I was reminded of one of the differences between Solaris and GNU/Linux which caused a few headaches for Sun's desktop team back in the days of GNOME 1.2. The problem is that while you can printf("%s",NULL); in most Linux distributions, doing the same in Solaris caused the executable to exit and generate a core. There were some debates about the correctness of each approach. Should the program crash to tell the developer that he shouldn't be trying to print a NULL string (the Solaris behavior) or should the program continue happily along printing a NULL pointer? I can see some advantages in both approaches I suspect this and other "Linuxisms" will end up in OpenSolaris simply because they make it more convenient for average coders to throw together a quick and dirty program or for someone to compile and run the thousands of source packages out there which (perhaps unknowingly) take advantage of this Linuxism.
But thinking about this reminded me of a similar "bug/feature" in my very first computer, the Commodore 64 back in 1982 when 64K seemed an unbelievably excessive amount of memory for a computer which cost only $595. The built in blitter and 4 channel 16 bit synthesizer made it a really fun computer for me to write simulations and sound generator programs for my father's physical science class. If you look closely at many of the programs which were published for Compute! and other magazines of the time, you might notice something strange. When a character was read from the user (e.g. via get (a$) ), the asc(a$) function would convert the character to its numeric ASCII value. But in the code you would usually see something like this:
n = asc(a$+chr$(0))
What is going on here? There was a bug/feature in Commodore 64 BASIC V2 which raised an "Illegal quantity error." whenever a null string was passed to the asc() function. The Commodore 64's 6510 processor had the unusual ability of being able to peek the ROM and write to shadow RAM which shared the same address space and then disable ROM so that BASIC was running from RAM. This allowed modifications to the BASIC interpreter. Jim Butterfield, a Commodore expert and author once demonstrated a one byte poke which fixed this asc("") bug. Ever since I learned of this simple fix, I wondered why so many BASIC's had this same one byte bug. The Commodore 64, Vic-20, Atari, Amiga, and at least some versions of the Apple and IBM PC Basic's shared this same bug! What was going on? Well, as it happens, a little company known as Microsoft wrote versions of BASIC for nearly all 8 bit computers of the 1980s and 1990s. Was this one byte bug overlooked by Microsoft and propagated to all Microsoft inspired codebases or were Microsoft's developers following the same purist philosophy as Solaris developers who assert that "good coders shouldn't pass NULL into string functions?" Either way, when such a company grows to what it has now become, it can decide that this one byte bug is actually a feature.