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
Father Chrysostomos via RT
January 12, 2012 13:30
[perl #77388] Stacked file tests with -T, -t and/or -B remove too much from the stack
Message ID:
On Wed Jan 11 22:33:40 2012, sprout wrote:
> On Mon Aug 23 11:51:51 2010, 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
> >   <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
> >   <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

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