• (cs) in reply to KenW
    KenW:
    brazzy:
    You have no idea how possible that is. For starters, you cannot accurately represent decimal fractions in a binary floating point variable AT ALL! Store 0.1, read it out again and you'll get something like 0.099999986

    Ummm. Wrong. If you store 0.1, you most definitely do not get 0.99999986. If you did, it would be totally impossible to do floating point math on the computer, as numbers would be off by an enormous amount.

    You might get something more like 0.099999986 (note the '0' immediately to the right of the decimal point?)

    Yup. Apparently you did NOT note it, though. If I were you, I'd have my glasses checked immediately...
  • JohnB (unregistered) in reply to vt_mruhlin
    vt_mruhlin:
    Error message: "Your username or PIN is invalid. Your username must be at least 5 characters long, must have at least one capital letter, must have at least one digit, must not contain the following characters: ' " ? / ! - + = Your PIN must be four digits long, must contain only numbers, must not be a consecutive run of numbers (i.e. 1234, 4321), must not resemble a year (i.e. 1983), must not be the same digit repeated consecutively (i.1. 4444)"

    I haven't noticed anybody else point out "the real WTF" (TM) here. The idea of a 4-digit pin is to provide for 10,000 possibilities (0000 through 9999 inclusive).

    "Not resemble a year" eliminates at least 1000 elements (1000 through 1999 inclusive) or possibly 1100 (1000 through 2099).

    Eliminating consecutive runs (0123, 3210, 2345, 5432, 3456, 6543, 4567, 7654, 5678, 8765, 6789, 9876), takes out 12 possibilities. Eliminating repetitions (0000, 2222, 3333, 4444, 5555, 6666, 7777, 8888, 9999) further reduces the available pool.

    While the pool is still greater than 8800 possibilities, it still makes a significant reduction if a brute force attack is used.

    But, if we're going to accept the bank's constraints, then surely they should reject four digits matching the user's birthday (either MMDD or MMYY or a permutation thereof), the last four digits of the user's phone, a correspondence between the pin and the street number ...

  • (cs) in reply to tobhsals
    tobhsals:
    real_aardvark:
    If necessary, the database will bounce the insert.

    Is that the way it works?

    I have, in the past, actually been stopped from putting any kind of data validation in the database. Everything was a varchar with checking mixed between the javascript and PHP.

    Well, yes. I missed out the "In principle..." bit.

    However, what you have here (copyright "Cool Hand Luke") is a serious failure to communicate. Not, per se, a database issue.

    And what you have here is also the sort of shoddy architectural thinking that leads the cretin on the javascript end to resort to a WTF such as the original post.

    It ain't a cure: it's a symptom of the disease.

  • (cs) in reply to AdT
    AdT:
    Bob:
    Spoe:
    What language doesn't has a regex library available these days?

    The readable, maintainable ones.

    Oh, please, elaborate. Name some readable, maintainable programming languages that do not have a regex library available.

    Bob, I assume, is not registered. (Can't be bothered to check.) Bob is demonstrably wrong.

    But a bigger question is: how much use is a regex library in a reliable, maintainable, language?

    At an even higher (design) level, are you sure that you're not just using regex to slap a band-aid over something that could be solved at a more appropriate architectural level?

  • AdT (unregistered) in reply to real_aardvark
    real_aardvark:
    At an even higher (design) level, are you sure that you're not just using regex to slap a band-aid over something that could be solved at a more appropriate architectural level?

    Regexes are often used in this way. But in this case, the input probably comes from an ordinary textbox (HTML INPUT element). To my awareness, there aren't many alternative ways to obtain currency input from a browser user via HTML. If a web interface is the only way to meet some other requirements (e.g. no installation), then you have to work with those constraints. And at some point, the key strokes to currency value translation will have to happen in any case.

  • (cs)

    It's absolutely scary how many posts down you have to go before someone mentions that the routine doesn't even work right - it has a funny definition of INT.

  • Steve (unregistered) in reply to dkf
    dkf:
    Spoe:
    What language doesn't has a regex library available these days?
    Brainf*ck.

    yeah it does

    !!!!!!!!(#&$(_#&$(@&()@#+)))))))))@#@#&@)($&()@&)%@!@!!!!!@()$+@$*())Q%&()%@(()(&*!!!!!!!!!!!!!

    would match "my dick is huge"

  • Steve (unregistered) in reply to dphunct
    dphunct:
    Spoe:
    ^\$-?[:digit:]*\.[:digit:]{2}$ anyone?

    What language doesn't has a regex library available these days?

    lotusscript (unless you steal VB's)

    buddy, you need a new job

  • FreekV (unregistered) in reply to Bob

    Yeah right, pages of code are more easily readable than a simple regex you can scan over in a blink of an eye. Regexes do make code more maintainable and readable.

  • (cs) in reply to vt_mruhlin
    vt_mruhlin:
    savar:
    "This field is required, and the format should be $xxx.xx."

    Anything wrong with that?

    Just don't get carried away. Signing up for bank account the other day... Username: vt_Mruhlin25 PIN: 10** //I'm not going to give you ALL the digits, but the first two are relevant!

    Error message: "Your username or PIN is invalid. Your username must be at least 5 characters long, must have at least one capital letter, must have at least one digit, must not contain the following characters: ' " ? / ! - + = Your PIN must be four digits long, must contain only numbers, must not be a consecutive run of numbers (i.e. 1234, 4321), must not resemble a year (i.e. 1983), must not be the same digit repeated consecutively (i.1. 4444)"

    After double checking everything, I determined that I violated the "must not look like a year" rule. Apparently the eleventh century has a special meaning in my life, and everybody knows that.

    / I have no idea how you could say that ANY integer doesn't look like a year though...

    That (assuming "look like a year" is for the first digit being 1) reduces the keyspace to 8978 - which is 13.13 bits. a keyspace of 10000 is only 13.29 bits. So you've lost a sixth of a bit. Not bad, compared to most password rules.

  • Cloak (unregistered) in reply to tobhsals
    tobhsals:
    real_aardvark:
    If necessary, the database will bounce the insert.

    Is that the way it works?

    I have, in the past, actually been stopped from putting any kind of data validation in the database. Everything was a varchar with checking mixed between the javascript and PHP.

    OhhhhhhhMG!

  • (cs) in reply to lovedumplingx
    lovedumplingx:
    I wonder if this is really a WTF and not the request from some crazy client. I had a project recently where the client was not satisfied with generic error messages and we needed to get much more in depth with what errors were being generated.

    SMACK that client. How dare programmers quibble about preferred data entry style. No bloody way I'd enter the $. If they are so anal about the entry, reformat for the user and ask to verify it's what they wanted.

  • (cs) in reply to FreekV
    FreekV:
    Yeah right, pages of code are more easily readable than a simple regex you can scan over in a blink of an eye. Regexes *do* make code more maintainable and readable.
    If you truely were able to "scan over" AND UNDERSTAND a non-trivial regexp in "a blink of an eye", I would bow down to your superior intellect. Only I don't believe you can do that.

    Regexps by themselves are extremely unreadable and badly maintainable. Their brevity does have a certain value, but as a maintainance programmer I actually would rather have pages of code than an uncommented regexp like this:

    /(/||.)(?:ad(image|page|peeps|s(erver|manager)?|vert.{0,8}|vo|x)?|(affiliatewiz|banner(exchange|s)?|counters?|(online|php|popup)ads?(new)?|popunders?|sponsors?))\d{0,2}\1|\D(468[x]60|125x300|728x90)\D|[^]banner[^_]*.(?:gif|jpg)$|/(?:ad|popup).(?:js|swf)$|_468[^/].gif$|^.{5,6}/{2}[^/]{0,10}(?:akamai.net.{0,50}.affiliate.net|(bravenet|ezboard).com/(jsbanner|(bravenet|rover)/)|fortunecity.com/js/(adscript|fctrack)|(geo.yahoo|geocities|domainpending|hostingprod).com/(js_source|(serv|toto)?s)|go2net.com/adclick|schooner.com/.{20}/banner_test.gif$)/

  • FreekV (unregistered) in reply to brazzy
    brazzy:
    FreekV:
    Yeah right, pages of code are more easily readable than a simple regex you can scan over in a blink of an eye. Regexes *do* make code more maintainable and readable.
    If you truely were able to "scan over" AND UNDERSTAND a non-trivial regexp in "a blink of an eye", I would bow down to your superior intellect. Only I don't believe you can do that.

    Regexps by themselves are extremely unreadable and badly maintainable. Their brevity does have a certain value, but as a maintainance programmer I actually would rather have pages of code than an uncommented regexp like this:

    /(/||.)(?:ad(image|page|peeps|s(erver|manager)?|vert.{0,8}|vo|x)?|(affiliatewiz|banner(exchange|s)?|counters?|(online|php|popup)ads?(new)?|popunders?|sponsors?))\d{0,2}\1|\D(468[x]60|125x300|728x90)\D|[^]banner[^_]*.(?:gif|jpg)$|/(?:ad|popup).(?:js|swf)$|_468[^/].gif$|^.{5,6}/{2}[^/]{0,10}(?:akamai.net.{0,50}.affiliate.net|(bravenet|ezboard).com/(jsbanner|(bravenet|rover)/)|fortunecity.com/js/(adscript|fctrack)|(geo.yahoo|geocities|domainpending|hostingprod).com/(js_source|(serv|toto)?s)|go2net.com/adclick|schooner.com/.{20}/banner_test.gif$)/

    Sigh, point is ultimately that the purpose of regexes is to replace boilerplate parsing code with a general notation, thus making code more maintainable. And BTW how many pages code would you need to do the equivalent of that expression? The example you cite is a WTF in itself, you should submit it.

  • (cs) in reply to AdT
    AdT:
    real_aardvark:
    At an even higher (design) level, are you sure that you're not just using regex to slap a band-aid over something that could be solved at a more appropriate architectural level?

    Regexes are often used in this way. But in this case, the input probably comes from an ordinary textbox (HTML INPUT element). To my awareness, there aren't many alternative ways to obtain currency input from a browser user via HTML. If a web interface is the only way to meet some other requirements (e.g. no installation), then you have to work with those constraints. And at some point, the key strokes to currency value translation will have to happen in any case.

    Indeed. And I would argue that "at some point" means server-side code or database validation. Remember, 99.99% of browser input will be valid, given a minimal amount of checking. Deal with the other 0.01% at a slightly saner level.

    Let's face it: valid != correct. Matching that 0.01% of weird gubbins that somehow passes the front-end checks is an amount of gubbins, probably greater than 0.01%, that was valid but not, in fact, correct. This might be because of business rules; it might simply be because the user was drunk and leant on the '0' key for a while.

    These "user cases" (hawk, spit) are not the responsibility of the front-end. They will be dealt with at a higher level.

    In ignorance of design and architectural decisions, regexes are more often abused than not. Where used, they are still, often, a band-aid solution.

    I rest my case, yer honour.

  • (cs) in reply to FreekV
    FreekV:
    brazzy:
    FreekV:
    Yeah right, pages of code are more easily readable than a simple regex you can scan over in a blink of an eye. Regexes *do* make code more maintainable and readable.
    If you truely were able to "scan over" AND UNDERSTAND a non-trivial regexp in "a blink of an eye", I would bow down to your superior intellect. Only I don't believe you can do that.

    Regexps by themselves are extremely unreadable and badly maintainable. Their brevity does have a certain value, but as a maintainance programmer I actually would rather have pages of code than an uncommented regexp like this:

    /(/||.)(?:ad(image|page|peeps|s(erver|manager)?|vert.{0,8}|vo|x)?|(affiliatewiz|banner(exchange|s)?|counters?|(online|php|popup)ads?(new)?|popunders?|sponsors?))\d{0,2}\1|\D(468[x]60|125x300|728x90)\D|[^]banner[^_]*.(?:gif|jpg)$|/(?:ad|popup).(?:js|swf)$|_468[^/].gif$|^.{5,6}/{2}[^/]{0,10}(?:akamai.net.{0,50}.affiliate.net|(bravenet|ezboard).com/(jsbanner|(bravenet|rover)/)|fortunecity.com/js/(adscript|fctrack)|(geo.yahoo|geocities|domainpending|hostingprod).com/(js_source|(serv|toto)?s)|go2net.com/adclick|schooner.com/.{20}/banner_test.gif$)/

    Sigh, point is ultimately that the purpose of regexes is to replace boilerplate parsing code with a general notation, thus making code more maintainable. And BTW how many pages code would you need to do the equivalent of that expression? The example you cite is a WTF in itself, you should submit it.

    I believe that the example is intentionally cited as a WTF.

    Further, I am quite prepared to believe that it is a genuine regex, as seen "in the wild" by brazzy.

    You must be from the southern hemisphere, because you're reading this upside-down.

    From the bottom, then:

    (1) "BTW how many pages code would you need to do the equivalent of that expression?"

    None, obviously. It's a WTF. It indicates a lack of design.

    (2) "Sigh, point is ultimately that the purpose of regexes is to replace boilerplate parsing code with a general notation..."

    Crap.

    Serious Crap.

    First of all, replace "parsing" with "lexing," and you're a scintilla closer to reality.

    Secondly, it is no more a general notation than is lambda calculus. And however general it might be, it has to prove itself useful for the specific case it is used.

    Thirdly, regexes are a tool. They have no "ultimate" purpose. Their use is constrained by the limiting conditions within which they are used. Sometimes they are appropriate; sometimes not. Here: not.

    (3) Back to the top. Oh, look. What a surprise. You completely ignore this:

    brazzy:
    If you truely were able to "scan over" AND UNDERSTAND a non-trivial regexp in "a blink of an eye", I would bow down to your superior intellect. Only I don't believe you can do that.

    Regexps by themselves are extremely unreadable and badly maintainable. Their brevity does have a certain value, but as a maintainance programmer I actually would rather have pages of code than an uncommented regexp like this...

    Now try responding from the top, dimwit.
  • Bill Szczytko (unregistered)

    Guarantee you it was because they had these problems crop up over time. Someone put two dollar signs in so they put a check in for it. Someone put the decimal in wrong so they put a check in for it. Amazing what the end user can do.

  • Me Too! (unregistered) in reply to cconroy
    cconroy:
    IceFreak2000:
    Andy Goth:
    return("You must express the magnitude of the dollar amount using modern, Arabic-derived numerals formatted according to base-10 (decimal) convention, most significant digit first.")

    ROFLAMO!

    Rolling On Floor, Lusting After Marie Osmond?

    Still!?
  • FreekV (unregistered) in reply to real_aardvark

    (Damn, what a piece of inflammatory hate mail...)

    sigh I fully agree! Complex expressions like that are just wrong by design and probably done by a maintainer who bolted it on. I never said that regexes should be used as an "ultimate" tool, as in a sort of lamba calculus. I meant that referring to brazzy's "by themselves", as in "the original purpose of". This is a stupid discussion, because ultimately ;-) we all agree.

    Sorry if my reply to Brazzy sounded a bit harsh though, I fully respect people who have to maintain stuff like that. But don't put words in my mouth, thanks.

  • FreekV (unregistered) in reply to real_aardvark

    Oh, and who said anything about lexing? Are you trying to look smart, dumbass, by comparing parsing an input value from a box to the parsing of complete programming languages. F*ck you.

  • FreekVeryDumb (unregistered) in reply to FreekV
    FreekV:
    Oh, and who said anything about lexing? Are you trying to look smart, dumbass, by comparing parsing an input value from a box to the parsing of complete programming languages. F*ck you.

    Hmmm, just an FYFI, lexing is not parsing... Might want to learn the difference BEFORE commenting.

  • Dube (unregistered)

    "Those who try to build idiot-proof systems always underestimate the persistence and ingenuity of idiots."

    wtf the chaptcha is getting longer and longer... "onomatopoeia"

  • BrandonPhone (unregistered)
    Comment held for moderation.

Leave a comment on “A Very Valid validInt”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article