But, if your passing parameters to syscall and syscall doesn't know what to do with them then the behavior is undefined. Undefined means anything could happen, data corruption, crash and etc. The problem is that Perl has to make assumptions about what you are going to do inside the syscall without actually parsing the syscall.

From perldoc -f syscall:

"You can't use a string literal(or other read-only string) as an argument to "syscall" because Perl has to assume that any string pointer might be written through."

We can't expect the same kind of DWIM inside the syscall as we ususally expect elsewhere from Perl. Instead Perl 'expects' our parameter to match syscall.ph. Any thing else is going to give undefined behaviors.

I don't know if Perl is trying to prep the string for writing as above or if the closing is accidental.

Note: It doesn't matter which routine you call only that the filehandle as a scalar in the argument list. So it seems to be an artifact of Perl trying to munge the argument list into a C structure.

#!/usr/bin/perl
use strict;
use warnings;
require 'sys/syscall.ph';

my $buffer = "                ";

open my $f, '</dev/null' or die "open: $!";

# This works
syscall(&SYS_read, fileno($f), $buffer, 1) != -1 or warn "write: $!";
defined read($f,  $buffer, 1) or die "First pass, read: $!";

# This closes $f
syscall(&SYS_read, fileno($f), $buffer, 1, $f) != -1 or warn "write: $
+!";
defined read($f,  $buffer, 1) or die "Second pass, read: $!";
[download]

Since there would be no C function that took a Perl filehandle as an argument, the appearance of a Perl filehandle in a syscall argument list I take to be an error.