A bug report that came in from a customer a while back:

I found a fully reproducible scenario.  But the results are not the same all the times.

I’m pretty sure those two sentences contradict one another.

Lots has been going on in our lives lately, but I’ll start this post by discussing one that many of you already have heard about.  My company is closing down their Charlotte office in six months.  A few people have been offered relocation to other offices in Massachusetts, Connecticut, and France, but not many.  A lot of people will be let go in two or three months.  And a few of us are fortunate enough to be offered jobs through the entire “transition period.”  I am in that last group, which means that if I stay through the end of March I will get a pretty substantial severance package (if I leave before then, the severance payment is much smaller).  I’m not sure what we will be doing from here, but I’ll try to keep everyone updated.

In more pleasant news, I thought I’d give some updates on Emma’s development.  She has turned into quite a giggler.  There are a few things that consistently trigger this giggling.  First and foremost, holding her in front of a mirror (especially while moving her forward and backward in front of it) will always make her stop crying and start smiling and laughing.  Another way of making her laugh it so simply let her see Punky.  It doesn’t matter what Punky is doing, she can even be sleeping.  When Emma sees her, she starts laughing.

A few days ago I spent most of the morning working from home, and I got to see Emma watch her Baby Galileo DVD.  This was very interesting.  Basically, random stuff comes by while classical music plays, and occasionally they show babies playing, or they’ll have a young kid say a word like “sun” or “moon”.  It reminded me a lot of A Clockwork Orange, when they brainwashed the guy by forcing him to vidie the ultraviolence while they played Ludwig Von.  I’m not sure if Baby Galileo is trying to brainwash viewers or not, but I had a strong urge to assassinate public officials after viewing it.

In other news, Emma learned to make the “d” sound about a week and a half ago.  This means that occasionally she sits there and says “da da da da da da da da!”  I’m trying to teach her that “da da” references me, by responding to her whenever she says the phrase.  I’m not sure how well its working, because she also says “da da da da da da” when she’s looking at Punky.  We’ll see.

As far as locomotive skills, Emma’s still not able to crawl and certainly not walk yet, but she has mastered rolling over.  She’s close to being able to sit up on her own, although she’ll tilt over to one side or the other after a minute or so.  She is also very aware, in that she’ll follow people around the room, and she can figure out where people’s voices are coming from.

I guess that’s enough updates for one post.  Until next time, keep on.. doing whatever it is that you do.. !

Do programmers still need to understand pointers in this day and age?  Is Java a good programming language?  Why is there something as opposed to nothing?

Please do not indulge in heated debate pertaining to any of the above unanswerable philosophical questions.  Instead, just let me show you what can happen when someone has to program in Java without understanding two things about the Java language: 1) all parameters are always passed by value; 2) objects are basically pointers (whose address can only be modified by assignment).  Without this knowledge, you might write code like this1:

            //ABC-defect#123456 - SetChildren update currSel so we need to take bakup of
                //currSel so that after returning we can set it back to original currSel
           TreeNode tmpCurrSel = currSel;
       int result = setChildren(currSel,fullTree,0,tmpLevels);
          if (tmpCurrSel != null)
                currSel=tempCurrentSelection; //ABC-defect#123456

Hint: it does not work as the developer expected it to (and obviously he never tested it after he coded it).

I recently came across a clever way of writing preprocessor macros, and I figured that I would share.

Let’s say that for some reason you need to write a macro: MACRO(X,Y)1.  You want this macro to emulate a function call in every way2.

Example 1: This should work as expected.
if (x > y)
  MACRO(x, y);
do_something();

Example 2: This should not result in a compiler error.
if (x > y)
  MACRO(x, y);
else
  MACRO(y - x, x - y);

Example 3: This should not compile.
do_something();
MACRO(x, y)
do_something();

The naïve way to write the macro is like this:

#define MACRO(X,Y)                       \
cout << "1st arg is:" << (X) << endl;    \
cout << "2nd arg is:" << (Y) << endl;    \
cout << "Sum is:" << ((X)+(Y)) << endl;

This is a very bad solution which fails all three examples, and I shouldn’t need to explain why.

Now, the way I most often see macros written is to enclose them in curly braces, like this:

#define MACRO(X,Y)                         \
{                                          \
  cout << "1st arg is:" << (X) << endl;    \
  cout << "2nd arg is:" << (Y) << endl;    \
  cout << "Sum is:" << ((X)+(Y)) << endl;  \
}

This solves example 1, because the macro is in one statement block.  But example 2 is broken because we put a semicolon after the call to the macro.  This makes the compiler think the semicolon is a statement by itself, which means the else statement doesn’t correspond to any if statement!  And lastly, example 3 compiles OK, even though there is no semicolon, because a code block doesn’t need a semicolon.

The solution is kind of clever, I thought:

#define MACRO(X,Y)                         \
do {                                       \
  cout << "1st arg is:" << (X) << endl;    \
  cout << "2nd arg is:" << (Y) << endl;    \
  cout << "Sum is:" << ((X)+(Y)) << endl;  \
} while (0)

