• (cs) in reply to sir_flexalot

    sir_flexalot:
    This is the trouble with java programming books.  They talk all about sorts, arrays, etc. and so people think that you have to use sorts and arrays at all times.  Someone should really come up with a book that is like a reference, and it just has 1000 examples, like, "to do random numbers, do this..." and then the shortest, cleanest possible way to do it.  Maybe there'd be a chance that people would stop coding so much and get something done.

    There is no need for that. You have the sun tutorials and you have the API. They are thorough and contain all the info you need. You don't require any books for producing good and clean java code. They are just expensive and are basically a list of implementations that will be outdated in a few years anyway. It only comes down whether you can program or not, which IMHO is much more than understanding APIs and syntax - it's a matter of experience, talent and understanding of software design itself. Not even all the programming language related books in the world can help you there as soon as you learned the basics of a given language. I assume the person who wrote that code simply lacked the understanding of the topic and didn't read into it while thinking that XORing a bunch of seemingly "random" values will do the trick. I bet no book would have kept him from producing this wonderful WTF.

  • Milkshake (unregistered) in reply to sir_flexalot

    sir_flexalot:
    Someone should really come up with a book that is like a reference, and it just has 1000 examples, like, "to do random numbers, do this..." and then the shortest, cleanest possible way to do it.

    I use the Examplets from the Java Developer's Almanac: http://java.sun.com/developer/codesamples/examplets/index.html

  • E (unregistered) in reply to sir_flexalot

    So like the Perl Cookbook, then.

  • Kabdib the Younger (unregistered)

    As a starting point for getting entropy on a box, it's not that bad.  I wouldn't call this a WTF.  There are a few things that would come out in a good security review, but it's not nasty.  He should be mixing in other real-world environmental things, if possible, but the practical issue may be that his runtime is sandboxed to the point that getting real sources of entropy is hard.

    I'd redesign this to have an entropy sink of some kind that other callers could stuff values into (e.g., mouse movements, ticks when keypresses are made, etc.).  And to bar more than one call to this during the application's run (since it doesn't really measure stuff that's terribly different, run-to-run -- even the time is pretty predictable after a crash).

     

  • (cs) in reply to jaspax
    jaspax:
    Michael Casadevall:
    public static byte[] getRandomBits() {
    byte[] random = new byte[32];
    Random.nextBytes(random);
    return random;
    }

     

    There's a mistake here: nextBytes() isn't a static method, so you should probably have something like:

    private static Random random = new Random();
    public static getRandomBytes() {
        byte[] bytes =  new byte[32];
        random.nextBytes(bytes);
        return bytes;
    }

     I didn't know about the SecureRandom class--will remember that one.


    Random can take a seed value, if one wanted to throw the system time or some other (long) value in there...

    public static getRandomBytes() {
    Random random = new Random(new Date().getTime());
    byte[] bytes =  new byte[32];
    random.nextBytes(bytes);
    return bytes;
    }

    ...likewise I didn't know SecureRandom existed. Have used some pseudo-random number generators though.

     

     

  • Corporate Cog (unregistered) in reply to A Nonny Mouse
    Anonymous:

                                } // end for
                            } // end if hash_bytes
                        } // end if val non null
                    } // end if key non null
                } // end while e.hasMoreElements

     so THAT's what }'s do...!

    } // No idea where beginning of the block is.  Method's too big. 

  • Franz Kafka (unregistered) in reply to sir_flexalot

    sir_flexalot:
    This is the trouble with java programming books.  They talk all about sorts, arrays, etc. and so people think that you have to use sorts and arrays at all times.  Someone should really come up with a book that is like a reference, and it just has 1000 examples, like, "to do random numbers, do this..." and then the shortest, cleanest possible way to do it.  Maybe there'd be a chance that people would stop coding so much and get something done.

     

    Spoken like someone who's never heard of knuth. 

  • Bill (unregistered) in reply to Xandax

    I do the "comment at the end of a long loop" thing as well sometimes.  Mostly when writing python, which has no curlies.  And since we require tabs to be just two spaces, unless your font is large, it can sometimes get a little hard to tell where things are.

  • Random() (unregistered) in reply to biziclop

    biziclop:
    Btw, isn't anyone annoyed by the magic numbers in this code? Being a maintainer, reading "(nbytes + 7)/8 " or "for( int i = 512/8;..." drives me crazy.

    I personally don't consider all integer constants to be magic numbers, unless you really need to be able to handle the case where the number of bits in a byte will change.... The important differentiator for me is whether [or not] it is painfully obvious as to what the constant represents.

    As for 512, there's probably a constant somewhere that could have been used in it's place.

  • bramster (unregistered) in reply to sf
    Anonymous:
    biziclop:
    MichaelWojcik:
    Michael Casadevall:

    The function, getRandomBits() returns a 32-byte array of random bites for security purposes. Since Java provides a Random method, this should be easy...

    If this is in fact "for security purposes", then using Java's Random method would be as equally WTFy (and the five-line implementation is no more "correct" than the long one).

    There is no "correct" way to generate pseudorandom data.  That's a domain-dependent function; the PRNG has to meet the particular requirements of the task.  In this case, of course, we have no information on those requirements other than "for security purposes", but if that's at all accurate we have some reason to believe that Java's Random would be quite wrong as well.

    I rarely use Java, so my docs are well out of date, but I note that there at least used to be a java.security.SecureRandom, which at least claims to be suitable for some security purposes.

    But what this item shows is that security code shouldn't be written by non-experts - and that's so well established it can hardly be counted a WTF.

     

    I bet there was no requirement for the method to give identical numbers if called twice within a millisecond. 

    You'rre right about the SecureRandom part though, but using SecureRandom is  just as simple as using Random. SecureRandom not just claims to be suitable for security purposes, you can choose from a number of standard algorithms (sure, there is no perfect one, but at least the built-in providers are definitely compliant with the relevant standards) and I think there should be native SecureRandom providers that use specialized random generator hardware.

    SecureRandom is just a wrapper and delegates most of its work to an underlying "service provider" random generator.  So if you don't like what the generators that Sun ships you can write your own and just plug it in.

     You may not want to ask this guy though.

    A number of years ago, a person was able to beat the Keno machines in a Montreal, QC Casino.  I think he analyzed the play, and was able to determine which random number generator was being used, and what the seed was.

    I don't think the code-snippet is a WTF at all.  Byte Magazine, back in 1989, (May, I think), had a really good article about random-number generators, with code to show how to have three generators running at the same time, each with its own seed, and then combining the results.

    And of course, to really use random numbers effectively, one should be able to sort them. 

     

     

     

     

     

     

     

  • Calyth (unregistered) in reply to sf

    Had he actally created a good seed, he could probably implement a Blum-Blum-Shub PRBN, which cannot be broken nearly as easily as a typical linear congruential generator that's usually used in a rand function for most libraries.

    The WTF for me is that the only thing that might remotely change in the "generator" is the time, and he's even using a relatively collision prone hash function too. Heck, there are programs that would find second-preimages for MD5, and MD4 has been proven bad a long time ago AFAIK.

  • Hunter (unregistered)
    bits = new byte[(nbits + 7) / 8];
    So he adds 7 to nbits, then divides by 8, making the addition totally superfluous. This is of course assuming that the number of bits is actually an integer, but given some of the stuff I've seen here, I woudn't be surprised if he kept track of fractions of bits. :)
  • (cs) in reply to Kyuzo

    Anonymous:
    code that is twenty times more complex and introduces many new points of failure, while not being any more secure since it adds practically no entropy to the random data.

    ALthough I think that was the intention.  I'd have entitled this "Looking for entropy in all the wrong places"

  • Random() (unregistered) in reply to Hunter
    Anonymous:
    bits = new byte[(nbits + 7) / 8];
    So he adds 7 to nbits, then divides by 8, making the addition totally superfluous. This is of course assuming that the number of bits is actually an integer, but given some of the stuff I've seen here, I woudn't be surprised if he kept track of fractions of bits. :)

    Not quite: (nBits+7)/8 rounds to the next number of whole bytes; the addition is important to the implied integer rounding.

    In 25 years, I've never seen anyone do this for a fractional number of bits, but then, this is TDWTF!

  • (cs) in reply to Jeff
    Anonymous:

    Aaugh! Please tell me that none of you laughing at this WTF will ever write cryptography code (excepting those few who pointed out that the built-in Random is bad too.)

    This is the only way to produce a reasonably secure random number in software. Java.security.SecureRandom might be better, but guess how it works? By hashing together a bunch of system values, along with the time, a counter, recent mouse input, etc. And if the author of the snippet had some experience, he'd know to never trust the random functions that come with your library for crypto purposes, because they're usually crap. (The best thing to do would be to use java.security.SecureRandom, *and* all the stuff he's doing here, and hash those together.)

    For the most part, the WTF here, is that he's reinvented the wheel, poorly.  SecureRandom, on its own, is just as secure, if not more secure, than this poor imitation of SecureRandom. 

  • Rich (unregistered) in reply to Hunter

    In a previous life I was working on some stored procedures in MSSQL. The stored procedure would create a session ID using a whole bunch of rands one after the other. The problem was that we were getting session ID collisions very frequently considering that the session ID was a 32 byte character string. Turned out the code went something like

     

    seed (time)

    id=some_manipulation_of rand() 

    id+= some_manipulation_of rand()

    id+= some_manipulation_of rand() 

    id+= some_manipulation_of rand()

    id+= some_manipulation_of rand()

     

    The issue is that rand() on mssql server is/was 16 (actually 15) bit (32768 values). I wrote a user procedure that called the stdlib version rand (32 bit) to generate the ID but was told to take it out because there was nothing wrong with the original code. I couldn't convince my boss that because rand() was determinate, the above manipulations would never produce more than what would be obtainable from a single rand() (i.e 16 bit) and could actually make things worse. In the end, I ended up just having to check for collisions and issue a new if it was already taken. Just as long as we never had more than 32768 customers I guess... Thing is, the guy was not a WTF guy otherwise. I guess he was just emotionally invested in that function...

     

    Rich
     

  • diaphanein (unregistered) in reply to Hunter

    Seems to be a rather typical case of NIH:  http://en.wikipedia.org/wiki/Not_Invented_Here

  • JL (unregistered) in reply to Hunter
    Anonymous:
    bits = new byte[(nbits + 7) / 8];
    So he adds 7 to nbits, then divides by 8, making the addition totally superfluous.

    This is actually standard practice for controlling the rounding of integer math.  If you want to divide a positive integer x by some positive integer n rounded up, you do (x + n - 1) / n.  It's the integer equivalent of the floating point ceil(x / n) (if x and n were floating point values).

  • Rich (unregistered)

    And in Ruby, it'll work in one line:

    def getRandomBits; Array.new(32) { rand 256 } end

  • Zygo (unregistered) in reply to Rick
    Rick:
    Xandax:
    Anonymous:

    i like these in particular

                                } // end for
                            } // end if hash_bytes
                        } // end if val non null
                    } // end if key non null
                } // end while e.hasMoreElements

     so THAT's what }'s do...!

    Actually - I do some similar myself as it often helps my overview of the indentation, rather then having to trace an ending scope up to the starting point.

     

    I used to add these comments before the existence of modern* editors and IDEs that easily show the matching brace.

    *Less than 10 years old

     

    So emacs and vi are really both less than 10 years old, and not over 30 years old each as I thought they were?  

     

    I learn new things every day at this web site.  Not correct things, of course, but new ones... ;-) 

  • Hunter (unregistered) in reply to JL
    Anonymous:
    Anonymous:
    bits = new byte[(nbits + 7) / 8];
    So he adds 7 to nbits, then divides by 8, making the addition totally superfluous.

    This is actually standard practice for controlling the rounding of integer math.  If you want to divide a positive integer x by some positive integer n rounded up, you do (x + n - 1) / n.  It's the integer equivalent of the floating point ceil(x / n) (if x and n were floating point values).

    Ok, I get it now, I was only thinking of the fact that 7/8 with int division would be 0 in java, not about the the other cases where the addition puts the sum over the next multiple of 8.

    Can I have my first post stricken from the record? :) 

  • Franz Kafka (unregistered) in reply to Rick
    Rick:

    I used to add these comments before the existence of modern* editors and IDEs that easily show the matching brace.

    *Less than 10 years old

     

    Kids today... 

  • Tony (unregistered) in reply to A Nonny Mouse
    Anonymous:

    i like these in particular

                                } // end for
                            } // end if hash_bytes
                        } // end if val non null
                    } // end if key non null
                } // end while e.hasMoreElements

     so THAT's what }'s do...!

     

    I dunno about you, but I comment code like that whenever I can remember to, and God bless anyone else who does the same... it makes the job of maintaining the code INFINITELY easier...there are MANY wtfs in this code... commenting the end braces isn't one of them. 

  • (cs) in reply to Hunter

    The best way to get randomness, I have heard, is in hardware... have the software "listen" to the noise generated by a resistor and use that.

  • Kurt Nordstrom (unregistered) in reply to Whiskey Tango Foxtrot? Over.
    Whiskey Tango Foxtrot? Over.:
    Anonymous:

    i like these in particular

                                } // end for
                            } // end if hash_bytes
                        } // end if val non null
                    } // end if key non null
                } // end while e.hasMoreElements

     so THAT's what }'s do...!

    Not to start a flame war or anything..... :>..... but explaining which block the } ends is important if you do that lame-assed start-a-block-on-the-same-line-that-you-declare-it thing.

    You know....

    if(foo) {
    bar();
    }

    Preach it, mah brothah.  I hate having to read code that uses the aforementioned style of blocks.  Brackets should line up, goshdarnit.
     

  • (cs)

    the WTF here is all the commenters who don't realise this code is OK.

    This creates a random seed from all the available enthropy sources present. It is not meant to be called multiple times. Just at the beginning, to seed the random generator. (maybe re-seeding every hour...)

     

  • (cs)

    J.S. just made his application less secure.  Great job!

  • sf (unregistered) in reply to Rich
    Anonymous:
    And in Ruby, it'll work in one line:

    def getRandomBits; Array.new(32) { rand 256 } end

    You can do it in one line of Java too:

    public static byte[] getRandomBits() { byte[] rand = new byte[32]; random.nextBytes(rand); return rand; }

    :-)

  • (cs) in reply to Rich

    Anonymous:
     I couldn't convince my boss that because rand() was determinate, the above manipulations would never produce more than what would be obtainable from a single rand() (i.e 16 bit)  

    Actually, I don't think that is true.

    Your contension seems based on the idea that the value returned by one call is used as the seed for the next, so that if 12345 is followed by 23456, then that sequence will always appear in order in the values returned by rand(), with the only effect of the seed being when that sequence appears.

    But I doubt that is the case.  Having looked at the code, I can say that it's not the case for .Net Random object. (I don't have the source code for SQL's rand() available, so I can't say for sure)

    So, 12345 may be followed by 23456 given one seed, and 34567 given another, then that code can produce more that 32768 different values --- granted, probably only 32768 * 5 different values, but that's still more.

    Also, that assumes that all calls to rand() are done 5 at a time.  If there's a single call to rand() elsewhere then that changes the sequence and you get another 32768 * 5.

  • (cs)

    At first I was like "Ok, someone reinvented a random funciton. Maybe they needed data that was more random than what the hardware generator was using or something..." Then I scrolled down the code.... Oh my god. What the hell was this person thinking? Do you get paid by the line? Even if pay was by line this is probably the worst implementation of a random function ever. I won't go into details, nor do I care to even think about them, but the data generated by this isn't really even that random. This is an abomination of code.

  • (cs) in reply to sf
    Anonymous:

    public static byte[] getRandomBits() { byte[] rand = new byte[32]; random.nextBytes(rand); return rand; }

    Well, assuming that "random" is a properly seeded static instance of the Random class, then the C# version is identical, except one letter would need to be capitalized.

  • sf (unregistered) in reply to Kurt Nordstrom

    Preach it, mah brothah.  I hate having to read code that uses the aforementioned style of blocks.  Brackets should line up, goshdarnit.
     

    All Bracket-Liner-Uppers are going to hell.  ;->

  • sf (unregistered) in reply to tegla
    tegla:

    the WTF here is all the commenters who don't realise this code is OK.

    This creates a random seed from all the available enthropy sources present. It is not meant to be called multiple times. Just at the beginning, to seed the random generator. (maybe re-seeding every hour...)

     

    What are all of the available entropy sources in question?  He's just hashing the values of the system properties and then using the current time.  The values of the System properties rarely, if ever, change during the execute of the VM, and are likely to be the exact same values every time the VM is run.  The only source of entropy is the current time, which is a weak source. 

    Remember, the System properties are like environmnet variables in the VM.  They contain things like the classpath, platform specific values (OS name, file separator char, etc.), and command-line parameters.

  • (cs) in reply to tegla
    tegla:

    the WTF here is all the commenters who don't realise this code is OK.

    This creates a random seed from all the available enthropy sources present.

    But, what you don't seem to be realizing is that most of these "entrophy sources" aren't presenting any entrophy.  Most of what he starts with is the bytes of the ASCII representations of "key + val" for the system properties --- where "val" changes little, and "key" doesn't change at all.  He then tossing in the time, but he's using currentTimeMillis, which is the time, in milliseconds, from 1-Jan-1970, which means, an hour from now, most of the bits will still be the same.

  • (cs)
    Michael Casadevall:
    public static byte[] innerGetRandomBits() {
    int pos = 0;
    int iters = 0;

    bits = new byte[(nbits + 7) / 8];

    I like this part of the code. I'm amazed that I didn't notice anybody else to have yet mentioned it:

    The bits array is not introduced as a local variable, so there must be a class field "private static byte[] bits;" in this class, which makes the outcome of this method actually quite random in a multithreaded environment.

  • (cs) in reply to Michael Casadevall
    Michael Casadevall:
    When I was going through the queue, it was the one that jumped out at me, because the guy knows how to do things like read Java configurations, but doesn't know Random().

    I think that might be an incorrect assumption. I think it's far more likely the author of the very long segment heard something about the phenomenon described at http://alife.co.uk/nonrandom/ and took it to heart...

    Nonetheless, it's still a WTF. Firstly, the author doesn't appear to have paused to consider whether, nonrandomness aside, Random() is in fact sufficiently random for the application concerned. Secondly, it seems to me that his version will in fact be considerably less random than the "problematic" Sun version...

    One more demonstration that a little knowledge is a dangerous thing.
     

     

  • (cs) in reply to tegla
    tegla:

    the WTF here is all the commenters who don't realise this code is OK.

    This creates a random seed from all the available enthropy sources present. It is not meant to be called multiple times. Just at the beginning, to seed the random generator. (maybe re-seeding every hour...)

    That being the case, it's still arguably (a) over-engineered, and (b) unlikely to be very entropic.
     

  • JB (unregistered)

    It would be very funny if this code is indeed a replacement of the java Random class for security reasons, and the software gets hacked because some maintainer has replaced the improved version with the suggested five-liner. THAT would really make a top scorer on this site.

  • Duc (unregistered) in reply to Xandax
    Xandax:
    Anonymous:

    i like these in particular

                                } // end for
                            } // end if hash_bytes
                        } // end if val non null
                    } // end if key non null
                } // end while e.hasMoreElements

     so THAT's what }'s do...!

    Actually - I do some similar myself as it often helps my overview of the indentation, rather then having to trace an ending scope up to the starting point.

     

    Umm, a good IDE should do actually.
  • Rich (unregistered) in reply to JamesCurran
    JamesCurran:

     

    Actually, I don't think that is true.

    It is. 

    JamesCurran:

    Your contension seems based on the idea that the value returned by one call is used as the seed for the next, so that if 12345 is followed by 23456, then that sequence will always appear in order in the values returned by rand(), with the only effect of the seed being when that sequence appears.

    It did. I tested it. I also found that there was a smaller range than the full 32768 values.

    JamesCurran:

    But I doubt that is the case.  Having looked at the code, I can say that it's not the case for .Net Random object. (I don't have the source code for SQL's rand() available, so I can't say for sure)

    It wasn't .net. It wasn't c. It wasn't a cosmic ray detector wired to the serial port. It was MSSQL server. Version 5 if I recall correctly. 


  • (cs) in reply to DWalker59

    DWalker59:
    The best way to get randomness, I have heard, is in hardware... have the software "listen" to the noise generated by a resistor and use that.

    Or a noise diode. I'm honestly amazed that there aren't noise generator / sampler circuits routinely included in machines. I suppose the issue is whether analogue noise is sufficiently random...? (I'm not prepared to accept that cost is significant; we're talking about a latch, a comparator and a diode.)

  • Anon (unregistered) in reply to Rootbeer
    Rootbeer:

    "so THAT's what }'s do...!"

    You'll notice that '}' is in fact an overloaded operator; sometimes it ends an 'if' block, sometimes it ends a 'for' block, sometimes a 'while' block... and that's just in this one code snippet!

    It's entirely appropriate to add comments clarifying their usage.

     

    If by appropriate you meant "pointless" then I totally agree.

    This post was brought to you by the letters I, D and E.

     

  • Rich (unregistered) in reply to JamesCurran
    JamesCurran:

    Your contension seems based on the idea that the value returned by one call is used as the seed for the next, so that if 12345 is followed by 23456, then that sequence will always appear in order in the values returned by rand(), with the only effect of the seed being when that sequence appears.

    And in fact, that is typically the case for pseudo-random numbers. Though the number returned may not actually be the seed itself, it will depend on the seed.

     If you restrict the range, you may appear to have numbers that aren't repetetive but you will still be caught by the number of bits the seed holds. A 16 bit seed limits you to 65536 values however you slice it. In the case of mssql server, this was actually much less.

     

    Mathematically, you could write it

    f(g1(x),g2(x+1),g2(x+2)...) == j(x)
     

    Since x is limited to 2^16 values and f and g and j are deterministic, it doesn't matter what you do to munge them around, you're still limited.

     

    Now, if you get lucky and through threading or other multitasking some function happens to also call rand() in the middle of your five-in-a-row rand() calls and updates the seed, you might get a new value. But if your system is calling rand() often enough that that would make any real difference, you probably need a redesign (not to mantion that that is an action-at-a-distance WTF in itself). Throwing in some entropy is a good bet too.

     

    Rich 

  • Rich (unregistered) in reply to Anon
    Anonymous:

    If by appropriate you meant "pointless" then I totally agree.

    This post was brought to you by the letters I, D and E.

     

    An IDE is not always available or appropriate. Still, why comment anyway, it's going to work first time, right?

     

    Rich 

  • fivetrees (unregistered) in reply to Whiskey Tango Foxtrot? Over.
    Whiskey Tango Foxtrot? Over.:
    Anonymous:

    i like these in particular

                                } // end for
                            } // end if hash_bytes
                        } // end if val non null
                    } // end if key non null
                } // end while e.hasMoreElements

     so THAT's what }'s do...!

    Not to start a flame war or anything..... :>..... but explaining which block the } ends is important if you do that lame-assed start-a-block-on-the-same-line-that-you-declare-it thing.

    You know....

    if(foo) {
    bar();
    }

    Absolutely right. The opening-brace-on-the-same-line made sense in the days of printed listing - not any more. (And for consistency, one should put the closing brace at the end of the final line of code, right?)

    For Xmas, give yourselves braces that line up, and no closing "this is what this brace does" comments - if it really needs them, the block is too long, so break it down further. And ho ho ho.

    Steve

    captcha: pizza. yum.

  • PseudoNoise (unregistered) in reply to fivetrees
    fivetrees:

    Absolutely right. The opening-brace-on-the-same-line made sense in the days of printed listing - not any more. (And for consistency, one should put the closing brace at the end of the final line of code, right?)

    For Xmas, give yourselves braces that line up, and no closing "this is what this brace does" comments - if it really needs them, the block is too long, so break it down further. And ho ho ho.

    Steve

    captcha: pizza. yum.

     We still do code reviews here with printed listings.  We have some online code review type applications, but they've never taken hold.

     So when printing out functions, even if they're small, they'll often go across page breaks.  It's very handy to have the end-brace comment.  Also, when modifying code, sometimes it can be easy to get lost (as with the 5 closing braces in the example) for somebody to maintain.

    Count me on the "comments are never bad unless they're wrong or misleading" side of this jihad.

     

  • (cs) in reply to fivetrees
    Anonymous:
    Whiskey Tango Foxtrot? Over.:

    Not to start a flame war or anything..... :>..... but explaining which block the } ends is important if you do that lame-assed start-a-block-on-the-same-line-that-you-declare-it thing.

    You know....

    if(foo) {
    bar();
    }

    Absolutely right. The opening-brace-on-the-same-line made sense in the days of printed listing - not any more. (And for consistency, one should put the closing brace at the end of the final line of code, right?)

    For Xmas, give yourselves braces that line up, and no closing "this is what this brace does" comments - if it really needs them, the block is too long, so break it down further. And ho ho ho.

    Steve

    captcha: pizza. yum.

    I know I certainly enjoy only being able to see half the code on the page in flurries of block open/closes. Why, it's like traveling back to DOS days! ... Indentation matters much more for readability than brace position ever does - and I'm not even a python user, it should just be obvious. If you don't indent well, no amount of braces will ever save you, and if you indent well, it'll be obvious at a glance what matches what.

    Anonymous:
    Anonymous:
    And in Ruby, it'll work in one line:

    def getRandomBits; Array.new(32) { rand 256 } end

    You can do it in one line of Java too:

    public static byte[] getRandomBits() { byte[] rand = new byte[32]; random.nextBytes(rand); return rand; }

    :-)

    That's because you can do this in one line in every language. Geez.

     

  • (cs) in reply to Moosey
    Anonymous:

    "Without further to do"?!  Jesus.  This site alone could be fodder for a linguistic WTF blog.


    Maybe since he'd already used the phrase "to do" twice, he was saying that was enough of them. But then the code contains a "to do" so that can't be it.
    I know, since he's provided a 4-line alternative, there's nothing left to do!
  • (cs) in reply to Random()
    Anonymous:

    In 25 years, I've never seen anyone do this for a fractional number of bits, but then, this is TDWTF!

    Cryptography, compression, networking, and audio/visual encoding almost always works on bits instead of bytes. (Thus it's called a bitstream, with bitrates, and so on.) It's just another way of seeing the same data, of course, but it gives you far more flexibilty when you're trying to squeeze every superfluous bit out of the stream.

  • (cs) in reply to fivetrees

    For a stack of closing braces, I agree, comments are a good idea.

    Of course, if you have a stack of closing braces, the WTF isn't the commenting.
     

Leave a comment on “Random Ways To Get To Random()”

Log In or post as a guest

Replying to comment #:

« Return to Article