C graffiti

C graffiti

By David Pescovitz

iuhiufi32ubf23.jpg I photographed this graffiti under an overpass near the Palo Alto Caltrain station. It's a C++ program, called FUCKYOURMEMORY.c. Only in Silicon Valley.

Published 10:05 am Fri, Oct 9, 2009

About the Author

David Pescovitz is Boing Boing's co-editor. On Instagram, he's @pesco.

62 Responses to “C graffiti”

  1. Jeff Bell says:

    Your basic fork bomb.

  2. 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:


  3. Andrew says:

    That’s C, not C++.

  4. 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.

  5. salvarsan says:

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

  6. mrfoo says:

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

  7. 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:

      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.

    • Anonymous says:

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

  8. 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.

  9. jacob_ewing says:

    int main(int argc, char *argv[]){
    return 0;

  10. 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.

  11. Xopher says:

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

  12. Bob says:

    Those are semi colons.

  13. 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!

  14. Xopher says:

    Ohhhhhh of course! Thanks Jacob.

  15. Anonymous says:

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

  16. 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!

  17. 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.

  18. arkizzle / Moderator says:

    C L A S S I C !

  19. pepsi_max2k says:

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

  20. 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!”;

  21. 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?

  22. Nanuq says:

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

  23. 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.

  24. 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) {
    print “ha!”;

  25. LOL says:

    So you can see which of your processes LOLs:

    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

  26. Ito Kagehisa says:

    Oh, Xopher, you had cards.

  27. 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;

  28. Ito Kagehisa says:

    Hey Xopher, have you read the story of Mel?


    I’m off to the pub now.

  29. Geoff says:

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

    int fym()
    return fym() + 1;

    int main()
    return 0;

  30. Xopher says:

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

  31. Anonymous says:

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

  32. arkizzle / Moderator says:

    Epic story of Mel is EPIC! :)

    Thanks, I’d never read it before.

  33. Anonymous says:

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

  34. Anonymous says:

    fym has fym has fym…

  35. 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:

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

  36. 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!

  37. 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!’

  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. 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?

  40. 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.

  41. 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 )

  42. 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.

  43. ab5tract says:


    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?

  44. while1dan says:

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

  45. glib909 says:

    That’s hilarious :)

  46. 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!

  47. 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.

  48. Anonymous says:

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

  49. 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.

  50. Anonymous says:

    I already wrote something like this in an hospital

  51. bodenski says:

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