Your basic fork bomb.

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:

www.ritporn.com

That's C, not C++.

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

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

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

And it'll compile with warnings... Main function doesn't return any value xD

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.

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

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.

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

That's ';;' ie. infinite for loop.

Those are semi colons.

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

Ohhhhhh of course! Thanks Jacob.

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

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!

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.

C L A S S I C !

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

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.

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

@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!";
}
}
}

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

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.

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!";
}

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

Oh, Xopher, you had cards.

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;
}

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.

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

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.

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;
}

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

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

Epic story of Mel is EPIC! :)

Thanks, I'd never read it before.

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

fym has fym has fym...

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");}

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!

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!'

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

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?

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.

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 )

It means they forgot to escape < and >

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

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

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.

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

That's hilarious :)

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!

Just as likely (if not more) on /.

If you liked The Story of Mel and want more proto-hacker lore, try esr's Jargon File.

ab5tract, I recommend Karla Jennings' "The Devouring Fungus"

http://www.amazon.com/Devouring-Fungus-Jennings-Karla/dp/0393307328

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.

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

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

Including myself.

I already wrote something like this in an hospital

Yeah!!!!

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