in reply to Re: syscall() closes file descriptor
in thread syscall() closes file descriptor

Actually, I think I was being too easy on your code and too harsh towards syscall. I can't think of anytime that SYS_write( id, filehandle, len) would work. Write() can not be expected to fill a buffer. Which is what you are asking it to do when you call it with a filehandle as the buffer. If you want to call write() then give it buffer. If you want something in that buffer then call read().

Sorry this post sounds harsh. It's not meant that way.:)


s//----->\t/;$~="JAPH";s//\r<$~~/;{s|~$~-|-~$~|||s |-$~~|$~~-|||s,<$~~,<~$~,,s,~$~>,$~~>,, $|=1,select$,,$,,$,,1e-1;print;redo}

Replies are listed 'Best First'.
Re^3: syscall() closes file descriptor
by betterworld (Curate) on Aug 22, 2006 at 23:50 UTC

    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.

      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}

      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: $!";

      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}