-T $filehandle seems broken

[p5pRT]

Migrated from rt.perl.org#23077 (status was 'resolved')

Searchable as RT23077$

[p5pRT]

From @kenahoo

Created by ken@mathforum.org

I've run the following test with both 5.6.1 and 5.8.0 on Mac OS X\, and it looks like -T $filehandle is returning different results (and incorrect ones at that) than -T $filename.

================== % echo foo > file % perl -le 'print 0 + -T "file"; open $fh\, "file" or die $!; print 0 +
-T $fh' 1 0

(I added zero for "clarity".)

I haven't tested the current 5.8.1 release candidate.

  -Ken

Perl Info

``` Flags: category=core severity=medium This perlbug was built using Perl v5.6.0 - Sun Jul 14 04:00:44 PDT 2002 It is being executed now by Perl v5.6.1 - Sun May 25 21:13:41 CDT 2003. Site configuration information for perl v5.6.1: Configured by ken at Sun May 25 21:13:41 CDT 2003. Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=darwin, osvers=6.6, archname=darwin uname='darwin junior.local. 6.6 darwin kernel version 6.6: thu may 1 21:48:54 pdt 2003; root:xnuxnu-344.34.obj~1release_ppc power macintosh powerpc ' config_args='-des -Dfirstmakefile=GNUmakefile -Dldflags=-flat_namespace -Dprefix=/sw -Dinstallprefix=/sw -Uinstallusrbinperl -Dman3ext=3perl' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cc', ccflags ='-pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing', optimize='-O3', cppflags='-pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing' ccversion='', gccversion='Apple cpp-precomp 6.14', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags ='-flat_namespace -L/usr/local/lib' libpth=/usr/local/lib /usr/lib libs=-lm -lc perllibs=-lm -lc libc=/System/Library/Frameworks/System.framework/System, so=dylib, useshrplib=true, libperl=libperl.dylib Dynamic Linking: dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-flat_namespace -bundle -undefined suppress -L/usr/local/lib' Locally applied patches: @INC for perl v5.6.1: /sw/lib/perl5/5.6.1/darwin /sw/lib/perl5/5.6.1 /sw/lib/perl5/darwin /sw/lib/perl5 /sw/lib/perl5/5.6.1/darwin /sw/lib/perl5/5.6.1 /Library/Perl/darwin /Library/Perl /Library/Perl . Environment for perl v5.6.1: DYLD_LIBRARY_PATH (unset) HOME=/Users/ken LANG (unset) LANGUAGE (unset) LC_ALL=C LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/sw/bin:/sw/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/ Users/ken/bin:.:/usr/X11R6/bin PERL5LIB=/sw/lib/perl5 PERL_BADLANG (unset) SHELL=/bin/tcsh ```

[p5pRT]

From @smpeters

[kwilliams - Mon Jul 21 11​:39​:00 2003]​:

I've run the following test with both 5.6.1 and 5.8.0 on Mac OS X\, and it looks like -T $filehandle is returning different results (and incorrect ones at that) than -T $filename.

================== % echo foo > file % perl -le 'print 0 + -T "file"; open $fh\, "file" or die $!; print 0 +
-T $fh' 1 0 ==================

(I added zero for "clarity".)

I haven't tested the current 5.8.1 release candidate.

-Ken

I was able to recreate this still on 5.8.5 and the current blead.
There is one question that I have though. I found this little chuck of code in pp_sys.c.

  if (io && IoIFP(io)) {   if (! PerlIO_has_base(IoIFP(io)))   DIE(aTHX_ "-T and -B not implemented on filehandles");   PL_laststatval = PerlLIO_fstat(PerlIO_fileno(IoIFP(io))\, &PL_statcache); ...

Is this some old artifact or should a -T or -B on a filehandle cause perl to die?

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @mjdominus

"Steve Peters via RT" \perlbug\-followup@​perl\.org​:

Is this some old artifact or should a -T or -B on a filehandle cause perl to die?

The problem with -T on a filehandle is that it requires that Perl read some of the data out of the handle and examine it for icky characters. But then that data is no longer available to the user\, so the filehandle is essentially spoiled. That is the reason that the original intention was for it to die.

With the advent of PerlIO\, it might be the case that this can be worked around. But if not\, Perl should die.

[p5pRT]

From nick@ing-simmons.net

Mark Jason Dominus \mjd@​plover\.com writes​:

"Steve Peters via RT" \perlbug\-followup@​perl\.org​:

Is this some old artifact or should a -T or -B on a filehandle cause perl to die?

The problem with -T on a filehandle is that it requires that Perl read some of the data out of the handle and examine it for icky characters. But then that data is no longer available to the user\, so the filehandle is essentially spoiled. That is the reason that the original intention was for it to die.

With the advent of PerlIO\, it might be the case that this can be worked around. But if not\, Perl should die.

-T on a filehandle works by snooping in the buffer. This has worked ok long before PerlIO where buffer snooping could be detected by Configure. What PerlIO does is extend snooping to any platform (by using :perlio layer if :stdio is not snoopable).

[p5pRT]

From @cpansprout

This was fixed in 5.10.0.

$ perl5.8.9 -le 'print 0 + -T "file"; open $fh\, "file" or die $!; print 0 + -T $fh' 1 0

$ perl5.10.0 -le 'print 0 + -T "file"; open $fh\, "file" or die $!; print 0 + -T $fh' 1 1

[p5pRT]

@cpansprout - Status changed from 'open' to 'resolved'