C graffiti

Discuss

62 Responses to “C graffiti”

  1. Anonymous says:

    fym has fym has fym…

  2. Ito Kagehisa says:

    Hey Xopher, have you read the story of Mel?

    http://www.cs.utah.edu/~elb/folklore/mel.html

    I’m off to the pub now.

  3. Ito Kagehisa says:

    I loved it when I stumbled across the story of Mel because I actually have programmed a drum using 8 toggle switches. It was an old SEL though, not a bee, used to test solid fuel rocket motors for missiles and JATO systems. The part about timing the drum rotation is true. You had so little space you had to do that kind of stuff!

    Coding still required that level of thinking even as late as the 1980s. I had to use DEC TKB to hand-optimize the compilation of core data aquisition code in the wake of the Westar/Palapa B incident… the aerodynamic heads of the RL02 disk drives needed to fly from the disk edge to the hub in one smooth movement, with zero “seek wiggle”, to avoid piling up I/O and crashing the operating system. This was complicated by the lack of an unsigned integer data type in FORTRAN II, because the disk sector addresses would flip negative after incrementing sector 32767… so I had to eliminate compiler-based bounds checking… anyway, that had to be in the mid to late 80s.

    Programming’s different today. You’ll never see a heavy ferrite drum throw its main bearing, snap its shaft, and go careening destructively through a control bunker any more. You can’t set your monitor on fire by sending it the wrong frequency signals any more either. You might as well wear a suit and tie to work!

  4. Anonymous says:

    ok. am i the only n00b here that does not understand what the program does?

  5. Anonymous says:

    I already wrote something like this in an hospital

  6. Jeff Bell says:

    Your basic fork bomb.

  7. Anonymous says:

    I wrote the original comment about this being C and not C++. Someone wrote that this is valid C++. It is not: “int main()” will work in most C-compilers (they assume it is shorthand for “int main(int)”) with most compiler directives, but not in most C++-compilers (a few will assume it is shorthand for “int main(void)”) where you have to use “int main(void)” or “int main(int argc, char *argv[])”.

    Short version, old style (will work in C++ with “int main(void)”, but then it won’t work in a lot of C-compilers, “int main(int argc, char *argv[])” will work in C++ and with C-compilers that isn’t really, really ancient), untested:

    #include
    #include
    #include
    main(){for(;;) if(fork()) for(;;) puts(“FUCK YO MEMRY”);}

  8. Geoff says:

    For this purpose, wouldn’t recursion be preferable to an infinite loop?

    int fym()
    {
    fork();
    printf(“har\n”);
    return fym() + 1;
    }

    int main()
    {
    fym();
    return 0;
    }

  9. Jessica says:

    This is great, but totally invented at the Rochester Institute of Technology, where our stairways commonly feature code snippets.

    I mean, we’re the school that invented this website:

    http://www.ritporn.com

  10. Andrew says:

    That’s C, not C++.

  11. fishbane says:

    That’s perfectly valid C. Of course, that means it is valid C++, too, but… just saying.

    • Rob says:

      Valid C != Valid C++.

      This program is valid C++, but it doesn’t always follow that valid C is valid C++. There’s differences in the casting rules, and you can have variables in C that are named after C++ keywords.

  12. Xopher says:

    Wow, Ito, he programmed in a box in the middle of the road, and his boss killed him every day.

  13. salvarsan says:

    Quibble: It’s written in C, not C++.

  14. valdis says:

    All you guys trying to “debug” it and fix the infinite loops. Geez. Don’t you know *anything*?

    It’s quite possible the unknown graffiti artist made the program intentionally buggy – for many years, it was standard practice when posting code that was potentially dangerous to include a subtle bug, so that clueless newbies couldn’t use the exploit as-is. You had to have enough clue to spot the bug and fix it yourself, which kept the knuckle-walking trolls from using the code to break things without understanding.

  15. mrfoo says:

    That’s yer classic fork bomb, though the taunting is an added extra.

  16. Daniel says:

    And it’ll compile with warnings… Main function doesn’t return any value xD

    • Anonymous says:

      Just an FYI, in C++ (at least) return 0; from main is assumed.

    • Anonymous says:

      Back in the day main was a void statement. Try out Borland Turbo C++

    • Anonymous says:

      This is OK C code: the C99 standard specifies that a “return 0;” is assumed at the end of main().

      C’mon guys, the standard has been out for a decade now and every decent compiler supports (approximately all of) it. Let’s stop defining C in terms of what K&R said in the 70s.

  17. aml says:

    It doesn’t look C++ specific to me, it looks like Standard C in a unix environment. ( unistd.h and fork() things needing a unix or unix-like environment.)

    It also doesn’t look like it would do what the author intended as both the parent and child after the work will go into the infinite for/printf loop and never reiterate in the infinite while/fork loop.

  18. jacob_ewing says:

    #include
    int main(int argc, char *argv[]){
    printf(“Awesome.\n”);
    return 0;
    }

  19. mrfoo says:

    Yeah, illiterate script kiddy graffiti. How appropriate. With this fork bomb, all you have to do to defuse it is to kill the latest created process.

  20. Xopher says:

    It’s been a while, but will it even do that? The variable ‘ii’ is uninitialized.

  21. glib909 says:

    That’s hilarious :)

  22. teapot says:

    Only on BB could a post about code graf turn into a long discussion about the effectiveness of the code. And only on BB would I enjoy reading it.

    The discussion ended up funnier than the post!

  23. Bob says:

    Those are semi colons.

  24. dculberson says:

    Dude, be more careful before posting code like this! My processor utilization is through the roof and I can’t get the process killed!

  25. Xopher says:

    Ohhhhhh of course! Thanks Jacob.

  26. Anonymous says:

    It frightens me that there’s geeks out there actually correcting the program. Seriously? :)

  27. Anonymous says:

    This is one the Berlin Wall (or it was last summer): http://ritter.vg/misc/stuff/berlinwall.jpg

  28. Anonymous says:

    I guess I’ll be the first to say in this comment string that I have NO IDEA WHAT THE FUCK IS GOING ON.

  29. arkizzle / Moderator says:

    Epic story of Mel is EPIC! :)

    Thanks, I’d never read it before.

  30. iamcantaloupe says:

    The other week I was at a pub and saw that someone had scrawled a symbolic logic proof on the bathroom wall. I corrected it, adding a line they skipped, and put at the bottom ‘SHOW YOUR WORK!’

  31. ab5tract says:

    @Ito

    Thanks for sharing ‘The Story of Mel’. I can’t seem to get enough of this kind of computer history–do you know of any other resources besides that site for finding more of this “folklore”? Perhaps a relevant USENET category?

  32. There is a bug in the program. The intention is to keep forking processes and fill up memeory. But after the first fork the two copies of the program will both get stuck in the second infinite loop. Doh!

  33. Anonymous says:

    Actually it’s broken. It will fork once, then both parent and child will enter the infinite printf loop. Net result: two processes. A truly devious author would have omitted the inner loop (i.e. alternate fork and printf) leading to an exponential explosion of processes.

    Kids nowadays. Can’t even write code to print an infinite stream of junk without screwing it up. At least my generation got *that* right.

  34. arkizzle / Moderator says:

    C L A S S I C !

  35. pepsi_max2k says:

    B- for lack of comments in code. Which is probably for the best as the guy clearly can’t spell.

  36. Obdurodon says:

    Actually it’s broken. It will fork once, then both parent and child will enter the infinite printf loop. Net result: two processes. A truly devious author would have omitted the inner loop (i.e. alternate fork and printf) leading to an exponential explosion of processes. Extra points off for being inconsistent about “while (1)” vs. “for (;;)” and for being unable to spell.

    Kids nowadays. Can’t even write code to print an infinite stream of junk without screwing it up. At least my generation got *that* right.

    • simonbarsinister says:

      @Obdurodon you beat me to it. This graffiti is a total fail. It will only spawn 2 processes which print ‘ha!’ until you kill it. Yawn. I’ll bet this wild anarchist also creates viruses that infect only one other computer then stop.

      For the record, what ‘V for Vandalism’ probably meant to do was:

      while (1) {
      if (fork()) {
      while (1) {
      print “ha!”;
      }
      }
      }

  37. JerryR says:

    *sigh* Two different styles for infinite looping and no comments. And that “while” loop is going to give a “constant conditional expression” warning when compiled with a strict warning level on many compilers.

    Oh, wow. I work right next to this station. Now I have to worry about script kiddies IRL?

  38. Anonymous says:

    @Anonymous (the one with the bash code)

    Kind of overcomplicating things. Try this one instead:

    $0 &

    If we assume it’s a file, then win.

  39. Nanuq says:

    Silicon Valley kids all right. Even the street gangs write in code

  40. Xopher says:

    I’m sitting here having fond old-man reminiscences about when I programmed in C, back before all this object-oriented stuff came in, and before the fast computers and optimizing compilers you kids enjoy. Back then, you had to worry about whether you used a Repeat or a While because the extra jump actually made a noticeable difference in the execution time of the program.

    One time I used a For loop to walk down a binary tree, with the increment statement determining whether it went to the right node or the left. Good times!

    The memories even further back, of programming in Fortran V on cards (you whippersnappers have probably never seen them things, have you?), are less fond.

    Not only that, we had to compile our code by hand. In the snow. Uphill both ways.

  41. simonbarsinister says:

    On second thought… my version will fill your computer with taunting little processes but it can be stopped by killing the parent process. A better version would be harder to stop if even one of the little buggers is still running:

    while (1) {
    fork();
    print “ha!”;
    }

  42. LOL says:

    So you can see which of your processes LOLs:

    while(1){
    fork();
    printf( “LOL %d\n”,getpid());
    }

    If he really wanted it to be a “fuckmemory” program, he should have thrown in a malloc statement in there along with the printf… like a stupid version of ulimit XD

  43. Xopher says:

    All right, I’m lost. The one I’m most curious about: what is the meaning of a #include with no .h file (or anything else) after it?

  44. while1dan says:

    We’re wasting time here. Someone needs to get over there and comment out the for loop.

  45. Ito Kagehisa says:

    Oh, Xopher, you had cards.

  46. Anonymous says:

    bash$ :(){ :|:& };:

  47. Wayne Maddison says:

    Other geek graffiti: Back in the late 70′s there was an engineering building at the U of Toronto with a prominent wall spray-painted in large symbols “e^(i*pi) + 1 = 0″. The authorities evidently saw the beauty of this equation, and let it be for several years.

  48. Anonymous says:

    And yet no one has posted a proper Memory Devourer Mk 2 that has all the bugs stomped and immaculate commentary sarcasm?

    Including myself.

  49. Jack-Booted EULA says:

    I remember keypunch machines, Fortran and (shudder) batch jobs.

    I also remember my co-workers at the USGS referring to that location as “the tunnel of pee.”

    :o )

  50. Gord Deinstadt says:

    simonbarsinister, I don’t know what language
    print “ha!”;
    is but it is not C.
    How about
    int main(){
    while (fork() != -1) puts(“ha!”);
    return 0;
    }

  51. bodenski says:

    To err is human. ‘Tis geekier to correct in situ.

Leave a Reply