• Am I really (unregistered)

    The Frist?

  • LCrawford (unregistered)

    Props for an ancient PHP script that tries to disallow audio_file.mp3.exe uploads. But in the end it would probably be allowed.

  • RLB (unregistered)

    Oh, it's worse than it looks: even back in 2002, PHP had pathinfo() and is_executable(). mime_content_type() came in at the end of that year. So none of this was necessary at all.

  • wiseguy (unregistered)

    Assuming '$extensionPass' is not initialised beforehand, the if ()-will go to the else clause, since null compares unequal to the string 'false'. So the whole thing 'works' in the way that it allows all uploads....

    (The bug would have been found earlier if the culprit had understood booleans and or types).

  • Hal (unregistered) in reply to wiseguy

    Which tells you all you need to know about the approach to acceptance testing taken too. That is they either did none - "It runs, off to production it goes!" or they only tested positive use cases "Upload a media file -> Success" and never tried "Upload an invalid file type -> Error expected" at all.

  • 516052 (unregistered) in reply to Hal

    Well to be fair to them the code causes absolutely no compiler errors. What more can we expect them to test?

  • Brian Boorman (google) in reply to Hal

    2002 was still relatively the early days of web development so maybe you can forgive the lack of rigorous process. Every new field has it's early days of "wild west".

  • my name is missing (unregistered)

    I always found PHP to be a self destructing language, given it has a popular function named explode()

  • Maelish (unregistered)

    Wouldn't any code from 2002 be terrible at this point? Why keep picking on PHP like it's the only one with this problem?

  • (nodebb)

    I suspect there used to be some code that ran when $extension was empty, but it got deleted without deleting the if, resulting in that huge WTF.

    The function only sets $media_type for allowed types, so there would be no point in using that variable when reporting that the type is not allowed.

  • ooOOooGa (unregistered)

    The WTF from PHP is that even though I use the language daily, I still had to go check the documentation to see if the strings 'true' and 'false' would get type juggled to the appropriate boolean values. They don't. They both get coerced to True. Only the empty string and the string '0' get coerced to False.

  • 516052 (unregistered) in reply to Maelish

    You'll find that there are plenty of programs written before the turn of the century in proper languages like C and assembly that are far better than this.

  • I dunno LOL ¯\(°_o)/¯ (unregistered) in reply to 516052

    That's the brillant part about using interpreted languages. You don't get compiler errors!

  • Faroguy (unregistered)

    I think my favorite bit is the comment "//get photo extension"

  • Gummy Gus (unregistered)

    I was about to bash on PHP, but it really is not that much worse than every other ad-hoc or ancient language, not limited to C, csh, bash, PowerBuilder, BASIC, Javascript, Visual Basic, Sendmail, the list of horrible languages is nearly endless. Ever try programming in VMS or MSDOS command language? I rest my point.

  • I see what you did there... (unregistered)

    "Also, instead of using booleans, we get to use stringly typed true/false values"

    ... and I like it!

  • Sole Purpose Of Visit (unregistered) in reply to Maelish

    That's insanely untrue (to misquote Steve Jobs). There's plenty of code written in or before 2002 that still basically works out of the tin. Quite a lot of it is in gnarly old languages like Cobol, Fortran, and C/C++.

    Some of it is even in Perl 5, although nobody can quite explain why it works.

    Let's turn the insanity around, shall we? Wouldn't any code written in PHP be terrible at this point, regardless of whether it was written before, or after, 2002?

    Now, I don't happen to agree with this assertion. But it's much easier to defend than yours.

  • anon (unregistered) in reply to ooOOooGa

    ...as well as empty array and null...

  • (nodebb) in reply to ooOOooGa

    Python also treats all spellings of "boolean strings" as True because sequences are falsy when they are empty, and truthy otherwise.

    It tripped me up at first, but I really found no useful use case for type casting boolean literal Strings to booleans. In all cases it was better anyway to check against a manually written list of allowed truthy and falsy string values and raise a Value error otherwise.

    I just wish Python had a built-in way to raise exceptions in expressions... I usually end up writing an "unexpectedvalue" function to allow treating that case in ternary expressions.

  • Officer Johnny Holzkopf (unregistered) in reply to Faroguy

    That, combined with the neatly arranged semicolons next to that comment.

  • Daniel (unregistered) in reply to Gummy Gus

    Reminds me of the old joke: What would programming be like without PHP and JavaScript? That would be like chocolate cake without ketchup and mustard.

  • rajbir goyal (unregistered)

    Digital marketing agency - https://www.mahiradigital.com/

  • 516052 (unregistered) in reply to Daniel

    Ewww.... how can you people eat that. Next thing you'll tell me you don't put any mayo on it either?!

  • (nodebb) in reply to 516052
    Ewww.... how can you people eat that. Next thing you'll tell me you don't put any mayo on it either?!

    That's Ruby.

  • 516052 (unregistered) in reply to CodeJunkie

    Wait, if that's ruby than what's Delphy?

  • numzero (unregistered) in reply to ooOOooGa

    The WTF is that "1" is coerced to true, "0" is coerced to false, "true" is coerced to true, but "false" is coerced to true. Heck, this is the only language I know that does things like that (not sure of JS though but others don’t treat non-empty strings as false)... OTOH that’s along the lines of "13" + "29" being 42.

Leave a comment on “Extensioning Yourself”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article