You know #define BEGIN {, but do you know THIS?



  • Extra points for guessing where it is from.

    Have fun - and find all the "real WTF"s :P


  • Discourse touched me in a no-no place

    I find the comments after the #includes a bit pointless. Does the student writer intend mentioning every function and #define used from each header file?

    I'm sure Pi is define in one of the headers not included

    main() returns int. (Not implicit int, float, or struct foo.) At least they got the parameters right

    There's an awful lot of volatiles declared.

    Along with an awful lot of uninitialised variables.

    And what's with the camera shots instead of copy/paste of the code?



    @OperatorBastardusInfernalis said:

    Extra points for guessing where it is from.
    I'm hoping it's a university assignment. I feel I'm going to be dissappointed when we are told.



  • Obviously something Japanese, given the use of ¥ as a pathname separator. Guessing it's probably, but not certainly, an anime. And I don't believe it's Suzumiya Haruhi (which, incidentally, is surprisingly good when it comes to code-related stuff).

    Any further hints?



  •  @PJH said:

    I find the comments after the #includes a bit pointless. Does the student writer intend mentioning every function and #define used from each header file?

     People I work with do this (thankfully, not people who work on the same code as I do). I really don't have any idea why - I suppose it's some attempt at keeping out unnecessary includes, but I can't imagine that every time they remove a system or library call they go and check if that call is still used anywhere and if so check if it's the last one used from a given header, and then remove the include.



  • Oh, and speaking of bizarre code from anime, this screenshot that I found in Witch Hunter Robin a while back is hilarious to me (though I'm easily amused). Proper C-style indentation and comments, but the rest is complete gibberish. It's like they wanted it to look sufficiently like code for people who knew what code looked like but couldn't be bothered to actually freeze-frame their recording.


  • Discourse touched me in a no-no place

    @Tyler said:

    @PJH said:

    I find the comments after the #includes a bit pointless. Does the student writer intend mentioning every function and #define used from each header file?

     People I work with do this

    They need re-educating. In an educational environment I can (possibly) understand the need for such comments, but in a business environment, they're equivilant to the /* add one to i */ sort of comments.



  • Hah, you should see what passed for screen greek in Gundam Wing.

    Photoshop 4 TWAIN installation directions ( http://img.photobucket.com/albums/v456/Mr_Bound/gw4.png?t=1260997490 )

    as well as, if I recall correctly, random programs in BASIC that looked obfuscated, and "asdf" & co. mashed on the keyboard...



  • @codeman38 said:

    Obviously something Japanese, given the use of ¥ as a pathname separator. Guessing it's probably, but not certainly, an anime. And I don't believe it's Suzumiya Haruhi (which, incidentally, is surprisingly good when it comes to code-related stuff).

    Any further hints?

    Looks more Hollywoodish from the effects. Animé (or at least the few I've watched) tends to be pretty realistic when it comes to computers. That WHR shot looks like they didn't want to show their real code (too sensitive?) or didn't have any, and just mashed up some gibberish rather than find a nice-looking open-source snippet.

    I wonder how copyright/licensing applies to the use of source code as an image in a movie?

    As for the topic, please find the author of that code, go back in time, and eliminate their parents. We can't take the chance that they had any siblings.


  • @PJH said:

    @Tyler said:

    @PJH said:

    I find the comments after the #includes a bit pointless. Does the student writer intend mentioning every function and #define used from each header file?

     People I work with do this

    They need re-educating. In an educational environment I can (possibly) understand the need for such comments, but in a business environment, they're equivilant to the /* add one to i */ sort of comments.

    Not really. In real world code you sometimes need to pull in some header you wish you didn't need to pull in, in order to use some obscure feature. Another programmer will probably see this and, like you, think "This really shouldn't be here." They'll try removing the "unnecessary include" and won't realize their mistake until the build fails three hours later.

    The comment is a way of saying "Yes, I really DO need this stupid thing, and here's why."

    Although I agree that such comments next to standard header files are more indicative of somebody who doesn't know the standard library...



  • I'm going out on a limb on this one but -- Nexuiz? The directory this is in contains mostly Nexuiz test screenshots, and I've seen a few code-related pictures in the Nexuiz folders, so it only seems logical.



  • No, this is my directory where I upload all my images.

    And, I am a Nexuiz developer.

    As for the screenshots - they come from an anime from 1998.



  •  Serial Experiments Lain maybe?



  • @smxlong said:

    Not really. In real world code you sometimes need to pull in some header you wish you didn't need to pull in, in order to use some obscure feature. Another programmer will probably see this and, like you, think "This really shouldn't be here." They'll try removing the "unnecessary include"

    Nothing wrong with this. I like to avoid #include bloat too.

    @smxlong said:
    and won't realize their mistake until the build fails three hours later.

    Possible WTFs here:

    • Committing code into version control without testing compilation
    • Not using any kind of dependency tracking in build system, forcing full rebuild for every small change
    • Having such a large codebase and backwards build system (recursive make anyone?) that getting to the compile error takes three hours

    Take your pick. As for the last one, I did work on a program that took 15 mins to build in debug mode, but 95% of that time was spent in the final link to produce a 250MB binary. But three hours to report an undefined identifier is just ridiculous.



  • @codeman38 said:

    Suzumiya Haruhi (which, incidentally, is surprisingly good when it comes to code-related stuff).

    Endless Eight

    Thank god it lasted only two episodes.



  • I assume that the primary WTF is the definitions of GOSUB and RETURN.  Scary.

    As for the "uninitialized variables" that another poster complained about, I don't see any problem there.  Variables should *not* be set until they can be set to a meaningful value.  Blindly initializing them to some noise value - zero, -1, NULL, "" - defeats static used-before-set analysis and means that a bug where you missed a code path and used the value before setting it to something meaningful is detected when it crashes the customer's application, rather than when you run "lint" or the equivalent.



  • @Shinhan said:

     Serial Experiments Lain maybe?

    No, they were LISP heavy.



  • Lost Universe

    (you know, the series where the design for Windows ME-tan is from)



  • @lolwtf said:

    Looks more Hollywoodish from the effects. Animé (or at least the few I've watched) tends to be pretty realistic when it comes to computers. That WHR shot looks like they didn't want to show their real code (too sensitive?) or didn't have any, and just mashed up some gibberish rather than find a nice-looking open-source snippet.

    Anime tends to be even somewhat realistic (sure, there is a lot of exceptions) when it comes facts and such, but it's not rare to see this kind of gibberish (or Sereal ATA AHCI3 HBA loading "Operation System") on random terminals.



  • @OperatorBastardusInfernalis said:

    Lost Universe

    (you know, the series where the design for Windows ME-tan is from)

    Huh. I was actually wondering if that might be what it was from, particularly given the path name (a:\lost) in the screenshot.

    Alas, I'm only familiar with that series because of the QUALITY outsourced animation used in one episode of the original TV airing, which has become a sort of meme in itself. Apparently the animation studio has disowned that version in lieu of the DVD version.



  • Maybe the CODING for this was outsourced too. Would explain the GOSUB.



  • Private mail indicates that my uninitialized-variable comment may not have clearly expressed my point.

    My point was that there are tools (lint and the Java compiler come to mind) that statically analyze your program to see if there are any code paths that could end up using the value of a variable before it is set.    If you blindly initialize the variable with some nonsense value, you defeat that analysis.  That means that instead of your bug showing up as a compile or lint error, it shows up as a runtime error or as corrupted data.

    Suppose you have (Java, but the concept applies anywhere):

        String s;
        while (moonPhase() != FULL) {
            s = somefunc();
        }
        System.out.println(s.length());

    That code has a bug in it:  if the moon is full the first time, s never gets set.  As written, the Java compiler will fail, reporting an error on the println.  If, on the other hand, you said "String s = null;", the compiler can't tell that there's anything wrong, but you still end up getting a runtime NullPointerException when it tries to execute s.length().  The compiler is trying to do you a favor, detecting your bug for you, and when you blindly initialize the variable you defeat that and make the bug much harder to detect - now, instead of causing a compile failure, it only fails when the moon is full, and maybe you didn't happen to test then.  (One might argue that you should instead initialize s to "".  Indeed that will avoid the NPE, but it might well cause some other still more subtle problem.)

    Remember that the compiler inspects every single line of your program, while testing only exercises a fraction of the code paths.  If you can get the compiler to detect bugs, that's a huge win.

     


Log in to reply