Front page | perl.perl5.porters |
Postings from January 2012
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=77388Thread Previous | Thread Next