• Bananas (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    The year was 1991, maybe 1992. It was an embedded system (without any file system, no less) with a four-line, twenty column text-mode LCD display.
    The Department of Redundancy department has fined you $2.00 dollars. You may make your payment at the nearest ATM machine.
  • Inb4 (unregistered) in reply to PedanticCurmudgeon

    He's turned me into a newt!

  • Kef Schecter (unregistered) in reply to Steve The Cynic
    The real WTF here, however, was me. It took me three passes over the code before I noticed the leading zeroes.
    No, the real WTF was that C used leading zeroes for octal numbers when a prefix like 0o would have done just as well and caused everyone far fewer headaches. (After all, there was already 0x for hex).
  • (cs) in reply to iToad
    iToad:
    This is a clear case where a Software Engineer IV needs to be busted back to something not involving computers or logical thought.
    FTFY
  • A Coworker (unregistered) in reply to soup dog

    A Coworker I knew this guy and the poster, The Bloviator lasted 2 years before getting laid off. He was also a level 4 engineer when working at the company and was quoted once saying “can look at my code, and whenever you see this and underscore, you know it’s a number !"

  • (cs) in reply to Your Name
    Your Name:
    You run into that a lot in C/C++, where something is outside the standard but in common usage and then people start whining when a new version of a compiler starts rejecting their code.
    Ah yes, like a bunch of code written by some chaps (translation: prime fuckwits) who had no fear of undefined behaviour.

    It involved two different versions of the Solaris native compiler. One would accept code like this:

    FunkyCharacterBufferClass variable;

    ...

    printf("%s\n", variable); // Note no & on the variable

    (This is undefined behaviour, passing an non-POD object to the ellipsis part of an varargs function. The previous version of the compiler silently passed the address of the variable, exactly as if the & was there.)

    The new version of the compiler sprayed warnings all over the place because this pattern was used extensively. The new version also passed the whole object by value, and the code ceased to work at all.

    That whole place was a WTF in and of itself, and server-side JavaScript got one of my colleagues into the habit of formatting strings like this:

    "Some text with a number at the end: " + integervariable

    And he then brought this habit to C++, where it doesn't work quite so well.

    Ah, well, I escaped from there.

  • (cs) in reply to A Coworker
    A Coworker:
    A Coworker I knew this guy and the poster, The Bloviator lasted 2 years before getting laid off. He was also a level 4 engineer when working at the company and was quoted once saying “can look at my code, and whenever you see this and underscore, you know it’s a number !"
    Let me guess...was he laid off for reasons completely unrelated to his inability to think straight?
  • Kef Schecter (unregistered)
    This is a clear case where a Software Engineer IV needs to be busted back to Software Engineer I, until he learns how to use enums correctly. Hint: Depending on their numeric values isn't very smart.

    Eh? Depending on their numeric values can be perfectly sensible. The primary use of an enum is to define a set of states, in which case the values should indeed not be relied upon, but there are plenty of cases where it does make sense. What if you're writing an app or library that reads in a binary file, and the relevant values are determined by some external spec rather than your own code? Certainly it's sensible then. And there's nothing wrong with using an anonymous enum solely as a convenient way to declare a series of numeric constants -- so long as they have meaningful names and are not just "FortyTwo" and whatnot.

  • (cs) in reply to Kef Schecter

    durp, I'm dumb, I misread the comment I was replying to. And apparently the "delete" button doesn't actually do anything?

  • (cs) in reply to Bananas
    Bananas:
    Steve The Cynic:
    The year was 1991, maybe 1992. It was an embedded system (without any file system, no less) with a four-line, twenty column text-mode LCD display.
    The Department of Redundancy department has fined you $2.00 dollars. You may make your payment at the nearest ATM machine.
    I would argue that it is possible for an embedded system to have a filesystem. Many printers have filesystems, but I would still say the software that runs the printer is 'embedded'. Am I wrong?
  • (cs) in reply to PedanticCurmudgeon
    PedanticCurmudgeon:
    Anketam:
    He is a witch! I say we need to burn him and his code at the stake.
    Inb4 "He's turned me into a newt!"
    No, he turned you into a enum!

    But you got better, right?

  • JJ (unregistered)

    TRWTF is that anyone actually used octal. EVER.

  • JJ (unregistered) in reply to Bananas
    Bananas:
    Steve The Cynic:
    The year was 1991, maybe 1992. It was an embedded system (without any file system, no less) with a four-line, twenty column text-mode LCD display.
    The Department of Redundancy department has fined you $2.00 dollars. You may make your payment at the nearest ATM machine.
    Actually, a very long time ago I was told (incorrectly) that LCD stood for Liquid Crystal Digit, not Display, so I can understand the poster's error if he too was told the same.
  • J (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    Reminds me of the time a colleague got bitten by a C compiler's interpretation of some literal numbers he put in some source code.

    The year was 1991, maybe 1992. It was an embedded system (without any file system, no less) with a four-line, twenty column text-mode LCD display.

    The data to be displayed was separated into numbered pages. Page numbers were four digits, divided into section, chapter and page-in-chapter. Being software types, we naturally started at zero, which lead to a hysterical issue with the page number validation routine. You see, a large fraction of the pages numbered between 0007 and 1000 (exclusive) were declared invalid. The reason: my colleague's nicely laid out table of valid page numbers, stored in 16-bit ints, completely formatted with leading zeroes and all so they'd look like the numbers you typed on the keypad. There was no page "0xx8", so the compiler didn't crap out, but the octaliser guaranteed that not one of the numbers was interpreted the way that he thought.

    The real WTF here, however, was me. It took me three passes over the code before I noticed the leading zeroes. In his defence: as soon as I said, "They're octal," he did a facepalm and went to fix it.

    Obviously, a coder's job is to know the language. But seriously, C, prepending a 0 changes the radix? WTF?

  • An innocent abroad (unregistered) in reply to J

    If compilers get integers wrong and this is the solution to that, I want to tell that compilers make floating point errors also -- and I really want to see his solution.

  • iToad (unregistered) in reply to Kef Schecter
    Kef Schecter:
    This is a clear case where a Software Engineer IV needs to be busted back to Software Engineer I, until he learns how to use enums correctly. Hint: Depending on their numeric values isn't very smart.

    Eh? Depending on their numeric values can be perfectly sensible. The primary use of an enum is to define a set of states, in which case the values should indeed not be relied upon, but there are plenty of cases where it does make sense. What if you're writing an app or library that reads in a binary file, and the relevant values are determined by some external spec rather than your own code? Certainly it's sensible then. And there's nothing wrong with using an anonymous enum solely as a convenient way to declare a series of numeric constants -- so long as they have meaningful names and are not just "FortyTwo" and whatnot.

    It shames me to admit it, but I have used numerical values of enums in production code. In fact, I had for loops that iterated over enums. I had to force my fingers to type the code in.

    I made real sure that the enum declarations had big comments warning that both the order and value of the enums were critical, and to not change them unless you knew what you were doing.

    BTW, is using enum numeric values MISRA compliant?

  • (cs) in reply to Kef Schecter
    Kef Schecter:
    The real WTF here, however, was me. It took me three passes over the code before I noticed the leading zeroes.
    No, the real WTF was that C used leading zeroes for octal numbers when a prefix like 0o would have done just as well and caused everyone far fewer headaches. (After all, there was already 0x for hex).

    WRONG... 0x was added much later.

    Remember, "C" was INTENDED to be "just one level above assembler". Given the computer capabilities at the time (specifically DEC PDP-11) this made tremendous sense. Minimal overhead, fine grained control, allowed the use of a more expressive format with very few negative impacts.

  • Nagesh (unregistered)

    In Java, this is good means of eficiency since veriable get passed by reference and not meke copy.

  • Jon (unregistered) in reply to An innocent abroad
    An innocent abroad:
    If compilers get integers wrong and this is the solution to that, I want to tell that compilers make floating point errors also -- and I really want to see his solution.

    Easy.

    enum { zero, one, two, three, four, five, six, seven, eight, nine, ten, one_hundred = 100, one_thousand = 1000, ten_thousand = 10000,

    };

    float Pi = three + (float)one / ten + (float)four / one_hundred + (float)one / one_thousand + (float)six / ten_thousand;

  • J (unregistered) in reply to Nagesh
    Nagesh:
    In Java, this is good means of eficiency since veriable get passed by reference and not meke copy.

    Java already has the Integer class, if you were really worried about that. Creating an enum with spelled-out numbers does not help efficiency.

  • Nagesh (unregistered) in reply to J
    J:
    Nagesh:
    In Java, this is good means of eficiency since veriable get passed by reference and not meke copy.

    Java already has the Integer class, if you were really worried about that. Creating an enum with spelled-out numbers does not help efficiency.

    Integer can be victim of auto-boxing. Beter to be sure with imutable clas.

  • Jay (unregistered)

    But think of the advantages! For example, if the value of "seven" changes, there's only one place to go to fix it!

  • Jay (unregistered)

    I think a fun thing to do with code like this is to pick a number deep in the middle of such a list and change the value. Like:

    OneHundredTwentyThree=123,
    TwoHundredSixtyTwo=262,
    ThreeHundredFortySeven=437,
    SixThousandTwenty=6020,
    SixThousandThreeHundredTwo=6302,
    ... etc ...
    

    If the list is long and/or the numbers have enough digits, this could be hard to spot. Then sit back and watch him try to find the error.

  • Jay (unregistered)

    I think this story falls under the general heading, "Programmer Refused to Belive that his Code had a Bug and Insisted it Must Be a Compiler Error".

    I recall a programmer I worked with who had a bug in her program so that a certain field printed as zero rather than the value it was supposed to have. So she tried twenty different ways to display the value of the field. They all showed zero. She insisted that there must be something wrong with the print function that it would not print the correct value, rather than even considering the possibility that she might never have set it.

  • J (unregistered) in reply to Nagesh
    Nagesh:
    J:
    Nagesh:
    In Java, this is good means of eficiency since veriable get passed by reference and not meke copy.

    Java already has the Integer class, if you were really worried about that. Creating an enum with spelled-out numbers does not help efficiency.

    Integer can be victim of auto-boxing. Beter to be sure with imutable clas.

    "Integer" could be the result of autoboxing of an "int." But isn't that what you wanted (to pass the pointer)? In any case, the enum still doesn't help.

  • Bonbon (unregistered) in reply to Jay
    Jay:
    But think of the advantages! For example, if the value of "seven" changes, there's only one place to go to fix it!
    At least only once for each of his (presumably many) enums...

    I had a Javascript version of the octal trick. Made a nicely formatted set of month options:

    <option value="01">Jan</option>
      ...
    <option value="07">Jul</option>
    <option value="08">Aug</option>
    <option value="09">Sep</option>
      ...
    

    The Javascript validation code was fun. Especially since Javascript accepted 08 and 09. Can't recall what it interpreted it as...

  • Nagesh (unregistered) in reply to J
    J:
    Nagesh:
    J:
    Nagesh:
    In Java, this is good means of eficiency since veriable get passed by reference and not meke copy.

    Java already has the Integer class, if you were really worried about that. Creating an enum with spelled-out numbers does not help efficiency.

    Integer can be victim of auto-boxing. Beter to be sure with imutable clas.

    "Integer" could be the result of autoboxing of an "int." But isn't that what you wanted (to pass the pointer)? In any case, the enum still doesn't help.

    I am not being to use autoboxing (my project runing jdk 1.3). My understanding being all Integer can be unexpectedly convert to int. Much beter to use comon class.

  • Harrow (unregistered) in reply to c
    c:
    I have really missed a trick - in all these years it's never occurred to me that underscore plus number is a valid identifier.
    In Delphi, a single underscore is also a valid identifier. Also, a horizontal rule the full width of the page made of underscores is a valid identifier.

    I put this in an include file: ________________________________________________________=0;

    Then I coded this in my main:

    //______________________________________________________

    // INITIALIZE DEFAULT UNIT VECTOR

      X   = 1;
      Y   = 0;
      Z   =
    

    // On second thought, we really // don't need the whole vector...


    // ;

    -Harrow.

  • J (unregistered) in reply to Nagesh
    Nagesh:
    I am not being to use autoboxing (my project runing jdk 1.3). My understanding being all Integer can be unexpectedly convert to int. Much beter to use comon class.

    I wouldn't say "unexpectedly"... But define your own immutable substitute for Integer if you want. What's that got to do with a the ridiculous enum in the article?

  • Thuktun (unregistered)
    I've seen compilers get literal numbers wrong before. And I'm tired of getting burned.
    Translation: I assumed that I saw a zebra instead of a horse, multiple times, and didn't sufficiently verify whether or not I was right. Thus, I take extraordinary precautions that don't make sense.
  • Dotan Cohen (unregistered) in reply to J
    J:
    Obviously, a coder's job is to know the language. But seriously, C, prepending a 0 changes the radix? WTF?

    You even have that in todays "modern high level" languages, such as PHP: echo intval(42); // 42 echo intval(042); // 34 echo intval('042'); // Guess!

    That last one is the one that bit me. Try to guess what it outputs, before looking it up.

  • J (unregistered) in reply to Dotan Cohen
    Dotan Cohen:
    J:
    Obviously, a coder's job is to know the language. But seriously, C, prepending a 0 changes the radix? WTF?

    You even have that in todays "modern high level" languages, such as PHP: echo intval(42); // 42 echo intval(042); // 34 echo intval('042'); // Guess!

    That last one is the one that bit me. Try to guess what it outputs, before looking it up.

    I had to look it up. I won't spoil it, but it looks like there's an optional second argument which can be used to specify the base, when it might be ambiguous.

    Anyway, there were plenty of characters that could have been used to denote octal. Why would they pick one which already had an excepted (different!) mathematical meaning at that position?

  • Buddy (unregistered) in reply to Rick
    Rick:
    ... I would argue that it is possible for an embedded system to have a filesystem... Am I wrong?

    I actually wrote a file system for an embedded system. It divided the high memory into sectors, and used something similar to the FAT model. I wrote special crash-protected fopen, fclose, fread, fwrite, fgets routines for it. Main reason was to make it easy to implement I/O with values less than 8 bits in width to pack data without requiring a compression routine.

  • J (unregistered) in reply to J
    J:
    Anyway, there were plenty of characters that could have been used to denote octal. Why would they pick one which already had an excepted (different!) mathematical meaning at that position?

    *Accepted. Ack...

  • (cs) in reply to Buddy
    Buddy:
    frits:
    Potiguar:
    All he needed was:

    enum Numbers { forty_two = 42; }

    Seriously, who hasn't made this joke?

    Correction:

    enum Numbers
    {
       forty_two = six times nine;
    }

    #define SIX 1 + 5 #define NINE 8 + 1 printf("%d\n", SIX * NINE);

    output: 42

  • Buddy (unregistered) in reply to J
    J:
    ... Anyway, there were plenty of characters that could have been used to denote octal. Why would they pick one which already had an excepted (different!) mathematical meaning at that position?

    Eventually you stop asking Why, and just grab a bottle and wait for its sweet, sweet embrace.

  • (cs) in reply to Anketam
    Anketam:
    PedanticCurmudgeon:
    Anketam:
    He is a witch! I say we need to burn him and his code at the stake.
    Inb4 "He's turned me into a newt!"
    No, he turned you into a enum!

    But you got better, right?

    I think so, but I'm not sure after looking at today's code sample. I think part of me may have been null'd forever.

  • (cs) in reply to Reginold
    Reginold:
    Hopefully, this is a 16 bit system. Either way declaring MaxValue is a WTF of its own.

    Captcha: facilisi. Enums are not the right facilisi.

    Hopefully this is NOT on a 16 bit system. -1 is not a good value for MaxValue.

  • Nag-Geoff (unregistered) in reply to soup dog
    soup dog:
    I refuse to believe someone can be this stupid. Seriously. That's just freaking awful. I would take one look at this code and fire him. immediately.

    Unfortunately, old chap, there's plenty of fools out there with a keyboard and a compiler at their disposal. You're obviously blind or affected by some kind of political correctness syndrome to point out the idiocy to an idiot.

    Never be afraid to call a spade a spade.

  • (cs) in reply to Jon
    Jon:
    An innocent abroad:
    If compilers get integers wrong and this is the solution to that, I want to tell that compilers make floating point errors also -- and I really want to see his solution.

    Easy.

    enum { zero, one, two, ... ten, one_hundred = 100, one_thousand = 1000, ten_thousand = 10000,

    };

    float Pi = three + (float)one / ten + (float)four / one_hundred + (float)one / one_thousand + (float)six / ten_thousand;

    Hum... You should try to run that code sometime. With all those integer divisions, it won't give you the result you expect.

  • (cs) in reply to Steve The Cynic
    Steve The Cynic:
    It involved two different versions of the Solaris native compiler. One would accept code like this:

    FunkyCharacterBufferClass variable;

    ...

    printf("%s\n", variable); // Note no & on the variable

    (This is undefined behaviour, passing an non-POD object to the ellipsis part of an varargs function. The previous version of the compiler silently passed the address of the variable, exactly as if the & was there.)

    At least on C99 it is has a defined behaviour.

  • decet (unregistered) in reply to Tester
    Tester:
    Frist!

    And not spam!

    first fool

  • Nagesh (unregistered) in reply to J
    J:
    Nagesh:
    I am not being to use autoboxing (my project runing jdk 1.3). My understanding being all Integer can be unexpectedly convert to int. Much beter to use comon class.

    I wouldn't say "unexpectedly"... But define your own immutable substitute for Integer if you want. What's that got to do with a the ridiculous enum in the article?

    Plz be reading about performace progaming in Java before meking uninformed coment.

  • (cs) in reply to Mcoder
    Mcoder:
    Reginold:
    Hopefully, this is a 16 bit system. Either way declaring MaxValue is a WTF of its own.

    Captcha: facilisi. Enums are not the right facilisi.

    Hopefully this is NOT on a 16 bit system. -1 is not a good value for MaxValue.

    Signedness of enumerated types is implementation defined in C, so it still might mean 65535 and not -1, depending.
  • (cs) in reply to Mcoder
    Mcoder:
    Jon:
    An innocent abroad:
    If compilers get integers wrong and this is the solution to that, I want to tell that compilers make floating point errors also -- and I really want to see his solution.

    Easy.

    enum { zero, one, two, ... ten, one_hundred = 100, one_thousand = 1000, ten_thousand = 10000,

    };

    float Pi = three + (float)one / ten + (float)four / one_hundred + (float)one / one_thousand + (float)six / ten_thousand;

    Hum... You should try to run that code sometime. With all those integer divisions, it won't give you the result you expect.

    Hum... you should try to run that code sometime. With the precedence of cast operators being greater than that of division, and the standard rules for arithmetic type promotion, it won't give you the result you think.
  • Aninnymouse (unregistered) in reply to Bananas
    Bananas:
    Steve The Cynic:
    The year was 1991, maybe 1992. It was an embedded system (without any file system, no less) with a four-line, twenty column text-mode LCD display.
    The Department of Redundancy department has fined you $2.00 dollars. You may make your payment at the nearest ATM machine.

    But I've forgotten my PIN number!

  • Twiddles (unregistered) in reply to Ross
    Ross:
    If I was in a mischievous mood, I would like to make the following change:

    Zero = -1,

    ...and watch the resulting mayhem.

    Much more fun if you just delete a value somewhere in the middle - probably less noticable....

  • George (unregistered) in reply to iToad
    iToad:
    This is a clear case where a Software Engineer IV needs to be busted back to Software Engineer I, until he learns how to use enums correctly. Hint: Depending on their numeric values isn't very smart.

    People who do this crap wouldn't recognize a #define if it bit them on the ass.

    I'll go a step further, and say depending on an enums value defeats the purpose of the enum. If you know you need a 5, use a 5 - except in cases like this where your compiler can't be trusted to use 5 consistently
  • Michael (unregistered) in reply to Kef Schecter
    Kef Schecter:
    The real WTF here, however, was me. It took me three passes over the code before I noticed the leading zeroes.
    No, the real WTF was that C used leading zeroes for octal numbers when a prefix like 0o would have done just as well and caused everyone far fewer headaches. (After all, there was already 0x for hex).
    Why would people use leading 0s in code (other than when they want to specify Octal)?
  • (cs) in reply to frits
    frits:
    Potiguar:
    All he needed was:

    enum Numbers { forty_two = 42; }

    Seriously, who hasn't made this joke?

    Not for thirty years.

Leave a comment on “Tired of Getting Burned”

Log In or post as a guest

Replying to comment #:

« Return to Article