Hmm let me think. It's in eval, so simple errors like m or die won't do anything. exit will quit. But dump is before exit. Is there anything earlier?

Let me look at the keyword list at ode getprotobyname generator...

Hmm, maybe the disaster you have expected was a fork bomb... I think eval"redo" isn't an infinite loop, but I try it in the console to be sure. Hmm. It is an infinite loop the way your code is now, because it jumps to the beginning of the while loop and the $s++ gets skipped.

Let me think that dump thing over. I think they're planning to remove that keyword so it can only be called as CORE::dump. I look it up in the manual... Try it in the console... So it warns only for now.

Ok, there's nothing more I can think of, so my prediction is that it will dump core.

Firstly, I realized that fork wouldn't cause a fork bomb as I thought for some reason, only fork exactly once. Now I didn't realize getc would do something significant (as opposed to, say, warn which just prints some output) until I've read FunnyMonk's reply. So this means that if we get over dump and exit, the script would fork exactly once and then try to read the terminal from both processes. This is not the typical job control situation, because the two interpreters are in the same process group, so I have to look it up in the manual what happens exactly. *looks it up* I can't find it out from the manual. Let me try. *tries* Apparently nothing special happens, they read lines after each other in some random order.

Secondly, I realized that I thought of redo but not last or next. last would obviously exit the loop and thus end the program. next would also cause an infinite loop the same way as redo, but this could be avoided by putting the $s++ in a continue block.

Of course, none of these change my answer being dump.