It's not really uncommon to run processes under a strict ulimit limit, reducing the number of processes a user account can have running. This usually protects against runaway processes.

You can easily reproduce the problem by using ulimit -u 64 and run any kind of forkbomb.

if you spend six months writing code that caters for porting to some non-forkable environment

That's not what we're talking about. It's a single line of code.

And if you were to ask if I would spend the literally 7 seconds it takes to type defined($pid) or die "fork failed: $!"; to save my employer the potential costs of a mysterious failure sometime in the future by replacing it with an error message, even on platforms where fork is supported, then yes, I would! I'm taking your continued disagreement to mean that you wouldn't. Although I disagree with that, I can't stop you from providing your employer with whatever code you like - but that's not what we're talking about either.

We're talking about providing a piece of code to help a stranger, and potentially many other future visitors of this site. In your posts, you showed the usage of fork without a check for an error or a mention that you've omitted the check and why. You can't be certain that on any of the systems where this code might be run in the future, fork will never return undef.

Fork can fail for lots of different reasons. For example: not enough swap to hold two copies of the process, you've reached the max process for your user or globally, not enough physical memory to complete the fork, you got a signal during the fork call, etc.

It seem naive to me to think that an error can't happen; it's better to die if it does happen than to continue on with possible corruption. If you don't like the aesthetic, then write a wrapper that dies on errors, so you can present clean code.