Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Tie::StdHandle read() offset argument #12093

Closed
p5pRT opened this issue May 8, 2012 · 4 comments
Closed

Tie::StdHandle read() offset argument #12093

p5pRT opened this issue May 8, 2012 · 4 comments
Labels
distro-Linux type-library

Comments

@p5pRT
Copy link

p5pRT commented May 8, 2012

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

Searchable as RT112826$
@p5pRT
Copy link
Author

p5pRT commented May 8, 2012

From user42@zip.com.au

With debian packaged perl 5.14.2 and Tie​::StdHandle version 4.2, the
"offset" argument to read() is not obeyed by a tied handle. For example
foo.pl

  use strict;
  use Tie​::StdHandle;
  {
  open PP, '</dev/null';
  my $buf = "xxxxxxxxxx\n";
  read PP, $buf, 2, 5;
  print "plain​: \"$buf\"\n";
  }
  {
  tie *TT, 'Tie​::StdHandle', '</dev/null';
  my $buf = "xxxxxxxxxx\n";
  read TT, $buf, 2, 5;
  print "StdHandle​: \"$buf\"\n";
  }
  exit 0;

prints

  plain​: "xxxxx"
  StdHandle​: ""

where I expected StdHandle to leave $buf as "xxxxx" the same as a plain
handle.

Perhaps the READ method should notice an offset argument and pass it on
to the real read(). I get some joy from the following. Prototyping
prevents passing @​_ directly does it?, the same as done in OPEN().

sub READ {
  (@​_ > 3
  ? read($_[0],$_[1],$_[2],$_[3])
  : read($_[0],$_[1],$_[2]))
}

Perl Info 

Flags:
    category=library
    severity=medium
    module=Tie::StdHandle

Site configuration information for perl 5.14.2:

Configured by Debian Project at Sat Mar  3 16:40:46 UTC 2012.

Summary of my perl5 (revision 5 version 14 subversion 2) configuration:
   
  Platform:
    osname=linux, osvers=2.6.32-5-686-bigmem, archname=i486-linux-gnu-thread-multi-64int
    uname='linux murphy 2.6.32-5-686-bigmem #1 smp mon jan 16 16:42:05 utc 2012 i686 gnulinux '
    config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Dldflags= -Wl,-z,relro -Dlddlflags=-shared -Wl,-z,relro -Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.14 -Darchlib=/usr/lib/perl/5.14 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.14.2 -Dsitearch=/usr/local/lib/perl/5.14.2 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Duse64bitint -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -Ui_libutil -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.14.2 -des'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fstack-protector -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -g',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fstack-protector -fno-strict-aliasing -pipe -I/usr/local/include'
    ccversion='', gccversion='4.6.2', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib/i386-linux-gnu /lib/../lib /usr/lib/i386-linux-gnu /usr/lib/../lib /lib /usr/lib
    libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
    perllibs=-ldl -lm -lpthread -lc -lcrypt
    libc=, so=so, useshrplib=true, libperl=libperl.so.5.14.2
    gnulibc_version='2.13'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib -fstack-protector'

Locally applied patches:

@p5pRT
Copy link
Author

p5pRT commented Jun 22, 2012

From @cpansprout

On Tue May 08 15​:46​:57 2012, kryde wrote​:

With debian packaged perl 5.14.2 and Tie​::StdHandle version 4.2, the
"offset" argument to read() is not obeyed by a tied handle. For
example
foo.pl

use strict;
use Tie&#8203;::StdHandle;
\{
  open PP\, '\</dev/null';
  my $buf = "xxxxxxxxxx\\n";
  read PP\, $buf\, 2\, 5;
  print "plain&#8203;:     \\"$buf\\"\\n";
\}
\{
  tie \*TT\, 'Tie&#8203;::StdHandle'\, '\</dev/null';
  my $buf = "xxxxxxxxxx\\n";
  read TT\, $buf\, 2\, 5;
  print "StdHandle&#8203;: \\"$buf\\"\\n";
\}
exit 0;

prints

plain&#8203;:     "xxxxx"
StdHandle&#8203;: ""

where I expected StdHandle to leave $buf as "xxxxx" the same as a
plain
handle.

Perhaps the READ method should notice an offset argument and pass it
on
to the real read(). I get some joy from the following. Prototyping
prevents passing @​_ directly does it?, the same as done in OPEN().

sub READ {
(@​_ > 3
? read($_[0],$_[1],$_[2],$_[3])
: read($_[0],$_[1],$_[2]))
}

Fixed in commit 7762c37, where I used a slightly different approach.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Jun 22, 2012

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

@p5pRT
Copy link
Author

p5pRT commented Jun 22, 2012

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

@p5pRT p5pRT closed this as completed Jun 22, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
distro-Linux type-library
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@p5pRT