Dr. Dobb's Journal April 2000
This month's column is a series of disjointed ramblings loosely connected by contrived segues. I have no better excuse than the deadline is upon me and I am far away from the comforts and conveniences of home, office, and reference material. Don't expect to read much about programming in C and C++ this month. They gave me a tough choice: I could stay home and write a meaningful column chock full of code, technical lore, and wisdom to raise the knowledge bar of my devoted readers; or I could fly to San Francisco to carouse and debauch at the annual DDJ alumni party and slap together something trivial and meaningless on the road to fill this space. Hard decision to make, but I made it. That's why I get the big money.
Speaking of deadlines: 3-2-1-fizzle is what happened at New Year's stroke of midnight when 1999 stepped out and 2000 stepped in. The fizzle was the Y2K computer bug disaster that didn't happen. Many will argue that the billions spent to prevent the dreaded disaster worked and prevented the disaster. But how can you tell? They have to make that argument to justify having spent all that money.
Remember those newspaper cartoons that depicted the old year as Father Time with a long beard and a scythe and the new year as a newborn babe? Whatever happened to them? I guess a three-digit flipover (millennium change, if you will) needs more significant icons than the traditional death and birth metaphor provides. But all we got this year was the occasional sinister beetle representing the insidious "Y2K Computer Bug." That image was intended to strike fear into our hearts and get us to spend money on useless stuff -- software, books, dry goods, bottled water. Cartoons of old men and babies aren't scary enough to frighten us out of our hard-earned dough. But creepy-crawly things -- that's another story. Shudder. They didn't go far enough, though. There should have been a bearded old bug and a diapered new bug. It's hard to turn loose of tradition.
By the way, if you're interested in any of those Y2K prevention self-help books, stop by any mega bookstore and check the bargain racks. Gasoline-powered generators and bottled water are showing up in yard sales in plentiful numbers, too.
Speaking of water: I recently got e-mail from a fellow who is unwilling to let go of the Y2K hysteria and move on. He listed some as-yet uncovered Y2K bugs that are not timed to bite exactly at the stroke of midnight, but that lie in wait for their appointed day and hour. This message got me thinking about my own small contribution to the problem -- programs I wrote in the dark ages that rely on two-digit years. One notable memory is a utility billing system I worked on for a medium-sized southern city, the capitol of its state. (I won't identify it for reasons that shall become obvious.) The city administers billing for water and sewer, and the company I worked for wrote the billing system under contract to the city. The year was 1970. I distinctly remember realizing that people whose accounts were current would be treated as being something like 100 years in arrears when the century turned over. That's enough to get your water turned off, I bet. The bug won't take effect until the first billing cycle after January 1. But what program would last 30 years? I wonder.
The really memorable part of that assignment had nothing to do with future Y2K bugs. It was my first and only journey into cracking in a long and otherwise honorable career. As a contract programmer, I was in a Catch 22. I could work on the system only during third shift when the computer was available. The commercial parking lots were closed, so I had to park on the street, which became illegal at an hour in the early morning when I was still working. If I took time off the computer to move the car, some other eager programmer would grab it. After about the third parking ticket, I took some extreme measures. I observed that the city police's moving and parking violation tickets were processed at the same data center in city hall that we used for testing. A forage through the keypunch operator's procedures and the computer operator's runbooks revealed how the system worked. The source code was in Cobol, which they maintained on punch cards. I located the programs, modified and recompiled them, and removed the modifications from the source code. Those modifications removed all traces of violations that had my license plate number. The crack worked. There was no such thing as computer crime on the books in those days, so I'm reasonably sure that I am in the clear by telling this story. Besides, the statute of limitations must have expired by now (assuming the system that tracks crime dates is Y2K compliant). Even so, I won't say which city it was.
Speaking of locales: I have a new area code. Central Florida, which includes Orlando and the Space Coast, where I live, has outgrown the reaches of a single area code, so the phone company had to break us up. Orlando gets to keep 407. We on the space coast get the new area code 321, which someone thought was cute because if signifies the least significant digits of a launch countdown. Area code 321 should be easy enough to remember, but I'll miss trusty old area code 407. You see, the venerable IBM 407 was the first computing device I programmed as a young lad, and the 407 area code represented a fond link to a happy past. The IBM 407 was not a computer as we understand them -- IBM called it an "electronic tabulating machine" -- because it did not use the stored-program concept. The 407 read punched cards and printed paper reports, and we programmed it by plugging wires into large removable control panels. When I graduated to programming a real stored-program computer, the IBM 650, its printer was a 407 that used a special control panel that had a data cable coming from the computer. I still have the operator's manual.
Speaking of area codes: It used to be that area codes all had 0 or 1 as their middle digit. If you doubt that, look at any old phone book from a few years ago. That fact figured significantly in an embedded-system program I wrote for a project that my brother, Fred, and I designed. To understand this system you have to remember when phones and all the hardware associated with them were analog rather than digital. This device attached to a PBX and had one single function -- to log incoming and outgoing calls made through that PBX. Fred designed a bunch of specialized hardware with a 2-MHz Intel 8080 as the brain, and I wrote the firmware in 8080 assembly language. Companies used this device and its paper log to monitor how their employees were using the phones. One of the firmware's algorithms parsed phone numbers while they were being dialed to see if the number was among the kinds of numbers the company wanted to log onto the TTY printer. Dialing and numbering conventions varied around the country and among PBXs, and the device had to select from a user-defined table of dialing options. Part of that algorithm was the format of the area code, which had to be n0n or n1n. We delivered the product with no documentation and with a binary EPROM image that included tons of hand-coded and hand-installed patches. Resources for reassembling 8080 code were not readily available in 1974, thus the hand work. They sold and installed a bunch of them and, as far as I know, never had to mess with the firmware. Then one day I learned that some new area codes were being issued with digits other than 0 and 1 in the middle. I wondered if any of those devices were still in use. If so, they were failing right and left. That was way before Y2K, too. I can only imagine the middle digits flipped my way by the programmer who had to fix that mess.
Speaking of the phone company and breaking up: Where does the U.S. Government come off breaking up businesses like they did with AT&T and like they are trying to do with Microsoft? How can any organization that changes management every two years, produces nothing but paper that nobody reads, exists mainly to perpetuate itself, and runs up a $3 trillion debt doing it pretend to know anything whatsoever about how business ought to operate? Just asking, you understand.
Speaking of phones: My trip to California included the usual plane change in Atlanta at a particularly busy time. I sat in the lounge waiting to board my connecting flight and watched the people go by. About one out of twenty who passed were talking on cell phones as they hurried by. Surely others had cell phones they weren't using at the moment, so it seems that a significant sample of the population -- at least those who travel by air -- have cell phones. That's not news. Cell phones are ubiquitous. But then I noticed something else -- a long row of neglected pay phones not being used. It used to be you couldn't find an available pay phone in a busy airport in a large city during prime time; now it's hard to find one being used. One of the peripheral advantages of progress, I suppose.
Speaking of progress: I have a growing list of annoying buzz phrases that creep into the national vocabulary while no one is looking (or listening). I blame the government because politicians say these things all the time, and they say them each time as if they had just coined a really clever phrase. "Raise the bar," "at the end of the day," "a real wakeup call," "less is more," "the bottom line," "the good news is" (usually followed by, "the bad news is"), and so on. It's contagious. One person turns a tricky phrase and the next thing you know, everybody is saying it. John Dean repeatedly said, "at this point in time" during his testimony in the Watergate hearings in the 1970s and influenced generations of politicians and bureaucrats to follow. The worst example was "If it looks like a duck...," which, thankfully, quickly faded from usage probably because it took too long to recite and everybody already knew the punch line anyway. (E-mail me if you've never heard it.) I'd like to propose my own addition to this list, a buzz phrase that sums up what will probably become our government's most enduring legacy for the final years of the 20th century to the people of this planet, and that is: "Character doesn't count."
Speaking of characters: Lest this column too closely resemble "Swaine's Flames," I guess I'd better say something about C and C++. I will, therefore, address the use of the underscore character (Ha! You thought I was calling Michael a character, didn't you?) in program identifiers.
The C++ Standard says that identifiers beginning with an underscore character followed by an uppercase character or with double underscore characters anywhere in the identifier are reserved for the implementation, meaning the compiler's version of the Standard C++ Library. The reason for this reservation is to prevent users of the compiler from inadvertently putting identifiers in their own code that collide with those of the Standard C++ Library. There is, however, no requirement that the compiler issue a diagnostic error or warning message if you break this rule, because then the compiler would need to recognize the difference between identifiers declared for the implementation and those that the user declares; and that, apparently, is too hard.
So you can break the rule and there is no error or warning. In which case, in my opinion, the rule is not a rule at all; it is a guideline that you can choose to ignore if you wish, understanding and accepting the ramifications of such a cavalier attitude. Champions of the rule are unable to see this. They insist that since the Standard document says so, it must be a rule and everyone must observe it. Those who do not are foolhardy programmers who must bear the consequences, which occur only if breaking the rule breaks something else.
The rule attempts to protect the Standard C++ Library from violation, but there is no corresponding rule to protect developers of other libraries from having their identifiers trampled upon. Except that there is. Since there is no diagnostic issued, and since contemporary library developers will make full use of the C++ namespace, they too can use the reserved underscore identifier format within their namespaces and expect the same protection from users that the Standard C++ Library developers expect. Which is none, really.
Inasmuch as every identifier in the Standard C++ Library is supposed to be declared within the std namespace and all identifiers in other libraries are expected to similarly shroud their identifiers in a namespace, it would seem that there is no reason for this rule. But there is. The #define mechanism that C++ inherits from C does not respect namespaces. The preprocessor invokes macro replacements blindly before the compiler gets hold of the code. The purpose of the underscore rule, therefore, is to protect namespace-qualified identifiers from being changed by #define macros. Only it doesn't.
DDJ