Now you have a single block-level statement, which must be followed by a semicolon.  This behaves as expected and desired in all three examples.  I have noticed this macro pattern before, but I never really thought about why it was written this way.  Mainly because I don’t often write macros to begin with.

I knew it would happen eventually.  I put in some code that broke our software, and it wasn’t discovered until nearly a month later, on the day the final build was scheduled.  This meant that the final build had to be delayed for a few days, which is kind of a big deal because it can affect ship date.  So lots of e-mails were circulated which featured my name—often in a red, boldface font—in various lists of actions.

Posted below is a paraphrased version of the code in question.  I’ve renamed or taken out anything that might refer to our internal codebase, and I’ve simplified a little, but not to the point that I look like a complete idiot for missing this.  The QueryInterface() and Release() stuff might look a little weird if you’re not familiar with COM+.  Or all of this will look weird if you’re not a programmer.  But odds are you’re about to stop reading if you aren’t a programmer.

LIST(IUnknown) listObjs;
Session->GetModifiedObjects(listObjs);

const int nbObjs = listObjs.Size();

if (nbObjs > 0)
{
   ObjectID** listObjIds = new ObjectID*[nbObjs];
   for (int i = 1; i <= nbObjs; i++)
   {
      ObjectID* pObjId = NULL;
     
      IUnknown* pUnknown = listObjs[i];
      IPart* pPart = NULL;
      if (pUnknown != NULL)
      {
        RC = pUnknown->QueryInterface(IID_IPart, (void **) &pPart);
        pUnknown->Release(); pUnknown = NULL;
      }
      if (SUCCEEDED(RC) && pPart != NULL)
      {
        RC = pPart->get_ObjectID(pObjId);
        pPart->Release(); pPart = NULL;
      }
     
      listObjIds[i] = pObjId;
   }
   ...
   //process listObjIds
   ...
   for (int i = 1; i <= nbObjs; i++)
   {
      if (listObjIds[i] != NULL) { delete listObjIds[i];  listObjIds[i] = NULL; }
   }
   delete [] listObjIds;  listObjIds = NULL;
}

For those of you still with me, maybe you already see the problem.  The LIST() macro in our infrastructure behaves pretty similarly to a Vector in Java: it will resize itself dynamically, check array bounds, and automatically free memory when it is destroyed.  However, because this was written long ago by guys with a Fortran background, the items in the list start at 1, whereas a C++ array starts at 0.  Also, it only works with components implementing IUnknown; plain-old-C++ objects must be handled with plain-old-C++ arrays.  In the code above, this meant I could not declare listObjIds as an object of type LIST(ObjectID*).  So I had a LIST(IUnknown) and an array of ObjectID*s, but I treated both as LISTs!  In fact, I have gotten so used to using LISTs in C++ that I completely forgot that listObjIds was an array (I guess a better variable name would have helped too).

The line listObjIds[i] = pObjId; should instead be written listObjIds[i-1] = pObjId;, since i loops from 1 to n, rather than 0 to n-1.  (Note that the line IUnknown* pUnknown = listObjs[i]; is still correct.)  So I was writing beyond the memory allocated to the listObjIds array.  And amazingly, it worked just fine in all my testing.  Most of the time, the next sizeof(void*) bytes on the heap aren’t going to belong to anyone.  But there is a chance that they are used for some other variable, whose value you would be overwriting.  This is especially more likely if memory has become very fragmented.

We run unit tests on all four operating systems we support, but only one operating system (HP-UX) was affected by this.  And since we don’t currently have any customers using that OS, it was a while before anyone looked at the traces very closely.  Unfortunately, it happens that this code was implemented in a listener that is called every single time the user saves.  So when it was discovered, it was something that had to be fixed before the final build.  We could have delivered it as a patch, but some customers are reluctant to deploy patches because that can mean shutting down production for a few hours.  Plus it doesn’t instill confidence to say we shipped broken code.  So delaying the final build for a day or two was the best option.

The worst part of it all is that it happened just before year-end performance reviews.  Doh!

I just got back from my first ever business trip.  My company sent me to Seattle (technically Everett, WA) this week to visit our good friends at Boeing.  You may have heard, they are a little behind schedule.  But I can’t say too much about the business purpose of my trip here.  Fortunately I wasn’t flying solo, there were several others from my company (two others from the Charlotte office).  I was the only developer there; everyone else was support.  In any case, here are a few highlights in convenient bulleted form:

• The area is pretty.  Unless you happen to hate evergreen trees, in which I guess you wouldn’t care for it.  Because there are lots of evergreens.  When you look out the window of the plane, it looks kind of like you are about to land in a Christmas tree farm.

• The Boeing plant is big.  Really big.  The biggest building in the world by volume, as a matter of fact.  If you imagine a garage where you might get your oil changed, with about six garage doors in the building, it’s kind of like that.  Except the garage doors are big enough to hold full-sized airplanes.

• Security is tight there.  Since they couldn’t confirm that I was a US Citizen, I got a temporary badge requiring an escort anywhere other than the conference room.  Including the bathroom.  So I had to act like a five-year-old and ask people to take me to the bathroom.

• I got to visit my friend from the Amazon.  It was nice to catch up with you.

