April Amy

Click through for all the pictorial goodness.

Funny Bug

For lack of anything else to write about, here’s an amusing bug that I found the other day. Consider the following fragment of C++ code.

if (ProbeThing(address),true) {

I was hitting HandleDuplicateThing when I thought I shouldn’t be. I went into the debugger and saw that, sure enough, ProbeThing was getting the correct/expected null value, but somehow when I got back into the caller it was still going down the wrong path. The problem turned out to be the placement of a right paren. What I meant to call was this:

if (ProbeThing(address,true)) {

See the difference? It turns out that the second argument to ProbeThing was optional, so the compiler didn’t see anything wrong with the incorrect call, and just applied the never-sufficiently-damned comma operator which would return its right half (true) as the value of the expression. Optional arguments are handy, but combined with the comma operator they can be very dangerous. So my question is this: who ever thought allowing comma as an operator was a good idea? I’ve seen it cause plenty of problems, but the only case it ever seems to be useful is in for-loop headers. If that’s the only use for them, the comma operator is an unnecessary hack. Function argument lists already use the comma as a syntactic element instead of as an operator, and for-loop headers could do the same thing to satisfy existing usage without requiring the generally-dangerous comma operator. I think I’m going to make a “no comma” sign and post it in my cube.

Spam Enablers

For a long time, I’ve been making up email addresses every time I need one e.g. to shop online or post a comment on someone else’s blog. As the owner of the entire domain I’ve set things up so anything not recognized as belonging some other specific mailbox is dropped into mine, so it’s almost the same as just using my real address everywhere except that this approach lets me track who’s selling my address or allowing it to be harvested by spambots. Somewhat surprisingly, this has generally yielded few results. Most of the spam I get does not go to addresses I’ve actually used, but is instead addressed to “generic” accounts like sales@atyp.us or info@atyp.us (both of which are automatically thrown away).

Recently, though, I’ve been getting quite a bit of spam, and phishing attacks too, from one of these “bait” addresses. Somehow it’s not a surprise that the offender is libertarian/laissez-faire blog site QandO because spamming is exactly the kind of “free market” cost-shifting that their ideology makes inevitable. Most blogs that are harvested frequently notice the traffic and implement countermeasures such as obfuscating email addresses, but that requires a modicum of technical skill. Since it’s not in full-of-ads QandO’s interest to protect their visitors from phishing, nobody bothers … and that assumes QandO isn’t deliberately making life easy for spammers and phishers.

The moral of the story is: if you leave comments at QandO, don’t use your real email address.

Rewriting Code

My last technical article was about debugging, because that’s what I had been doing a lot at the time. Now I’m going to discuss rewriting code, for similar reasons. It’s no secret that the code for any multi-person project is likely to represent different levels of quality. Regardless of whether the median quality is stellar or abysmal, the road to improvement often means picking one of the components at the bottom and either eliminating the need for it or overhauling it until its quality is at or near the top. Because a chain is only as strong as its weakest link, even a few iterations of this process can yield substantial improvements in overall product quality. Much of the advice I’ll give applies also to writing new code, but the emphasis is a little different and plenty of books have already been written on that topic so I’ll focus on the areas that are of particular interest when rewriting old code.