• (cs) in reply to Matt Westwood
    Matt Westwood:
    J:
    Mathlete:
    Maybe because "burned" and "burnt" are both accepted spellings for the past participle of "burn"? Additionally since the usage of "burned" was in a quotation, it would not be corrected to "burnt" anyway, it would be "burned[sic]", if anything.

    I find it a little ridiculous that we're still using Latin in English sentences, e.g. "e.g.", "[sic]", "i.e.", "per se", "etc.", etc.

    Yes well you would because you're an ignorant anti-intellectual subhuman who can't even tell the difference between "except" and "accept". Go stick your head in a bucket of water three times and pull it out twice.
    It's one of the strengths of the English language. It doesn't just borrow from other languages: it lures them into an alley, beats them senseless, and goes through their pockets.

  • Cbuttius (unregistered)

    If you redefine _250 how will you specify the 250th parameter in a boost::bind statement?

  • Chaltione (unregistered)

    Whenever I read these WTFs with enums, the closing braces with semicolons looks even sadder than usual...

    };

  • (cs) in reply to Your Name
    Your Name:
    C/C++
    Hey! Don't write it like that, it's undefined behaviour.
  • Mr Clever Ideas (unregistered) in reply to Cbuttius
    Cbuttius:
    If you redefine _250 how will you specify the 250th parameter in a boost::bind statement?
    Hint: Boost is open source.:-)
  • Nagesh (unregistered)

    Sasha motives is wrong, but stumbling upon elagant perfromance technique.

  • Silowyi (unregistered)

    I have some sympathy for this guy. I dealt with a compiler once that treated the literal 2 strangely when used as an array index.

    The following int myArray[]; int a = 2; myArray[a] = 1;

    Would yield a => 2 myArray[2] => 1F398A9C (random 4 byte sequence)

  • (cs) in reply to Watson
    Watson:
    Matt Westwood:
    J:
    Mathlete:
    Maybe because "burned" and "burnt" are both accepted spellings for the past participle of "burn"? Additionally since the usage of "burned" was in a quotation, it would not be corrected to "burnt" anyway, it would be "burned[sic]", if anything.

    I find it a little ridiculous that we're still using Latin in English sentences, e.g. "e.g.", "[sic]", "i.e.", "per se", "etc.", etc.

    Yes well you would because you're an ignorant anti-intellectual subhuman who can't even tell the difference between "except" and "accept". Go stick your head in a bucket of water three times and pull it out twice.
    It's one of the strengths of the English language. It doesn't just borrow from other languages: it lures them into an alley, beats them senseless, and goes through their pockets.

    Not much different from what English people did to rest of world two century earlier.

  • Jay (unregistered) in reply to Jim
    Jim:
    da Doctah:
    00401 is a ZIP code (which happens to be for Pleasantville, New York, the home of Reader's Digest). Excel allows the numeric format 00000 to prevent suppression of leading zeroes if you should happen to require ZIP codes in your data.
    Who cares.

    I assume (no being a yank) that Zip codes are always 5 digits, so we can still store it as 401 and pad out the 0s when we need to display.
    Pretty sure when we read input we don't make assumptions on format, so leading 0s don't mean diddly squat

    Umm, someone says, "here's how to format your output padded with the required number of leading zeros" and your reply is "that's unnecessary -- just format your output padded with the required number of leading zeros".

  • Jay (unregistered) in reply to Michael
    Michael:
    For columns - if it's in your code, then use spaces (they're free)...

    Let me ask the question again, when in your code do you use preceding 0's (other than to specify Octal)?

    I don't think the point of the complaint was, "Is it possible to write a program in which you never write a decimal number with leading zeros?" The answer is obviously yes. The complaint was that programmers sometimes don't know or forget that leading zeros cause the number to be interpreted as octal, they do sometimes put leading zeros on a decimal number to make columns line up and that sort of thing, and then the results are confusing. As programmers rarely have a need to express numbers in octal, it would not be surprising if many were unfamiliar with this rule.

    i.e. the issue is not that it creates an unsolvable problem, but that the syntax is non-intuitive, perhaps unfamiliar to many, and thus a potential trap for the unwary.

  • abbas (unregistered) in reply to Rick
    Rick:
    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?

    I don't think you're wrong. Presumably the redundancy argument was about an LCD Display (Liquid Crystal Display Display).

    Either that, or a reference to http://thedailywtf.com/Articles/The-cbitmap.aspx (a case of an embedded system without a filesystem that embedded BMP files into the C source files; to the complete confusion of the submitter. Proof that no matter how much you think you know, others might know more than you).

    Heck, one could argue the firmware on my camera is embdedded, but it sure interacts with FAT filesystems on SD cards.

  • (cs) in reply to Nagesh
    Nagesh:
    Watson:
    Matt Westwood:
    J:
    Mathlete:
    Maybe because "burned" and "burnt" are both accepted spellings for the past participle of "burn"? Additionally since the usage of "burned" was in a quotation, it would not be corrected to "burnt" anyway, it would be "burned[sic]", if anything.

    I find it a little ridiculous that we're still using Latin in English sentences, e.g. "e.g.", "[sic]", "i.e.", "per se", "etc.", etc.

    Yes well you would because you're an ignorant anti-intellectual subhuman who can't even tell the difference between "except" and "accept". Go stick your head in a bucket of water three times and pull it out twice.
    It's one of the strengths of the English language. It doesn't just borrow from other languages: it lures them into an alley, beats them senseless, and goes through their pockets.

    Not much different from what English people did to rest of world two century earlier.

    (smug) Yep.

  • (cs) in reply to Matt Westwood
    Matt Westwood:
    Nagesh:
    Watson:
    It's one of the strengths of the English language. It doesn't just borrow from other languages: it lures them into an alley, beats them senseless, and goes through their pockets.

    Not much different from what English people did to rest of world two century earlier.

    (smug) Yep.

    Two centuries earlier than what? The English language has always behaved that way. That's how it survived being invaded all the time.

    There may be a lesson in that.

  • (cs) 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.
    The following are also valid identifiers in most languages: _ __ ___ ____ etc...
  • Nag-Geoff (unregistered) in reply to Nagesh
    Nagesh:
    Watson:
    Matt Westwood:
    J:
    Mathlete:
    Maybe because "burned" and "burnt" are both accepted spellings for the past participle of "burn"? Additionally since the usage of "burned" was in a quotation, it would not be corrected to "burnt" anyway, it would be "burned[sic]", if anything.

    I find it a little ridiculous that we're still using Latin in English sentences, e.g. "e.g.", "[sic]", "i.e.", "per se", "etc.", etc.

    Yes well you would because you're an ignorant anti-intellectual subhuman who can't even tell the difference between "except" and "accept". Go stick your head in a bucket of water three times and pull it out twice.
    It's one of the strengths of the English language. It doesn't just borrow from other languages: it lures them into an alley, beats them senseless, and goes through their pockets.

    Not much different from what English people did to rest of world two century earlier.

    Isn't it obvious that the poor sod can't get over the beatings his ancestors received from people, clearly superior at the time?

  • Luiz Felipe (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    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.

    I hate those dumber string formatting functions. Lucky c++ has more advance string class.

  • Luiz Felipe (unregistered) in reply to L.
    L.:
    da Doctah:
    Bldsquirrel:
    da Doctah:
    00401 is a ZIP code (which happens to be for Pleasantville, New York, the home of Reader's Digest).

    So store it as a string? Again, stop and think about what you're doing. If the exact sequence of characters is what's important, not the numerical value, then it's not an integer. It's a string.

    Stop hacking, do things the right way, and save yourself a lot of effort.

    It's not hacking, it's inheriting a system from someone who didn't understand that just because something has digits in it doesn't make it a number.

    When I've had the opportunity to train new programmers, I explain that unless you plan on doing math with it, make it a string. Would you subtract one ZIP code from another? Increment a Social Security Number? Divide a credit card number by two?

    This is my small and largely ineffective way of trying to make the world a better place for generations of programmers yet unborn.

    Well yes .. but no If you start storing numeric values as varchar or using them as strings in your application when they can only have numeric values, ... you should probably avoid giving advice ;)

    No, you are wrong, because the ZIP is not really an number, it must not be treated like number, because it is an identifier. Doctah are correct. Everything else that can have only numbers is numeric and need to be stored in numeric variables or fields.

  • (cs) in reply to Luiz Felipe
    Luiz Felipe:
    L.:
    da Doctah:
    Bldsquirrel:
    da Doctah:
    00401 is a ZIP code (which happens to be for Pleasantville, New York, the home of Reader's Digest).

    So store it as a string? Again, stop and think about what you're doing. If the exact sequence of characters is what's important, not the numerical value, then it's not an integer. It's a string.

    Stop hacking, do things the right way, and save yourself a lot of effort.

    It's not hacking, it's inheriting a system from someone who didn't understand that just because something has digits in it doesn't make it a number.

    When I've had the opportunity to train new programmers, I explain that unless you plan on doing math with it, make it a string. Would you subtract one ZIP code from another? Increment a Social Security Number? Divide a credit card number by two?

    This is my small and largely ineffective way of trying to make the world a better place for generations of programmers yet unborn.

    Well yes .. but no If you start storing numeric values as varchar or using them as strings in your application when they can only have numeric values, ... you should probably avoid giving advice ;)

    No, you are wrong, because the ZIP is not really an number, it must not be treated like number, because it is an identifier. Doctah are correct. Everything else that can have only numbers is numeric and need to be stored in numeric variables or fields.

    Correct: just because they're composed of digits doesn't automatically mean they're numbers any more than something composed of English letters is automatically a word; ZIP codes, SSNs and CCNs are identifiers.

    If you're that concerned about using an appropriate type, use something with a sufficiently rich type system.

  • (cs) in reply to Watson
    Watson:
    Luiz Felipe:
    L.:
    da Doctah:
    Bldsquirrel:
    da Doctah:
    00401 is a ZIP code (which happens to be for Pleasantville, New York, the home of Reader's Digest).

    So store it as a string? Again, stop and think about what you're doing. If the exact sequence of characters is what's important, not the numerical value, then it's not an integer. It's a string.

    Stop hacking, do things the right way, and save yourself a lot of effort.

    It's not hacking, it's inheriting a system from someone who didn't understand that just because something has digits in it doesn't make it a number.

    When I've had the opportunity to train new programmers, I explain that unless you plan on doing math with it, make it a string. Would you subtract one ZIP code from another? Increment a Social Security Number? Divide a credit card number by two?

    This is my small and largely ineffective way of trying to make the world a better place for generations of programmers yet unborn.

    Well yes .. but no If you start storing numeric values as varchar or using them as strings in your application when they can only have numeric values, ... you should probably avoid giving advice ;)

    No, you are wrong, because the ZIP is not really an number, it must not be treated like number, because it is an identifier. Doctah are correct. Everything else that can have only numbers is numeric and need to be stored in numeric variables or fields.

    Correct: just because they're composed of digits doesn't automatically mean they're numbers any more than something composed of English letters is automatically a word; ZIP codes, SSNs and CCNs are identifiers.

    If you're that concerned about using an appropriate type, use something with a sufficiently rich type system.

    Not me. I determine which to use based on which one stores in my database better. It takes 2 bytes to represent a zip code as a number and 5 to represent it as a string. It also indexes easier. Idk though, maybe I'm just a whore for efficiency.

  • Jezebel Spirit (unregistered) in reply to Scarlet Manuka

    There was once a moderately obscure platform that systematically used <radix><underscore><number> to represent integer literals, so you would write for example 8_377 or 16_FF instead of 0377 or 0xFF. Simple, unambiguous, and supports bases other than 8 and 16.

    Of course, it had to go.

  • (cs) in reply to OneOfTheFew

    They do realise that absolutes is the way of the Sith.

    Leads to the Darks side it does........

  • L. (unregistered) in reply to PiisAWheeL
    PiisAWheeL:
    Watson:
    Luiz Felipe:
    L.:
    da Doctah:
    Bldsquirrel:
    da Doctah:
    00401 is a ZIP code (which happens to be for Pleasantville, New York, the home of Reader's Digest).

    So store it as a string? Again, stop and think about what you're doing. If the exact sequence of characters is what's important, not the numerical value, then it's not an integer. It's a string.

    Stop hacking, do things the right way, and save yourself a lot of effort.

    It's not hacking, it's inheriting a system from someone who didn't understand that just because something has digits in it doesn't make it a number.

    When I've had the opportunity to train new programmers, I explain that unless you plan on doing math with it, make it a string. Would you subtract one ZIP code from another? Increment a Social Security Number? Divide a credit card number by two?

    This is my small and largely ineffective way of trying to make the world a better place for generations of programmers yet unborn.

    Well yes .. but no If you start storing numeric values as varchar or using them as strings in your application when they can only have numeric values, ... you should probably avoid giving advice ;)

    No, you are wrong, because the ZIP is not really an number, it must not be treated like number, because it is an identifier. Doctah are correct. Everything else that can have only numbers is numeric and need to be stored in numeric variables or fields.

    Correct: just because they're composed of digits doesn't automatically mean they're numbers any more than something composed of English letters is automatically a word; ZIP codes, SSNs and CCNs are identifiers.

    If you're that concerned about using an appropriate type, use something with a sufficiently rich type system.

    Not me. I determine which to use based on which one stores in my database better. It takes 2 bytes to represent a zip code as a number and 5 to represent it as a string. It also indexes easier. Idk though, maybe I'm just a whore for efficiency.

    You are obviously correct and probably somebody who knows what the f* he's doing .. They are java programmers, complete total utter noobs who actually believe it'll be so much better if you CALL those digits a string INSIDE the computer ... when in effect that is merely a human view on the subject, which the machine doesn't care about.

    FFS . How can two different people even stand behind that failure of an argument I cannot understand ... keep on creating WTF though .. go ahead .. "identifiers" my ass . my unique ID columns are sometimes integers, want me to store those as strings too ??

  • Craig (unregistered) in reply to Nagesh
    Nagesh:
    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.

    Nagesh, Please (not "Plz") read (not "be reading") about Premature Optimisation before making (not "meking") uninformed comments (not "coment") about programming for performance in any language. Don't write rubbish code in a futile attempt to achieve nanoseconds worth of performance improvement.

  • Neil (unregistered)

    enums are the solution to those octal mistakes.

    enum decimal {
      _0000, _0001, _0002, _0003, _0004, _0005, _0006, _0007, _0008, _0009,
      _0010, _0011, _0012, _0013, _0014, _0015, _0016, _0017, _0018, _0019,
      /* etc. */
    };

    Perfect alignment.

  • bahner (unregistered) in reply to snoofle

    Sorry, no can tell. That's only revealed on a need to know basis. But I can give you a clue: its hold by the Fnord Fire Circle :P

  • (cs) in reply to L.
    L.:
    You are obviously correct and probably somebody who knows what the f* he's doing .. They are java programmers, complete total utter noobs who actually believe it'll be so much better if you CALL those digits a string INSIDE the computer ... when in effect that is merely a human view on the subject, which the machine doesn't care about.

    FFS . How can two different people even stand behind that failure of an argument I cannot understand ... keep on creating WTF though .. go ahead .. "identifiers" my ass . my unique ID columns are sometimes integers, want me to store those as strings too ??

    Depends; there are those who argue that primary keys should be built from one or more data columns in the table, while there are those who believe that role of primary key should be abstracted from the data itself and implemented as a distinct column. In the latter case, using a purely ordinal type makes for automated generation with a minimum of effort.

    TRWTF of course are online forms that require me to enter a ZIP code and refuse to accept "SW1V 3BS" as an answer.

  • ThatOneGuy (unregistered)

    TRWTF: people continue to fall for Nagesh's tired old schtick.

  • list_processing++ (unregistered) in reply to L.

    Fixed length strings can be stored as integers too. Do you do that as well?

  • unanymously a coder (unregistered) in reply to Michael

    And that's the way I gotten burned by this. Know TCL script? Well, weakly typed - everything is a string. But hey, they use the same numbering notation as C: leading 0 means octal, leading 0x means hex. Getting into date processing, one gets a string like "110503" which represents YYMMDD, i.e. thr third of May 2011. Now you split the thing into 3 teo digit sections and assign them to variables year, month and day. And you do arithmetics with them - all is fine whilst testing the code. Now guess what happens when you get to the eight of May - or to august in that respect.

    expected integer but got "08" (looks like invalid octal number)

  • unanymously a coder (unregistered) in reply to Silowyi
    Silowyi:
    I have some sympathy for this guy. I dealt with a compiler once that treated the literal 2 strangely when used as an array index.

    The following int myArray[]; int a = 2; myArray[a] = 1;

    Would yield a => 2 myArray[2] => 1F398A9C (random 4 byte sequence)

    Erm, this code instigates undefined behaviour, does it not? Without the array size, how can the compiler assign apropriate memory for the array? In the case of gcc, the compiler gives an error:

    bad_array.c: In function main': bad_array.c:6: error: array size missing inmyArray'

    By setting the array size, I get it compiled. If setting the size too low, I'll get a seg-fault. When set apropriately I get the expected result (the value 1).

    Assuming the compiler does not complain, what most likely happened was this:

    • no or insuficient memory allocated for the array due to missing size parameter
    • after setting value, something modified the memory accessed by myArray[a] = 1;

    Who knows where myArray[a] pointed to - could be stack, could be heap - modification could have happened by calling the 'printf' you may have used to display its content.

  • NerdF (unregistered) in reply to Silowyi

    There is nothing strange about that! Initialize your array with a size bigger than a and it will work properly.

  • The lurk (unregistered) in reply to boog
    boog:
    I admit I appreciate his strategy: rather than "get burned" like last time, he chooses to burn everyone else. That's just being a team-player.

    HAhahahaha! Best comment EVER!

    captcha: who cares? grow up.

Leave a comment on “Tired of Getting Burned”

Log In or post as a guest

Replying to comment #:

« Return to Article