We already know that Kara’s office has a problem with strings. Kara’s back again, with more string related troubles.

These troubles are a bit worse, once we add in some history. You see, some of their software does machine control. That is to say, it sends commands to some bit of machinery, which then moves or extrudes or does whatever the machine does. Kara wasn’t specific, only granted that this machine was neither large enough or mean enough to kill someone. Minor cuts, burns, scrapes, bruises and damage to the equipment itself is still possible, but nobody will die.

Once upon a time, the bulk of this code was written in C. Then someone wanted a better UI. So that C code got replaced by the perfectly natural solution of… Visual Basic. There’s still some C in there somewhere, hidden behind interops and marshalled calls to native code, but most of the GUI and logic is pure VB.Net. Which brings us to our representative line.

Dim errorMsg As String = somePieceOfHardware.PerformSomeOperation(index).Replace("\r\n", vbCrLf)

As you might gather, someplace deep under the PerformSomeOperation method, commands are sent to the machine, and any errors come back in the form of a string. This string may contain a “\r\n”, which is the typical Windows line-terminator (carriage-return, line-feed), so we’ll Replace the carriage-return/line-feed with vbCrLf which is… a carriage-return/line-feed.

That’s not what ended up with Kara looking into this line, however. Kara was dragged in when the program started crashing, especially when their machine successfully executed PerformSomeOperation without error- because when there was no error, there was no string returned. So Replace was called on a null object, which obviously doesn’t work and raises a NullReferenceException.

Despite Kara’s assurance that this machine can’t kill you, this code can hurt you in far worse ways than mere death.

[Advertisement] Keep the plebs out of prod. Restrict NuGet feed privileges with ProGet. Learn more.