develooper Front page | perl.perl5.porters | Postings from October 2013

Re: [perl #119529] Filehandle opened from ref to ref hangs on reading

Thread Previous | Thread Next
From:
Dave Mitchell
Date:
October 17, 2013 14:57
Subject:
Re: [perl #119529] Filehandle opened from ref to ref hangs on reading
Message ID:
20131017145723.GL2278@iabyn.com
On Mon, Sep 23, 2013 at 06:59:09AM +0000, Ed Avis wrote:
> In general I suggest that opening a filehandle giving a reference to a
> reference doesn't make any sense, and surely didn't do anything useful
> even before the change identified.  It would be better to make it throw
> an exception.

The other approach is to treat it similarly to how other non-string vars
are treated when used as strings, e.g. $x = \1; $x .= 2, which sets
$x to "SCALAR(0x11fd5b0)2".

> Similarly I suggest that open $fh, '<', \undef should also throw.

The test suite for PerlIO::scalar already explicitly expects undef
to behave like an empty string *without* generating any warnings.

I've pushed the following, which fixes the original bug report by going
down the stringifying route.


commit 552908b17471877454d99aa32f7ac5c29ea2efbb
Author:     David Mitchell <davem@iabyn.com>
AuthorDate: Thu Oct 17 15:35:14 2013 +0100
Commit:     David Mitchell <davem@iabyn.com>
CommitDate: Thu Oct 17 15:46:05 2013 +0100

    PerlIO::scalar: stringify refs
    
    If $s in
        open my $fh, "<",  \$s
    or similar is a ref, then
    stringify that ref: i.e. convert it from a ref into the string
    "SCALAR(0x....)" or whatever.
    
    This fixes
    
        RT #119529 Filehandle opened from ref to ref hangs on reading
    
    which in this case was looping forever, since it kept thinking that
    the var was a string ("SCALAR.."), but whose length was 0.
    
    I haven't gone for a complete "always force var into a string" approach,
    since PerlIO::scalar has quite a tolerance for "bad" vars; e.g.
    it won't warn if $var is undef or a read-only constant number etc;
    and it already normalises under some circumstances and not others.
    So I've just increased the cases somewhat where it normalises.
    
    Also, I didn't look to closely at the code that was looping (or to put it
    another way, I looked at it but didn't understand it), so it could
    conceivably still behave badly on some other strange type of variable that
    manages to avoid getting normalised.


-- 
"But Sidley Park is already a picture, and a most amiable picture too.
The slopes are green and gentle. The trees are companionably grouped at
intervals that show them to advantage. The rill is a serpentine ribbon
unwound from the lake peaceably contained by meadows on which the right
amount of sheep are tastefully arranged." -- Lady Croom, "Arcadia"

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About