• Due to a layover in Phoenix, I got to see the Grand Canyon from the sky.  I think it was the Grand Canyon anyway.  In any case, it was a large canyon somewhere north-northwest of Phoenix.

• On the flights to Seattle, I got to experience first-class flight for my first time.  I didn’t think it was that great, until I flew coach on the way back.  Then I remembered what coach was like.

• Most of our nation is a barren wasteland.  That’s the impression I get from thirty thousand feet.

• It was my observation that there are no black people in Seattle.  Some quick internet searching seems to support this: only 8.44% of the population in Seattle versus 32.72% of the population in Charlotte.  That’s a pretty big difference.  And in Everett it is only 3.35%.  That was a little weird.

• There is some kind of circular farming that they do in the flat states, where they just don’t use 21.5% of the land in a square plot.  See many examples here.  This isn’t the first time I’ve noticed this but I thought I’d mention it.  I’m not sure how it is cost effective to waste so much of your land, but since there is so much of it done I’m assuming it must be more than 21.5% more efficient for some crops than traditional farming techniques.

• They still like grunge rock in Seattle.  At least the station I was listening to does.  In four half-hour drives (two trips to and from Peter’s house), I think I heard: 4 Nirvana songs, 3 Pearl Jam songs, 4 Foo Fighters songs, 2 Alice In Chains songs.  And then some new stuff like that terrible Finger Eleven song about clubbing.  I really hate that song.

• It didn’t rain all week.  Garrison had the same experience when he visited.  I’m beginning to think that “it always rains in Seattle” is just a myth.

• No signs of Sasquatch.  That also might be a myth.  But if so, then how do beef jerky enthusiasts mess with them?

I guess that’s all I’ve got to share.

As someone who works in an office environment, I run into a lot of people with Dilbert comic strips tacked or taped to various cubicle surfaces.  After deciding that there must be something to Dilbert, I started reading the strips (posted online daily).  After trying for about two months to figure out why people find Dilbert entertaining, I’ve given up.  In fact I’ve come to the simple conclusion that Dilbert is not funny.  At best, it is highly overrated.  I guess if you draw 365.25 strips per year you are bound to hit on something funny sooner or later, but I’m not sitting through crap like this to get there.

you heard me

Sure coming up with a great algorithm can be fun, but programmers only get true freedom to express themselves in their comments.  And it’s always fun when you are fixing a bug and run across a funny or ironic comment that you don’t recall typing but you can tell without a doubt that you were the one that wrote it.  While looking through some code I wrote about a year ago, I ran across these comments and thought I’d share.

long numSubLists = (numPRC + (MAX_SUBLIST_SIZE - 1))/MAX_SUBLIST_SIZE; //this math is right.. work it out if you don't believe me. :)

Assert(numReturned == returnSize); //this could only be false if something is broken hard...

PS: assertions are awesome.  I’ve found nothing else to be better at preventing future programmers (especially myself) from breaking my code.

There is an intricate social interaction that occurs when walking down a long corridor, such as a hallway at an office building, where architecture allows you to see someone from a greater distance than volume levels appropriate for polite conversation would permit conversing.  As a result, when you see someone you know on the other end, you realize that eventually you must acknowledge him with some form of greeting.  But at this distance, you’d have to shout “HELLO!!” across the building to do so, which would make you look rude.  So you continue walking, looking at the floor or wall or something—anything to avoid staring at him for thirty consecutive seconds.

Now it’s on.  You have chosen your destiny for the next half-minute, and it will involve a hallway hello.  Sure, you could duck into a row of cubicles, and pretend that was your intended destination until the person passes.  But what if there are people in those cubicles?  They will be all “what are you doing here?”  Unless you are good at making up answers to such questions on the fly, your best course of action is probably to continue walking down the hallway.

Before you know it, you are at last in speaking range.  At this point you look towards the other party, wait for him to look at you (which he is expected to do!), then say something like “Hey, [passerby’s name]” or “Hey how’re you?”   Next, if you are dealing with a civilized individual, you can expect to hear “Hey, [your name]”, or just simply “Hey.”  Note:  do not tell the other party how you are doing, even if he asks; he is asking merely out of politeness.  Finally, any eye contact is immediately broken until you have passed said person.

Whew, that was close.  But now you’ve successfully executed a hallway hello.  That makes you a real people person.  That’s why they pay you the big bucks.  And doggone-it, people like you.

PS: I was surprised that spellcheck didn’t have a problem with “how’re”

Last Monday marked two years since Stephanie and I got hitched, an event which was well-documented on this site and others.  Those of you who are fans of The Office are no doubt familiar with the Dwight Schrute bobble head.  Well in honor of our second anniversary, my wife had a bobble-head Kip constructed.  You will see the results below, I think it’s pretty cool, although the bobble-head doesn’t have the I-sit-behind-a-computer-all-day physique of yours truly.  But I don’t think I’d want a realistic representation of my waistline sitting on my desk all day anyway.  Other than the eye color, I think it’s pretty spot-on, at least insofar as that is possible on a bobble head.

It’s me.  I’m the bobble-head. Yes!