One day, one will be zero



  • Currently working on an very old VBA-Excel app, using dozens of undefinded Variables with names like xz, x2, ww, nn and so on. But this one made my day:

    If UCase(vergl) = UCase(richtig) And eins = 0 Then

    ("eins" is the german word for "one")

     



  • @funthomas said:

    Currently working on an very old VBA-Excel app, using dozens of undefinded Variables with names like xz, x2, ww, nn and so on. But this one made my day:

    If UCase(vergl) = UCase(richtig) And eins = 0 Then

    ("eins" is the german word for "one")

     

    Obviously this is to prevent the infamous MathRulesHaveChanged() exception.



  • I assume this is a critical application, the check for memory corruption is valid in such circumstances.



  • @why? said:

    I assume this is a critical application, the check for memory corruption is valid in such circumstances.
     

    But this would be checking the wrong cell, and if eins is really 1 (which we can only hope), then the check should be for eins!=1, since it could be corrupted to any non-unity value.  Furthermore, if this was a check for memory corruption, then there would be no point in checking the other test. This leads me to suspect that eins is instead a badly-named flag for something, which makes this not much of a WTF.



  •  Or someone decided this would be easier than commenting out the code.



  •  TRWTF is...ah, to hell with it...



  • @funthomas said:

    If UCase(vergl) = UCase(richtig) And eins = 0 Then

    Always remember: "einmal ist keinmal" (roughly "once is never"),

    so you'll probably find

        eins=0;

    somewhere else 



  • @Physics Phil said:

    This leads me to suspect that eins is instead a badly-named flag for something, which makes this not much of a WTF.

    You're right, it's used as a flag. However:

    • It has a complete useless and irritating name (even the name "flag" would make more sense...)
    • it uses 0 and 1 instead of false and true (no, "FileNotFound" not needed here)
    • it is completly unneccessary (you cannot see this from the snippet, but it is like that, I've removed it in the meantime) 

    How much of a WTF have you found in your code that you think that this is not much of a WTF?

     



  • @funthomas said:

    You're right, it's used as a flag. However:

    • it uses 0 and 1 instead of false and true (no, "FileNotFound" not needed here)

     QBASIC (old DOS BASIC from Microsoft) used 0 for false and -1 for true.  Also, bitwise and logical operators were combined, which is the reason for -1 = true so that FALSE = NOT(TRUE).  I don't know if Visual Basic has actual booleans (probably does), but if it doesn't then we have 1 = "true", 0 = false, -1 = "it's really true I mean it", and -2 = "file not found".



  • @funthomas said:

    undefinded Variables with names like xz, x2, ww, nn

    funthomas, are you oaky?  Did spectate get to you?  Are you in a swamp shack?  Do you need help? :)



  • but of course everyone uses VBA for critical appliations...



  • One day, one will be zero
    Is that a zero day vulnerability?



  • @samanddeanus said:

     QBASIC (old DOS BASIC from Microsoft) used 0 for false and -1 for true.  Also, bitwise and logical operators were combined, which is the reason for -1 = true so that FALSE = NOT(TRUE).
    A manual for an old basic dialect that used true = -1 claimed the reason was that 0 = 0b00000000 and -1 = 0b11111111, and those values wouldn't be changed between each other by memory corruption. Or something. I'm not sure. It does strike me as a nice (if devoid of any real merit) thing to have, that true = bitwisenot(false), and if treated as a signed byte, that makes true = -1.



  • @m0ffx said:

    @samanddeanus said:

     QBASIC (old DOS BASIC from Microsoft) used 0 for false and -1 for true.  Also, bitwise and logical operators were combined, which is the reason for -1 = true so that FALSE = NOT(TRUE).
    A manual for an old basic dialect that used true = -1 claimed the reason was that 0 = 0b00000000 and -1 = 0b11111111, and those values wouldn't be changed between each other by memory corruption. Or something. I'm not sure. It does strike me as a nice (if devoid of any real merit) thing to have, that true = bitwisenot(false), and if treated as a signed byte, that makes true = -1.

     

     

    from what i remember, visual basic still uses this values for boolean true and false, but in addition, when you ask for a numeric value of it, it does some conversions and returns 1 for true and 0 for false 



  •  I guess the one and only reason for true == -1 in old BASIC was that it allowed the same operators (i.e. NOT) to be used for boolean and bitwise operations. When the whole BASIC (along with the primitive operating system) has to fit into 8K of ROM, you don't want two sets of logical operators.

    "Memory corruption" is an absolutely moronic explanation. If that kind of things happen, your system will happily crash anyway.



  • Unless the author of the code added Option Compare Binary to the module UCase wasn't needed to begin with ... anyone that doesn't realize this probably shouldn't be expected to use hungarian notation or any variable names that actually mean anything.

     




  • @ammoQ said:

    "Memory corruption" is an absolutely moronic explanation. If that kind of things happen, your system will happily crash anyway.

    Was BASIC ever used in space? I guess that might help slightly with radiation randomly flipping bits.


Log in to reply