Representative line: to be and not to be



  • Back in 2002, I worked as a sysadmin in a small software shop. They let me do some small projects in VB3, and when I was looking for a job in 2007 they already knew me so they hired me pretty much immediately, to work on the new version of the same software, this time written in C#. One of my responsibilities was to make sure the old VB3 program still worked with some minor changes, until they can roll out the new version. This was not as bad as it seems - it was much, much worse. There were many WTFs, and this is one of my favourite discoveries.

    The program had something to do with insurance, and lots of calculations were made in it, in fact there were thousands for a standard plan. At some point I need to find what the parameters to a function called CalcPPP were, because one of them was slightly off. This function was only called by the monolithic CalcMainPPP, which prepared the parameters and called it. I only actually looked into this 500-line function after talking to every developer who had ever worked on the product, none of whom could remember how CalcMainPPP actually worked.

    Function CalcMainPPP(ByVal fp As Boolean, ....)
        ' (snip ~100-200 lines of code, where fp is used and checked many times)
        If fp Then
            ' (snip ~70 lines of code, where fp is used and checked many times)
            If Not fp Then
                ' (snip ~100 lines of code)
                CalcMainPPP = CalcPPP(...)
            End If
        End If
        ' (snip ~100-200 lines of code)
    End Function
    

    Nobody, of course, knew what fp stood for, or what the value meant. I went line by line trying to find where fp is changed from True to False, but apparently it never did. Somehow fp and Not fp were both triggered by the same value. Not only that, CalcPPP was one of the most important functions in the entire program, and without it it couldn't do any calculations whatsoever - so this had to be possible.

    After a few days of excavating in the pits of never-before-seen VB3 spaghetti, I found this:

    CalcMainPPP(2, ...)


  • VB3 in 2002? I remember using VB6 in 98 or 99.



  • @Speakerphone Dude said:

    VB3 in 2002? I remember using VB6 in 98 or 99.
    Version numbers are seldom in chronological order.  Heck, Windows 7 came after Windows 2000.



  • @configurator said:

    Somehow fp and Not fp were both triggered by the same value.

    Cue my favorite catch-all explanation from every Microsoft KB article on every Microsoft WTF ever: this behavior is by design.

    The logical operators (And, Or, Not) have worked bitwise on every version of the language since MS BASIC 5 and possibly earlier. None of those languages has ever had a dedicated Boolean type, either; they treat logical values as integers instead. And this is exactly why the conventional representations for False and True in the MS BASIC world are zero and minus one: in signed twos-complement binary arithmetic, which is what BASIC uses for integers, -1 has all bits set and is therefore equal to Not 0.

    Whether or not the person who coded that horror function actually knows this, though? Hard to say.

     



  • @da Doctah said:

    @Speakerphone Dude said:

    VB3 in 2002? I remember using VB6 in 98 or 99.
    Version numbers are seldom in chronological order.  Heck, Windows 7 came after Windows 2000.

    I remember using VB3 a lot earlier, and IIRC it was only with VB5 that VB was actually compiled.



  • @configurator said:

    Somehow fp and Not fp were both triggered by the same value.
    Congratulations: you've just invented the Infinite Improbability Drive.

     



  • He was doing quantum computing before it was popular!



  • @flabdablet said:

    And this is exactly why the conventional representations for False and True in the MS BASIC world are zero and minus one: in signed twos-complement binary arithmetic, which is what BASIC uses for integers, -1 has all bits set and is therefore equal to Not 0.

    Actually, this just reminded me I think I was a bit wrong about the punchline - it was CalcMainPPP(1, ...), and Not 1 is (obviously) -2...



  • @flabdablet said:

    And this is exactly why the conventional representations for False and True in the MS BASIC world are zero and minus one: in signed twos-complement binary arithmetic, which is what BASIC uses for integers, -1 has all bits set and is therefore equal to Not 0.
     

    I wondered why that was.

    I'm used to the Unix-style "true is zero and false is non-zero" because there are a multitude of reasons why something failed (hence the non-zero return code) but only one instance where it succeeded. It made sense to me to have those kinda values.



  • @configurator said:

    After a few days of excavating in the pits of never-before-seen VB3 spaghetti, I found this:

    CalcMainPPP(2, ...)

     

    ...Surely you mean that you ran an appropriate Find In Files command for "CalcMainPPP" in all the source files and found it in seconds, rather than days?

     



  • @configurator said:

    Actually, this just reminded me I think I was a bit wrong about the punchline - it was CalcMainPPP(1, ...), and Not 1 is (obviously) -2...

    It's the same in VB.NET...



  • @dhromed said:

    ...Surely you mean that you ran an appropriate Find In Files command for "CalcMainPPP" in all the source files and found it in seconds, rather than days?
     

    It just took several days to merge all the files into one big data data file using tt at prompt #1 enter enter golf option i love this program greatest got betterleave them in our dust grepplers wargle geehhghghghghhghhghg



  • @dhromed said:

    ...Surely you mean that you ran an appropriate Find In Files command for "CalcMainPPP" in all the source files and found it in seconds, rather than days?

    This is very much simplified, of course. In the end, the parameter that got put there had the value 1 instead of True.



  • All the MS BASIC languages have comparison operators (< > <> =) that yield either 0 or -1. So provided the only things you ever apply logical operators to are the results of comparisons, you will get correct results regardless of whether those operators work bitwise or not.

    Bear in mind that this is is a design decision made back in the middle Cambrian (before the great x86tinction) when 64K was a lot of RAM to have in a personal computer, and the fact that microprocessors all had native bitwise logic instructions was actually worth thinking about. Having bitwise operators in a high level language is occasionally useful, and the best tradeoff between concision and readability was not where we have the luxury of allowing it to be today. Most of us, if we noticed it at all, thought the fact that MS BASIC let you use And, Or and Not to manipulate bitmasks as well as to build test conditions was kind of cool, and rated the use of -1 for canonical True as a Clever Trick.

    Clever Tricks are fun to use, and it takes some people a lot of lessons in watching them cause more grief and expense than they save to give them up.

     


Log in to reply