As I write, I am still warming up after a very unsuccessful attempt to get to London by train. An hour and a half waiting on a station platform gives plenty of time for thought but my fingers were soon too numb to use my PDA.
In a break from tradition, I am going to name and shame someone responsible for a bug that I recently was involved in fixing. This was one of mine and was interesting because it was rather subtle. It was in some VB6 code that I wrote the other day and was of the form
If Len(txtSomething) And Len(txtSomethingElse) Then
cmdOK.Enable = True
cmdOK.Enable = False
So, the idea was that a button is only enabled if there is text in both fields. I am a big fan of not letting people make errors in the first place if possible. I had thought (correctly) that len(whatever) would give 0 (false) or something else (true). The code worked most of the time. It took me a second or two to work out why. Compilers use a lot of state machines. In this case, the state that the parser was in when it got to this code was that it was expecting a boolean. What I had given it was a pair of integers. It would have interpreted one as a case for coercing the type and handling the integer (the result of the len function) as a boolean. Was there any way of making “integer and integer” into a boolean? Why yes, there was. VB doesn’t make a distinction betweens logical and boolean And. They use the same keyword unlike C which uses && and & respectively. Now,maybe this was a good decision and maybe it wasn’t but it was one that I should have remembered. As written, the code was ambiguous and the parser went for the simpler option. 12 & 8 == 8 is non-zero so the control was enabled. 8 & 4 == 0 so it was disabled. A less ambigous bit of coding would have been
cmdOK.Enable = len(txtSomething) * len(txtSomethingElse)
but I couldn’t bring myself to write such unintuitive code and a multiplication for a boolean operation seems wasteful although it would have made no actual difference in this case. The best coding would have been
cmdOK.Enable = (len(txtSomething)=0) And (len(txtSomethingElse)=0)
As for threats, it seems that that SRIZBI is back on the air. The bot and the bot master had a trick up their sleeves that the security community had not expected. If the bot is unable to contact its command and control channel, it generates a url mathematically and refers to it for instructions. The bot masters had the URL ready and most of the botnet was picked up again on schedule. I have to applaud our Russian friends for that. Fortunately, it is relatively simple to simulate the loss of a command and control system in the lab so we can anticipate where they will go to next time. I still think that a peer to peer system like Storm used is the way to go in the long term. Oh, and a big hello to my readers at the Washington Post. You heard it here first.
In other news, Apple are now recommending Mac users to install some kind of anti-virus product. Previously, their recommendation was that the threat was insufficient to warrant the potential downside of having an AV solution. The world is getting more dangerous, folks.
Oh, and there seems to be a lot of buzz about an enterprise information security package that contains rootkit like technology in a Chinese written module. Some of the AV vendors are detecting it as malicious. Well, it could be but it is hard to know. Increasingly we see security tools that resemble malware more closely as they try to hide from each other. The malware wants to disable the AV product and the AV product wants to disable the malware. It sounds like the new rootkit uses function redirection so the old Rootkit Unhooker tool should detect it.
Well, back to coding. You have to love feature creep.
Mark Long. Digital Looking Glass