• (cs) in reply to jay
    jay:
    In fairness, the "BigIndian" programmer (not Nagesh, I mean the programmer who used that name in his code) may have known the correct name and just been joking. I haven't done any research on this, but I strongly suspect that whoever invented the terms BigEndian and LittleEndian was thinking of the song "Ten Little Indians" and making a joke.
    Surprisingly, no. The terms come from Gulliver's Travels, in which wars are fought over which is the appropriate end to break an egg.

    (My work the last few weeks has been steeped in mismatched endianness, hence my bloviating on the subject)

  • jay (unregistered)

    RE the code to "fool a not-so-wily hacker": I don't fault them for the idea. A standard mantra of security is that no security system will keep out a determined, capable attacker. The goal is to keep out the casual, less-competent attackers and make things difficult enough for the more-capable that they decide that it's easier to pick on someone else. Like I don't suppose that the lock on the front door of my house will make it absolutely impossible for an expert thief to break in. But it might keep out some young punk making his first try at breaking into a house, and it might slow down the professional thief long enough for me to get a gun, or even if I'm not home, make it obvious enough that he's breaking in that one of the neighbors will call the police.

    No, what's dumb about that security scheme is that they put it in the Javascript, where any hacker can easily see it. Okay, I guess a really lazy hacker might not bother to look at the code. But it's a little like putting up one of those signs that says "Protected by XYZ Alarm Systems" when you really have no alarm system at all, just to scare off the burglars ... and then putting a sign above it that says, "We don't really have an alarm system. We just put this sign up to scare off burglars."

  • jay (unregistered) in reply to Abico
    Abico:
    jay:
    In fairness, the "BigIndian" programmer (not Nagesh, I mean the programmer who used that name in his code) may have known the correct name and just been joking. I haven't done any research on this, but I strongly suspect that whoever invented the terms BigEndian and LittleEndian was thinking of the song "Ten Little Indians" and making a joke.
    Surprisingly, no. The terms come from Gulliver's Travels, in which wars are fought over which is the appropriate end to break an egg.

    Hmm, is that really where they got the name from, though? It's been a while since I read Gulliver's Travels, but I don't recall them calling the two sides "Big Endians" and "Little Endians". Not that the person who invented the computer terms couldn't have invented them based on Swift without his using those exact words.

  • (cs) in reply to jay
    jay:
    Abico:
    jay:
    In fairness, the "BigIndian" programmer (not Nagesh, I mean the programmer who used that name in his code) may have known the correct name and just been joking. I haven't done any research on this, but I strongly suspect that whoever invented the terms BigEndian and LittleEndian was thinking of the song "Ten Little Indians" and making a joke.
    Surprisingly, no. The terms come from Gulliver's Travels, in which wars are fought over which is the appropriate end to break an egg.

    Hmm, is that really where they got the name from, though? It's been a while since I read Gulliver's Travels, but I don't recall them calling the two sides "Big Endians" and "Little Endians". Not that the person who invented the computer terms couldn't have invented them based on Swift without his using those exact words.

    Here it is on Gutenberg. It looks like Big-Endian is explicitly used but not Little. So maybe it's actually a mashup joke?

  • Sigivald (unregistered) in reply to Cidolfas
    Cidolfas:
    The first one does not appear to be a WTF - in fact, the developer *is* covering all his/her bases by not only testing for null and undefined, but a real string whose contents are "null" or "undefined" - i.e. a victim of a bad concatenation. Might be an indication of WTFs elsewhere (or just oversights) but is not a WTF in itself.

    Amen.

    The code is not a WTF.

    The problem that it's dealing with is, but sometimes you just have to deal with crappy inputs from Other Code You Cannot Fix.

  • Sigivald (unregistered) in reply to Sigivald

    Also?

    Seriously?

    Screw BBCode*. Or rather, screw DWTF's parser that evidently cares about casing in it.

    I guess using a subset of HTML would have been too easy and standard...

    (* And double-screw the bad UX of having the "BBCode Okay" reference link REPLACE the page you're viewing, rather than opening a new page...)

  • Jason H (unregistered)

    Don't make us type it out by hand, Nathan. Don't do it. You've got the power, use it.

  • (cs)

    Just came across this code that reminded me of the first WTF from today, hehe.

                                <% if DistiType = "Fake Company " OR DistiType = "FakeCompany" OR DistiType = "fakecompany" OR distitype = "FAKECOMPANY" OR DistiType= "FAKE COMPANY" then %>
                            Fake Company.
                            <% else %>
                            <%= DistiType %>.
                            <% end if %>
  • (cs)

    Sorry. No Secret Squirrel Club is complete without Morocco Mole. That's the real WTF.

  • That Guy (unregistered) in reply to Abico
    Abico:
    Leo:
    One little, two little, three little Indians...
    16777216 big, 33554432 big, 50331648 big endians....

    You, sir, win the Internet!

  • (cs) in reply to Sigivald
    Sigivald:
    Cidolfas:
    The first one does not appear to be a WTF - in fact, the developer *is* covering all his/her bases by not only testing for null and undefined, but a real string whose contents are "null" or "undefined" - i.e. a victim of a bad concatenation. Might be an indication of WTFs elsewhere (or just oversights) but is not a WTF in itself.

    Amen.

    The code is not a WTF.

    The problem that it's dealing with is, but sometimes you just have to deal with crappy inputs from Other Code You Cannot Fix.

    A minor WTF, then, is the fact that there is no comment in the code in question to explain the specific WTF that this kludge is intended to get around. "This code is shit because Big Fred cocked up when he "corrected" the JDHIHG table."

  • Jerry (unregistered) in reply to Sigivald
    Sigivald:
    double-screw the bad UX of having the "BBCode Okay" reference link REPLACE the page you're viewing, rather than opening a new page
    Your browser most likely has an option to open a link in a new page. It isn't Alex's job to teach you how to use your browser. I'd rather him let me make that decision than take control of my browser and make it do things I may not want.
  • Shark8 (unregistered) in reply to Soaring Eagle
    Soaring Eagle:
    How many different byte orders are there? Middle-Indian?

    http://en.wikipedia.org/wiki/Endianness#Middle-endian

    Yep.

  • Panda (unregistered)

    The first one could be tempting at times, though bad at others. We pull in data from different source types and have had a few oops from something expecting the wrong sort of blank value.... including a Sgt Null that failed to import from the wonderful tab separated text file.

  • Major DoucheBag (unregistered)

    How is:

    Boolean public static bool IsEmpty(string s) { return string.IsNullOrEmpty(s) || s == "undefined" || s == "null";
    A WTF?

    I use similar code on a semi-regular basis in my work. Sometimes a protocol will send nothing to represent nothing, sometimes it will send an empty string, or sometimes it will send "null" - and it's much easier and faster to have one 'catch all' method than it is try to enforce that every web-service, parser & protocol give me a specified answer.

  • Ema Nympton (unregistered)

    Checking for null, empty, "undefined", or "null" is useful. If you're pulling data from multiple sources, it's not uncommon for some parser that requires non-empty strings to parse data with empty strings and put a literal "null" in place of an actual null string.

  • Gerry (unregistered) in reply to Abico

    The use of big-endian in computing comes from "ON HOLY WARS AND A PLEA FOR PEACE" http://www.ietf.org/rfc/ien/ien137.txt

    This isn't spam askimet - it links to IETF!

  • (cs)

    Bits within a Byte do not have an order.

    A Byte is, by definition, the smallest addressable unit.

  • Cheong (unregistered)

    Regarding "SecretSquirrel", that's how to produce difficult to followup code without being caught by coding practice analysis programs.

    The practice say you can'y use names like A, B, C, but don't say you can't use Apple, Banana, Cat, etc.

  • Ptorq (unregistered) in reply to Cidolfas

    That was my reaction as well. Without knowing what sort of data users might be throwing at this thing, checking to see if a string is literally set to "null" or "undefined" might just be prudent thinking. I know that I've dealt with datasets before where the input data was not ... let's just say "well-formed". Or consistent. Or sane.

    If anything, the WTF is in not also checking for "N/A", "none", "I don't know", and a couple of hundred other variations on the same theme. But perhaps the data is mostly consistent and there are only a couple of (probably high-ranking, so nobody dares correct them) nutjobs using their Very Own Method of Input Terminology.

  • (cs)

    I once had a function to look at user input and return True if he pressed: The T key (shifted or unshifted) (keyboard mode English or Thai) The Y key (shifted or unshifted) (keyboard mode English or Thai) The "CH" key (for "Chai" which is "yes" in Thai) (shifted or unshifted) (keyboard mode English or Thai)

    Same sort of coverage for false.

    Amazingly, all the possibilities were mutually exclusive.

  • Meep (unregistered) in reply to Abico
    Abico:
    PiisAWheeL:
    Soaring Eagle:
    How many different byte orders are there? Middle-Indian?
    Think of a byte order as a string. You can only read it in 2 directions. Forwards and backwards.

    Or a better analogy is comparing little endian and big endian to written languages.

    Left to right vs right to left. 10110001 in 1 is the same as 10001101 in the other.

    Sort of. Endianness can operate at the bit level, but more typically, it affects the bytes of multi-byte words (and by "words" I mean words of bytes, not strings. Strings often are unaffected by endianness).

    Unless the system addresses individual bits, endianness can not possibly affect bits.

    That is, 5 << 1 is always 10 on little or big endian machines. And while you can extract the 32s bit of x with x & 32, you can't tell if it's the 5th bit or the 3rd, or where it is in the byte.

    The reason for big endian is obvious, we write numbers left to right. The reason for little endian is also obvious, just start adding two numbers together long-hand, and you'll see you naturally add right to left. But, really, it's just a memory loading convention, and before C fouled things up, most systems didn't let you address anything less than a word.

  • Paradice (unregistered)

    The fact that the "Indian" code returns a bool may be significant.

    Maybe the developer was working with language implementations that treated boolean values with different integer representations (maybe -1 vs 1 for 'true') and needed this to be consistent, and he/she confused this with the concept of endianness.

  • Damien (unregistered) in reply to Meep
    Meep:
    Abico:
    PiisAWheeL:
    Soaring Eagle:
    How many different byte orders are there? Middle-Indian?
    Think of a byte order as a string. You can only read it in 2 directions. Forwards and backwards.

    Or a better analogy is comparing little endian and big endian to written languages.

    Left to right vs right to left. 10110001 in 1 is the same as 10001101 in the other.

    Sort of. Endianness can operate at the bit level, but more typically, it affects the bytes of multi-byte words (and by "words" I mean words of bytes, not strings. Strings often are unaffected by endianness).

    Unless the system addresses individual bits, endianness can not possibly affect bits.

    That is, 5 << 1 is always 10 on little or big endian machines. And while you can extract the 32s bit of x with x & 32, you can't tell if it's the 5th bit or the 3rd, or where it is in the byte.

    The reason for big endian is obvious, we write numbers left to right. The reason for little endian is also obvious, just start adding two numbers together long-hand, and you'll see you naturally add right to left. But, really, it's just a memory loading convention, and before C fouled things up, most systems didn't let you address anything less than a word.

    Or, you know, any time the data is sent over a serial line. You have to agree which bit within the byte you're going to transmit first.

  • GlitchMr (unregistered)

    Obviously it isn't minified source code - it's obfuscated source code.

    Of course, they should minify the source code, not obfuscate it - some virus scanners see viruses in obfuscated files just because they're obfuscated.

  • Mark (unregistered) in reply to Shark8

    Gah! I'm at least pleased to find there is a name for this - SS7 signalling in Telco networks manages to use this type of ordering for some number parameters, e.g.

    21436587092103 will decode to 1234567890123 once the byte order is sorted out (the final "0" is ommited due to the length of number specified elsewhere).

    Drives me crazy at times, even though the tracing tool may decode it for you.

  • (cs)
    Article:
    /** convert from big indian to little indian:
Remove when not using legacy databases or Delphi code.*/
    Well, there's the problem. Indians (either big or little) are of course not used in Delphi code, but in Delhi code.
  • (cs)

    We always called them Big Indian and Little Indian in discussing network packets, but would always write endian.

    Dont forget Vax-endian (16 bit words little endian byte order but 32 bit would be made from high word then low word in increasing memory address) .

    And I have a macro used in a bit of software I wrote between 1996 and 2003 which had the ISNULLSTR(x) macro because sometimes you got null pointers and other times the string pointed at ended up empty.

    No specification - just fixed problems and challenges as they arrived. End result : 50000 lines of code (excluding comments). On inspection of this code I find I did the same thing at least three different ways in different parts of the code.

    It is so horrible that I turned down a three month placement in the USA to commercialise the tool into a product, because I knew it would take a lot longer to fix.

  • Janez (unregistered)

    Why is the best comment in the world here like a pic? I WANT TO COPY IT!!!

    :)

  • qbolec (unregistered)

    even PHP requires you to put a closing bracket after if condition

  • (cs) in reply to Meep
    Meep:
    But, really, it's just a memory loading convention, and before C fouled things up, most systems didn't let you address anything less than a word.
    Actually, the problem was always there at the machine-code/assembler level too. Fortunately, not too many write very much there these days; it's a niche that C has mostly taken over (and C is much easier to write than Asm for almost any program).

    Mind you, what's much weirder is where you've got C code built on systems where the smallest native-addressable unit is 32 bits in size (or more). That's where you get char* being larger than void*, to great confusion…

  • Iain (unregistered)

    Hmm, I remember filling in a census form last year.

    Well if it is the UK one then it was obviously not developed off-shore because you can't fault the language use in the comment.

  • d (unregistered) in reply to Soaring Eagle
    Soaring Eagle:
    How many different byte orders are there? Middle-Indian?
    There was the Random Endian format. It was not very popular
  • Chris (unregistered) in reply to Ol' Bob
    Ol' Bob:
    Thuktun:
    /// >summary<
/// Returns True if the input string is 
/// null, empty, "undefined", or "null".
/// >/summary<
/// String to check /// Boolean public static bool IsEmpty(string s) {
	return string.IsNullOrEmpty(s) || s == "undefined" || s == "null"; }
    Sadly, I've seen things like this necessary in the short term due to past bad programming. Million-row relational tables where someone has stored 'null' in some column instead of NULL and you have to fix a different bug immediately, but can't get approval to do a proper fix with database update.

    In other words, because Enterprisey.

    <snip>

    I'm confused - surely the Enterprisey solution would involve an anticorruption layer in front of the database server, so that null, "null", "", etc. would be standardized to whatever value the remote config service told it to use for a given client?

    ;-)

  • blank (unregistered) in reply to bgodot
    bgodot:
    Bits within a Byte do not have an order.

    A Byte is, by definition, the smallest addressable unit.

    assumption: obvious troll is obvious.

  • (cs)

    Endianness isn't always just about memory. I'm working with Photoshop PSD files, which are defined as Big-Endian.

  • Bozo (unregistered) in reply to Shark8

    What about Palindrom-endian?

    16.843.009 or 33.686.018 or 50.529.027 or ...

    (32-bit integers, of course)

  • (cs)

    Of course the Squirrel Club is secret - it's president is the most powerful hero of the Marvel Universe!

  • JJ (unregistered) in reply to Abico
    Abico:
    Endianness isn't always just about memory. I'm working with Photoshop PSD files, which are defined as Big-Endian.
    Huh? Endianness is 100% about memory. It's about the order that the bytes are stored...wait for it...in memory. (I'm assuming that by "memory" you really meant "storage medium.")
  • (cs) in reply to JJ
    JJ:
    Abico:
    Endianness isn't always just about memory. I'm working with Photoshop PSD files, which are defined as Big-Endian.
    Huh? Endianness is 100% about memory. It's about the order that the bytes are stored...wait for it...in memory. (I'm assuming that by "memory" you really meant "storage medium.")
    No, I meant memory; I'm saying that it may also be about storage media. What I was trying to say was, you don't have to be working close to the metal for endianness to bite you.
  • jay (unregistered) in reply to Abico
    Abico:
    jay:
    Abico:
    jay:
    In fairness, the "BigIndian" programmer (not Nagesh, I mean the programmer who used that name in his code) may have known the correct name and just been joking. I haven't done any research on this, but I strongly suspect that whoever invented the terms BigEndian and LittleEndian was thinking of the song "Ten Little Indians" and making a joke.
    Surprisingly, no. The terms come from Gulliver's Travels, in which wars are fought over which is the appropriate end to break an egg.

    Hmm, is that really where they got the name from, though? It's been a while since I read Gulliver's Travels, but I don't recall them calling the two sides "Big Endians" and "Little Endians". Not that the person who invented the computer terms couldn't have invented them based on Swift without his using those exact words.

    Here it is on Gutenberg. It looks like Big-Endian is explicitly used but not Little. So maybe it's actually a mashup joke?

    Yeah, I just happenned to look that up myself minutes before returning to this thread. You're 100% right. I learned something valuable today. Probably much more valuable than anything I've learned in weeks.

  • Spewin Coffee (unregistered)

    Dat gat has da bling in da end!

  • Major Douchebag (unregistered) in reply to JJ
    JJ:
    Abico:
    Endianness isn't always just about memory. I'm working with Photoshop PSD files, which are defined as Big-Endian.
    Huh? Endianness is 100% about memory. It's about the order that the bytes are stored...wait for it...in memory. (I'm assuming that by "memory" you really meant "storage medium.")

    And bits being transferred through a network? Not exactly what I'd call 'storage'.

  • DarrenC (unregistered)

    I'm just happy all the Indians can co-exist.

  • LC_ (unregistered)

    About the first one, I think I was doing ajax request with the jQuery dataTables plugin and it took me some debug time to understand that a value indicated as null in the request (and Firebug) was in fact a string, so in fact "null".

    Felt stupid afterward.

  • Matt (unregistered)

    Am I the only one who thinks the gun one is staged? There is the red underline on the method name, which sparks to me that it was renamed from "Get..." to "Gat..."

  • AndyB (unregistered) in reply to Abico
  • Snowman25 (unregistered) in reply to Cidolfas
    Cidolfas:
    The first one does not appear to be a WTF - in fact, the developer *is* covering all his/her bases by not only testing for null and undefined, but a real string whose contents are "null" or "undefined" - i.e. a victim of a bad concatenation. Might be an indication of WTFs elsewhere (or just oversights) but is not a WTF in itself.

    OR an application which lets the user set variables through text-boxes. Sadly, he didn't cover empty strings: ""

Leave a comment on “The Secret Squirrel Club, a Gun, and More”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article