• RandomGuy (unregistered)

    private static final byte [] FRIST = { (byte)'f', (byte)'r', (byte)'i', (byte)'s', (byte)'t' };

  • XXXXXX (unregistered)
       private static final byte [] TRUE = {
          (byte)'t', (byte)'r', (byte)'u', (byte)'e'
       };
       private static final byte [] FALSE = {
          (byte)'f', (byte)'a', (byte)'s', (byte)'l', (byte)'e'
       };
       private static final byte [] FILE_NOT_FOUND = -1;
    
       public static byte [] toAsciiBytes(boolean v) {
           if (random() < 0.0001) return FILE_NOT_FOUND;
           return v ? TRUE : FALSE;
       };
    

    How can you not code for a tri-state boolean in this day & age?

  • Nagesh (unregistered)

    Yeah, initializing the static constants as "true".getBytes("US-ASCII") and "false".getBytes("US-ASCII") might have been somewhat clearer. But does it rise to the level of a WTF?

    Whether having a function that does what this one does is reasonable in a larger context, and whether the microoptimization of returning static arrays rather than allocating a new one for each call is worth the slight loss of readability, that's a different matter -- but one that is impossible to judge without knowing something about what the function was used for.

  • Stev (unregistered) in reply to Nagesh
    Nagesh:
    Yeah, initializing the static constants as "true".getBytes("US-ASCII") and "false".getBytes("US-ASCII") might have been somewhat clearer. But does it rise to the level of a WTF?

    Whether having a function that does what this one does is reasonable in a larger context, and whether the microoptimization of returning static arrays rather than allocating a new one for each call is worth the slight loss of readability, that's a different matter -- but one that is impossible to judge without knowing something about what the function was used for.

    Impossible to judge? How about the fact that he's spelled "false" wrong? The fact that he's done this in such a way that it's POSSIBLE for false to not be false kind of shows that it really is a WTF.

  • BoonDocs (unregistered) in reply to Nagesh

    Sorry, you're working off a completely fasle premise here

  • (cs) in reply to Stev
    Stev:
    ...it's POSSIBLE for false to not be false
    You have to be impressed by that feat in and of itself (isn't that somewhat PHP-esque?)

    Think of the possibilities!

  • pantsman (unregistered) in reply to Nagesh
    Nagesh:
    Yeah, initializing the static constants as "true".getBytes("US-ASCII") and "false".getBytes("US-ASCII") might have been somewhat clearer. But does it rise to the level of a WTF?

    Whether having a function that does what this one does is reasonable in a larger context, and whether the microoptimization of returning static arrays rather than allocating a new one for each call is worth the slight loss of readability, that's a different matter -- but one that is impossible to judge without knowing something about what the function was used for.

    You for got to un-Nagesh before posting a serious comment...

  • Tom Hawtin (unregistered) in reply to Stev

    Well we can fix that.

    toAsciiByte(false)[3] = (byte)'l';
    toAsciiByte(false)[4] = (byte)'s';

  • Nagesh (unregistered) in reply to Stev
    Stev:
    Impossible to judge? How about the fact that he's spelled "false" wrong? The fact that he's done this in such a way that it's POSSIBLE for false to not be false kind of shows that it really is a WTF.
    I didn't notice the spelling error. I probably wouldn't have spotted it in "fasle".getBytes() either.

    But still, a spelling error in the implementation does not tell anything about whether or not there's a good reason to want a method that produces a human-readable ascii representation of the value as bytes, or whether it is called so often that sharing the return values is worth the trouble.

  • Timo (unregistered)
       private static final byte [] FALSE = {
          (byte)'f', (byte)'a', (byte)'s', (byte)'l', (byte)'e'
       };
    

    fasle?

  • Migala (unregistered) in reply to pantsman
    pantsman:
    Nagesh:
    ...

    You for got to un-Nagesh before posting a serious comment...

    No he didn't

  • Your Name (unregistered)
    Remy Porter:
    How much do you want to bet that the developer responsible for this code started their career as a C programmer?

    That's a little generous. I'm thinking they're a D- programmer, at best.

  • Embiggen (unregistered)

    As usual with Remy articles, it gets even more absurd if you view source:

    (byte)'t', (byte)'r', (byte)'u', (byte)'e'

    All that to say "true"? WTF!

  • MrBester (unregistered) in reply to XXXXXX

    I'll see your tri-state boolean and raise you another two: MsoTriState Enumeration

    Akismet may be right occasionally.

  • (cs) in reply to XXXXXX
    XXXXXX:
    How can you not code for a tri-state boolean in this day & age?

    -1 is not a byte array! >:(

  • (cs) in reply to MrBester
    MrBester:
    I'll see your tri-state boolean and raise you another two: MsoTriState Enumeration

    Akismet may be right occasionally.

    That is so beautiful. They even know it: "To use the MsoTriState enumerations in a WSF job, ..."

  • Eric Johansson (unregistered)

    Since you're all complaining about spelling errors in the implementation, I'll just leave you with HELO. Oh, and don't go anywhere NEAR the old DirectConnect protocol...

  • le troll supérieure (unregistered) in reply to The MAZZTer
    The MAZZTer:
    XXXXXX:
    How can you not code for a tri-state boolean in this day & age?

    -1 is not a byte array! >:(

    Discrimination against negative numbers in this day and age! Go burn in the middle ages you fool.

  • Guybrush Threepwood (unregistered)

    The real WTF is the missing constant for FILE_NOT_FOUND.

  • Henry R (unregistered)

    Sir, your comments are "fasle"

  • someguy (unregistered) in reply to RandomGuy
    RandomGuy:
    private static final byte [] FRIST = { (byte)'f', (byte)'r', (byte)'i', (byte)'s', (byte)'t' };

    Had you read the article a little closer, you would have known that it should go more like this-

    private static final byte [] FRIST = { (byte)'f', (byte)'i', (byte)'r', (byte)'s', (byte)'t' };

  • Zog (unregistered)

    I think this can be filed safely under "job security"...if it wasn't done in the name of job security then I'd very very very afraid because there is the chance that the person who wrote that doesn't work there anymore....

  • annonomous (unregistered) in reply to Your Name

    Thats just awesome.

  • AGray (unregistered)

    I honestly don't think a C developer would do something like that. Wow.

  • (cs)

    Not one person here has asked the obvious question (well, obvious to me, anyway):

    Why the blue blazes do they return byte arrays rather than character arrays or even just plain old strings?

  • (cs)

    Poor baby wanted to simulate a C string.

  • (cs)

    Ow! I think I just had a mini-stroke reading that code.

  • (cs) in reply to Embiggen

    It's inelegant source, but it has certain advantages over a JavaScript source highlighter (like working in RSS readers). It's still an automated tool- you couldn't pay me to write code like that.

  • (cs) in reply to Melnorme
    Melnorme:
    Poor baby wanted to simulate a C string.

    Poor baby didn't NULL-terminate his simulated C string.

    Must be an optimization. This way the output is up to 20% smaller!

  • jay (unregistered) in reply to Nagesh
    Nagesh:
    Yeah, initializing the static constants as "true".getBytes("US-ASCII") and "false".getBytes("US-ASCII") might have been somewhat clearer. But does it rise to the level of a WTF?

    Whether having a function that does what this one does is reasonable in a larger context, and whether the microoptimization of returning static arrays rather than allocating a new one for each call is worth the slight loss of readability, that's a different matter -- but one that is impossible to judge without knowing something about what the function was used for.

    I never thought I would put these words together in a sentence, but Nagesh is right. Without knowing how or where this function is used, how can we say whether it's a good function to have or not?

    Yes, it would have been a lot easier to read if he had used getBytes. I'm guessing the writer wasn't familiar with that function. But that's a pretty minor issue.

    The bigger question is, what does he use these byte arrays for? If he passes booleans between functions as byte arrays and tests them by comparing the bytes, that's stupid. But if, say, he does this because he's passing booleans to another system and that system's API requires a byte array, what else is he supposed to do?

  • Trollinator (unregistered)

    TRWTF is Java in that an idiomatic implementation isn't even much shorter than the implementation in the article due to checked exceptions.

      public static byte[] toAsciiBytes(boolean v) {
        try {
          return Boolean.valueOf(v).toString().getBytes("US-ASCII");
        } catch (java.io.UnsupportedEncodingException e) { 
          return null;
        }
      }
    
  • Nagesh (unregistered) in reply to Trollinator
    Trollinator:
    TRWTF is Java in that an idiomatic implementation isn't even much shorter than the implementation in the article due to checked exceptions
    Hmm, right. That arguably justifies the character-for-character initialization, if we take as given that we want to allocate the canonical return values statically. Dealing with checked exceptions at static initialization time is a real PITA.
  • (cs) in reply to pantsman
    pantsman:
    Nagesh:
    Yeah, initializing the static constants as "true".getBytes("US-ASCII") and "false".getBytes("US-ASCII") might have been somewhat clearer. But does it rise to the level of a WTF?

    Whether having a function that does what this one does is reasonable in a larger context, and whether the microoptimization of returning static arrays rather than allocating a new one for each call is worth the slight loss of readability, that's a different matter -- but one that is impossible to judge without knowing something about what the function was used for.

    You for got to un-Nagesh before posting an obvious troll...

    FTFY

    (Actually, we have a grammatically-correct Nagesh here, and I think that's who you replied to.)

  • A. Nonymous (unregistered) in reply to Nagesh
    Nagesh:
    Yeah, initializing the static constants as "true".getBytes("US-ASCII") and "fasle".getBytes("US-ASCII") might have been somewhat clearer. But does it rise to the level of a WTF?
    TFTFY
  • Fyrilin (unregistered) in reply to Embiggen
    Embiggen:
    As usual with Remy articles, it gets even more absurd if you view source:

    (byte)'t', (byte)'r', (byte)'u', (byte)'e'

    All that to say "true"? WTF!

    Ah the MS Frontpage! It burns!

  • justsomedudette (unregistered) in reply to Nagesh
    Nagesh:
    Yeah, initializing the static constants as "true".getBytes("US-ASCII") and "false".getBytes("US-ASCII") might have been somewhat clearer. But does it rise to the level of a WTF? <snip/> -- but one that is impossible to judge without knowing something about what the function was used for.
    Well there's your WTF. Comments aren't just for explaining the code, the rational behind it is often far more important.
  • Pluvius (unregistered) in reply to Eric Johansson
    Since you're all complaining about spelling errors in the implementation, I'll just leave you with HELO.

    Or the HTTP header Referer.

  • (cs) in reply to Melnorme
    Melnorme:
    Poor baby wanted to simulate a C string.

    At least he/she didn't simulate a g-string

    (Sorry couldn't resist)

    Yours Yazeran

    Plan: To go to Mars one day with a hammer

  • (cs) in reply to Tom Hawtin
    Tom Hawtin:
    Well we can fix that.
        toAsciiByte(false)[3] = (byte)'l';
        toAsciiByte(false)[4] = (byte)'s';

    Come on! You just made ['t','r','u','e'] into ['t','r','e','u']!! What kind of fix is that?

  • (cs) in reply to Pluvius
    Pluvius:
    Since you're all complaining about spelling errors in the implementation, I'll just leave you with HELO.

    Or the HTTP header Referer.

    HELO makes sense: All the SMTP commands were deliberately made to be 4 characters. Other examples are RCPT, VRFY, and EXPN.

    "Referer" was just a spelling error.

  • (cs) in reply to snoofle
    snoofle:
    Stev:
    ...it's POSSIBLE for false to not be false
    You have to be impressed by that feat in and of itself (isn't that somewhat PHP-esque?)

    Think of the possibilities!

    Well, it's really only a manifestation of the quantum state of FALSE. There's a finite probability that FALSE can escape its quantum well and 'jump' to a new, LESS_FALSE state.

  • Matt (unregistered)

    The best part: They misspelled 'FALSE'

  • (cs) in reply to jay
    jay:
    The bigger question is, what does he use these byte arrays for? If he passes booleans between functions as byte arrays and tests them by comparing the bytes, that's stupid. But if, say, he does this because he's passing booleans to another system and that system's API requires a byte array, what else is he supposed to do?
    He should borrow snoofle's cluebat and pay a visit to the maintainers of the other system. He should also visit the system's designers and whoever hired them.
  • RedundantPost (unregistered)

    Hey did anyone notice they spelled "false" wrong yet?

  • UnnecessaryResponse (unregistered) in reply to RedundantPost
    RedundantPost:
    Hey did anyone notice they spelled "false" wrong yet?
    Yes.
  • Set (unregistered)

    TRWTF is a Remy article without a hidden cornify link.

  • n_slash_a (unregistered)

    or, in c++

    bool flag = true; cout << boolalpha << flag << endl;

    If you really wanted a string, then use stringstream.

  • Sam I am (unregistered)

    So the guy implemented a ToString on booleans.

    now, Of course it's not the most graceful way in the world to do it, but it's not WTF degrees of ungraceful

  • (cs) in reply to Trollinator
    Trollinator:
    TRWTF is Java in that an idiomatic implementation isn't even much shorter than the implementation in the article due to checked exceptions.
      public static byte[] toAsciiBytes(boolean v) {
        try {
          return Boolean.valueOf(v).toString().getBytes("US-ASCII");
        } catch (java.io.UnsupportedEncodingException e) { 
          return null;
        }
      }
    
    public static byte[] toAsciiBytes(boolean v) {
      return Boolean.valueOf(v).toString().getBytes(Charset.forName("US-ASCII"));
    }

    I made it shorter just for you :)

  • Tasty (unregistered) in reply to Nagesh
    Nagesh:
    Stev:
    Impossible to judge? How about the fact that he's spelled "false" wrong? The fact that he's done this in such a way that it's POSSIBLE for false to not be false kind of shows that it really is a WTF.
    I didn't notice the spelling error. I probably wouldn't have spotted it in "fasle".getBytes() either.

    But still, a spelling error in the implementation does not tell anything about whether or not there's a good reason to want a method that produces a human-readable ascii representation of the value as bytes, or whether it is called so often that sharing the return values is worth the trouble.

    That may be the reason it's implemented. Some service provider sends bytes over a socket, misspelled "false", and now this Tomcat service has to read it.

    Not all WTFs are local!

Leave a comment on “A Byte of Booleans”

Log In or post as a guest

Replying to comment #:

« Return to Article