develooper Front page | perl.perl5.porters | Postings from April 2019

[perl #134042] POSIX::close() bug?

Thread Previous
April 17, 2019 17:14
[perl #134042] POSIX::close() bug?
Message ID:
# New Ticket Created by 
# Please include the string:  [perl #134042]
# in the subject line of all future correspondence about this issue. 
# <URL: >


	Todd Rinaldo and I were talking today about this:

perl -MPOSIX= -e'
open my $r3, "<&", \*STDIN;		# opens fd 3
open my $r4, "<&", \*STDIN;		# opens fd 4
print "r4 is " . fileno($r4) . "\n";
close $r3;				# closes fd 3 & Perl $r3
POSIX::close(fileno($r4));		# closes fd 4, NOT Perl $r4
my($in, $out);
pipe($in, $out);			# opens fds 3 & 4
print "out is " . fileno($out) . "\n";

close $out;				# XXX: a no-op, because Perl still has $r4 open?

sysread( $in, my $buf, 512 );		# hangs

We’re wondering if the above constitutes something that would reasonably be considered a bug in Perl, and/or something that could be accommodated anyway.

I’m guessing that the fact that close() is a no-op (i.e., it doesn’t close any FDs) is because PerlIO never knew about the POSIX::close() call against FD 4 and so it tracks both $r4 and $out as referring to FD 4; thus, it won’t do anything when $out is close()d because it still has another filehandle that refers to that FD.

When pipe() gives FD 4, shouldn’t PerlIO set that reference counter to 1? Or should it maybe warn() that there’s a file descriptor conflict?

Thank you!

-Felipe Gasper

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About