At first sight this behaviour looks very strange. If there was any data available via <>, the command x <> would consume all of it and the loop would not be entered. I've played a bit with this setup and are able to reproduce such a thing. If <> is exhausted and the final returned undef is ignored, the next call to <> will read from STDIN, even if file names were provided via @ARGV.

This behaviour is documented in I/O Operators.

I guess there is some part in the script that ignores an undef return from <> or evaluates it in list context before the loop in question. And there are named files in addition to data from STDIN.

Update:

...the loop would not be entered.

This it not true and is not what I wanted to say. The loop is entered, but it will wait for input from STDIN.