I am not complaining about the output "GLOB(0x814". This is what one should expect when treating a file handle reference as a string. I don't expect perl to read from the file handle.
I'm only wondering why the file handle gets closed. Nobody told perl to do that.
| [reply] |
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.
s//----->\t/;$~="JAPH";s//\r<$~~/;{s|~$~-|-~$~|||s
|-$~~|$~~-|||s,<$~~,<~$~,,s,~$~>,$~~>,,
$|=1,select$,,$,,$,,1e-1;print;redo}
| [reply] [d/l] |
#!/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: $!";
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.
s//----->\t/;$~="JAPH";s//\r<$~~/;{s|~$~-|-~$~|||s
|-$~~|$~~-|||s,<$~~,<~$~,,s,~$~>,$~~>,,
$|=1,select$,,$,,$,,1e-1;print;redo}
| [reply] [d/l] |