develooper Front page | perl.perl5.porters | Postings from January 2012

[perl #77388] Stacked file tests with -T, -t and/or -B remove too much from the stack

Thread Previous | Thread Next
From:
Father Chrysostomos via RT
Date:
January 12, 2012 13:30
Subject:
[perl #77388] Stacked file tests with -T, -t and/or -B remove too much from the stack
Message ID:
rt-3.6.HEAD-14510-1326403810-1141.77388-15-0@perl.org
On Wed Jan 11 22:33:40 2012, sprout wrote:
> On Mon Aug 23 11:51:51 2010, p5p@perl.wizbit.be wrote:
> > I had a talk with Jan Dubois about this (because he fixed a similar  
> > bug with -u/-g/-k on windows) and this are his notes:
> >   <jdb> It happens because pp_fttty and pp_fttext don't know about  
> > stacked file tests
> >   <jdb> The problem is that the stacked filetest doesn't leave the  
> > filename on the stack, it leaves the result of the test only.
> >   <jdb> So the next test in the sequence will pop the result with  
> > STACKED_FTEST_CHECK and either return early with a FALSE value, or  
> > continue checking
> >   <jdb> The checking will have to rely on PL_laststatval for the next  
> > test in the sequence
> >   <jdb> But the stat buffer doesn't contain the information that -T
needs
> >   <jdb> So it always pops something from the stack, even though there  
> > is nothing there in this case
> >   <Bram> I see. Is it fixable? Or should I create a bug report for it?
> >   <jdb> For pp_ftis is this hard to see because the actual stack logic  
> > is hidden in my_stat() in doio.c (my_stat_flags in 5.12)
> >   <jdb> Please create a bug report, I'm not sure how you can fix it
> easily.
> >   <jdb> Because the filename is gone by the time the second stacked  
> > filetest is executed.  So how are you going to make the check now?
> 
> The file name is in PL_statname.  The last gv is in PL_statgv.  -T and
> -B can already handle *_.  They just need to be taught to do so in
> stacked mode instead of popping something off the stack.
> 
> (There does seem to be another bug, though.  The code is not setting
> PL_laststype when called with a gv.  And I think a nonexistent file name
> will cause the internal stat status to get out of sync, as
> PL_last_stat_val and PL_statcache are not set until after the file is
> opened, but PL_laststype is set before.  Ouch, there is so much wrong
> with this code!)
> 
> >   <jdb> And extending my_stat() is not an option because -T is
*expensive*
> >   <jdb> It actually opens the file and reads the first 1024 bytes or  
> > something like that.
> >   <Bram> I'm not sure... the fix could be to disallow -T and -t in  
> > stacked file tests but I don't know how complicated that is..
> 
> But -t is difficult.  -r -w $foo is documented as being equivalent to -r
> $foo && -w _.  But -t doesn’t work with _.  We could make -t use _  when
> stacked, which would be silly.  I can’t think of a case where stacked -t
> is actually useful, which makes it hard to decide how it should work.
> 
> Actually, forget half of that.  -t could use PL_statgv, too.  We just
> need to document that -t -r is not exactly equivalent to -r && -t _.
> 
> Should -t -r "filename" be an error, or equivalent to -r "filename" &&
> -t "filename"?

Except that can’t really work either, because what would -r -t do? 
After all, -t doesn’t *set* the stat buffer, either.

I propose we make stacked -t an error in 5.16.  It has never worked,
it’s not clear how it should work, and if we try to make it do something
illogical we’ll be stuck ‘supporting’ that behaviour.

-- 

Father Chrysostomos


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=77388

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