• Chuck (unregistered)

    What is your thing against variable variables, or PHP in general? Variable variables are not much different than pointers in terms of ability to screw yourself versus ability to do really useful things.

    All of the language flaming here takes away from my enjoyment of the humor of the code (so does the "I don't get the WTF", but that's another story).

    So consider this a request to stick to presenting the code in the main post, and leave the language arguments and all other pokes/jabs/etc to the comments.

  • Ron (unregistered)

    I just want to say that I love MSFT. That being said, I think this KB article is evidence that nobody is perfect.

    I won't argue to justify it, but I'll submit a hypothesis that a Junior PM or a Software Engineer Intern wrote it.

  • black (unregistered)

    i preffer doing lets say..

    $function_name = "somefunction";
    $function_name($parameters);

    as opposed to using www.php.net/call_user_func_array to call functions and alike in php

    In fact, this has been adopted trough a lot of the php community (the people who read the manual anyway), and thus hinders efforts of compiling php into bytecode. I think the story went around the lines "I'm writing a compiler, but wtf are variable variables, I'm not gonna code this shit, nobody uses it!", and then people ripped him a new one since they did use it.

    php variable variables are not only useful but also fun ;)

  • AvonWyss (unregistered)

    There are a couple of such things in the KB and also in MSDN, like this:

    ' Build the query string for a deep traversal search
    ' on the x0e080003 mapi proptag.
    sQuery = "<?xml version=""1.0""?>"
    sQuery = sQuery & "<g:searchrequest xmlns:g=""DAV:"">"
    sQuery = sQuery & "<g:sql>SELECT ""http://schemas.microsoft.com/"
    sQuery = sQuery & "mapi/proptag/x0e080003"" FROM SCOPE "
    sQuery = sQuery & "('DEEP TRAVERSAL OF """ & strUri & """') "
    sQuery = sQuery & "WHERE ""DAV:isfolder"" = true"
    sQuery = sQuery & "</g:sql>"
    sQuery = sQuery & "</g:searchrequest>"

    And more in other samples... taken from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/e2k3/e2k3/_esdk_getting_mailbox_size_webdav.asp

  • Razzie (unregistered)

    You really wonder how on earth Microsoft can place an article in their KB like this. You'd think it gets checked by some Lead Visual Basic Developer or something. Or maybe he was the one who wrote this. Hmmm...

  • Razzie (unregistered)

    And it's nice to see a fellow EE'r here, AvonWyss :)

  • Guayo (unregistered)

    The IHBLRIA syndrome it's a WTF in itself not to mention this is code that people would probably copy and paste in their code base as this is the MS' recommended way, but even pretending there wasn't a Replace function, the KB code still seems odd to me (I'm not a VBScipt expert).

    Why bodystring it's needed at all? What's wrong with parsing text using instring directly?
    Why tree Mid(bodystring, i, 1) in a loop?
    Why bodystring = bodybuild : padQuotes = bodystring and not simply padQuotes = bodybuild?

    But the thing that amazes me more is that that code went through revision 4.1!

  • Mike Dimmick (unregistered)

    The correct solution is always to use parameterised queries (with the Command object's Parameters collection, from ADO). Any concatenation operation to build a SQL string from unchecked input runs the risk of SQL injection attacks.

    With parameters, you don't need to worry about filtering or escaping characters - the parameter's value is passed directly to the underlying engine with no interpretation.

  • Raymond Chen (unregistered)

    This is an old article from August 1998. The Replace() function didn't exist back then.

    KB articles aren't in the same class as formal documentation. They're more like "Some guy had a problem, he came up with a solution [possibly not the best solution but a solution], may as well share it with other people to save them some trouble."

  • Eric W. Bachtal (unregistered)

    I think that KB is pretty old (is that too obvious?). I think it originally dates from back in the VBScript version 1.0 days (or just after it) when there was no Replace (or Split, or Join). I suppose the WTF-est thing about it is how someone at MS could have reviewed it in 2004 without thinking it would be a good idea to note the existence of Replace, or (as Mike Dimmick notes) to avoid using this technique at all for building dynamic SQL strings due to the security implications.

  • Will Waters (unregistered)

    Actually, according to the KB's "Applies To" section, this KB article applies IIS 4.0. The link to the Replace method shows it was introduced in VB Scripting Edition 2.0 which was introduced with IIS 3.0. So this really is a case of IHBLRIA.

  • Adelle L Hartley (unregistered)

    I think that not updating the KB example code to take advantage of newly introduced features or functions is a matter of policy. Some areas of the KB have quite obviously only received minor revisions since Windows 3.0.

    When I read a KB article, I assume that the code being presented is meant only to demonstrate the feature/problem/aspect being described. I go WTF when anyone says "Do it this way because that's how it is in MSDN". If the article does not have the title "How to write really good code in your favorite language" then I wouldn't go presuming that it was written as though it does.

    Given the number of changes that products go through during development, I think it's impressive that example code that was probably written during a product's early development even compiles on the final release.

  • EmCee (unregistered)

    Firstly, I do enjoy the site, and I've never commented, 'till now. I'd just like to say I agree with the first poster, Chuck. :/ I mean really, this is the second time I've seen so far a link to Variable Variables in PHP, and it seems you're calling it a personal WTF.

    Anyway, continue on, love the page.

  • FredP (unregistered)

    I'm not really sure where the defending of variable variables is coming from. Just because you can do some really useful things with a mechanism of a language doesn't mean it's a good practice. I can imagine debugging someone else's code that utilized variable variables must be a nightmare. Sure you can shoot yourself in the foot with pointers but it's often times the most efficient way of doing something. I don't think that's the case at all for variable variables.. It was a good WTF.

  • Concerned Citizen (unregistered)

    Reference the 'dangerous' example C in the sample code for T-SQL EXECUTE:

    Why is this so dangerous? The variable isn't passed in from some calling module, it's delcared locally and populated by the value from a cursor, the query for which is at the top of the example. The code is doing exactly what is intended; deleting all user-defined objects. The only way this could be dangerous would be if you could spoof the system with your own sysobjects table or something hairy like that.

    I enjoy this site, but sometimes I just have to say "WTF yourself", with stuff that's overboard or a real stretch to consider a WTF.

  • Alex Papadimoulis (unregistered)

    @Concerned Citizen:

    It is a dangerous example because it's an incredibly rare and harmful thing to do. It would be like teaching someone how to use Pipes and Switches in DOS with an example like this:

    The following example will unconditionally format your hard drive without any prompting whatsoever ...
    ECHO Y | Format C: /q /u /label=

  • Charles (unregistered)

    For the "variable variable" haters, you can also spread the hate to Perl, as it's where PHP guys surely lifted it from... there are even two ways to do it...

    ----
    no strict("refs");
    $one = "something";
    $two = "one";
    $three = $$two;
    $four = ${"one"};

    print "!$three!\n!$four!\n";
    ---

    Of course, this doesn't work in strict. You can also do the same thing for sub calls...

    ---
    sub whatever { return shift }
    $five = "whatever";
    print $five->("Print me!");
    ---

  • Peter Torr (unregistered)

    Well, I submitted feedback to them that they should recommend parameterised queries and Replace.

    Here's hoping they fix it...

  • Antti (unregistered) in reply to Charles

    Recommended substitute: a hash. That is, a namespace of your own. Now let's see how you would work with this one:

    my %namespace;
    $namespace{a} = 1;         # replaces $a = 1;
    $namespace{b} = 2;         # replaces $b = 2;

    foreach my $key qw(a b) {
        print "$key = $namespace{$key}\n";   # replaces print "$key = $$key\n";
    }

    Clean, safe, efficient.

  • Zygo (unregistered) in reply to Mike Dimmick
    Mike Dimmick:
    The correct solution is _always_ to use parameterised queries (with the Command object's Parameters collection, from ADO). _Any_ concatenation operation to build a SQL string from unchecked input runs the risk of SQL injection attacks.

    With parameters, you don't need to worry about filtering or escaping characters - the parameter's value is passed directly to the underlying engine with no interpretation.

    Except if you're using one of the zillions of home-brew ORM classes (like the one that was sold to one of my former employers for $50K/developer seat) that implements parameters by creating query strings with escaped characters.

    10 points if you get caught with one of these client libraries that doesn't escape UTF-8 strings quite the same way the server parses them.

    Still, it is usually a good idea to speak to your libraries as if they weren't coded by idiots, at least until the bugs force you to behave otherwise.

  • Cristian (unregistered)

    Ohh... They deleted that KB article!

    Microsoft Advanced Search:
    There are no documents that match your search for "scid kb en us 190742"

  • Anon (unregistered)
    But I'll be willing to bet that you haven't heard of IHBLRIA ("Invented Here, But Let's Reinvent It Anyway"). And it you have, that's quite impressive; I just made it up right now.

    Sure, but that was almost 10 years ago.

Leave a comment on “IHBLRIA”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article