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

pragma open handles STDERR improperly #11441

Closed
p5pRT opened this issue Jun 13, 2011 · 25 comments
Closed

pragma open handles STDERR improperly #11441

p5pRT opened this issue Jun 13, 2011 · 25 comments

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Jun 13, 2011

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

Searchable as RT92728$

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 13, 2011

From uhuruh@gmail.com

This is a bug report for perl from Yunfeng Wang <uhuruh@​gmail.com>,
generated with the help of perlbug 1.39 running under perl 5.12.3.


After the default PerlIO layer for STDIN/STDOUT/STDERR been set with
the :std subpragma, a second call to `use open ...' without :std will
undo the settings of STDIN and/or STDOUT, while leave STDERR untouched.
The expected behavior is to treat STDERR the same way as to STDOUT.

Example code​:

1. use open '​:encoding(UTF-8)', '​:std';
2. # the I/O layer of STDIN/STDOUT/STDERR is set to :encoding(UTF-8)
3. use open '​:encoding(UTF-8)';
4. # layer :encoding(UTF-8) is dropped for STDOUT, but not for STDERR

Here is a patch to fix this bug​:

Inline Patch
--- /usr/share/perl/5.12.3/open.pm      2011-05-20 03:02:33.000000000 +0800
+++ open.pm     2011-06-13 19:03:59.000000000 +0800
@@ -100,11 +100,13 @@
        }
        elsif ($type eq 'OUT') {
            _drop_oldenc(*STDOUT, @val);
+           _drop_oldenc(*STDERR, @val);
            $out = join(' ', @val);
        }
        elsif ($type eq 'IO') {
            _drop_oldenc(*STDIN,  @val);
            _drop_oldenc(*STDOUT, @val);
+           _drop_oldenc(*STDERR, @val);
            $in = $out = join(' ', @val);
        }
        else {

-----------------------------------------------------------------
---
Flags:   category=library   severity=low   module=open

Site configuration information for perl 5.12.3​:

Configured by Debian Project at Thu May 19 18​:42​:35 UTC 2011.

Summary of my perl5 (revision 5 version 12 subversion 3) configuration​:
  Derived from​:
  Platform​:
  osname=linux, osvers=2.6.32-5-686,
archname=i486-linux-gnu-thread-multi-64int
  uname='linux callisto 2.6.32-5-686 #1 smp tue mar 8 21​:36​:00 utc
2011 i686 gnulinux '
  config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN
-Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr
-Dprivlib=/usr/share/perl/5.12 -Darchlib=/usr/lib/perl/5.12
-Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5
-Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local
-Dsitelib=/usr/local/share/perl/5.12.3
-Dsitearch=/usr/local/lib/perl/5.12.3 -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
-Dplibpth=/lib/i386-linux-gnu /usr/lib/i386-linux-gnu -Duseshrplib
-Dlibperl=libperl.so.5.12.3 -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
-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize='-O2 -g',
  cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing
-pipe -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.6.1 20110507 (prerelease)', 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 /usr/lib /usr/lib64
  libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
  perllibs=-ldl -lm -lpthread -lc -lcrypt
  libc=/lib/libc-2.13.so, so=so, useshrplib=true, libperl=libperl.so.5.12.3
  gnulibc_version='2.13'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib
-fstack-protector'

Locally applied patches​:
  DEBPKG​:debian/arm_thread_stress_timeout -
http​://bugs.debian.org/501970 Raise the timeout of
ext/threads/shared/t/stress.t to accommodate slower build hosts
  DEBPKG​:debian/cpan_config_path - Set location of CPAN​::Config to
/etc/perl as /usr may not be writable.
  DEBPKG​:debian/cpan_definstalldirs - Provide a sensible INSTALLDIRS
default for modules installed from CPAN.
  DEBPKG​:debian/db_file_ver - http​://bugs.debian.org/340047 Remove
overly restrictive DB_File version check.
  DEBPKG​:debian/doc_info - Replace generic man(1) instructions with
Debian-specific information.
  DEBPKG​:debian/enc2xs_inc - http​://bugs.debian.org/290336 Tweak
enc2xs to follow symlinks and ignore missing @​INC directories.
  DEBPKG​:debian/errno_ver - http​://bugs.debian.org/343351 Remove
Errno version check due to upgrade problems with long-running
processes.
  DEBPKG​:debian/extutils_hacks - Various debian-specific ExtUtils changes
  DEBPKG​:debian/fakeroot - Postpone LD_LIBRARY_PATH evaluation to
the binary targets.
  DEBPKG​:debian/instmodsh_doc - Debian policy doesn't install
.packlist files for core or vendor.
  DEBPKG​:debian/ld_run_path - Remove standard libs from LD_RUN_PATH
as per Debian policy.
  DEBPKG​:debian/libnet_config_path - Set location of libnet.cfg to
/etc/perl/Net as /usr may not be writable.
  DEBPKG​:debian/m68k_thread_stress - http​://bugs.debian.org/495826
Disable some threads tests on m68k for now due to missing TLS.
  DEBPKG​:debian/mod_paths - Tweak @​INC ordering for Debian
  DEBPKG​:debian/module_build_man_extensions -
http​://bugs.debian.org/479460 Adjust Module​::Build manual page
extensions for the Debian Perl policy
  DEBPKG​:debian/prune_libs - http​://bugs.debian.org/128355 Prune the
list of libraries wanted to what we actually need.
  DEBPKG​:fixes/net_smtp_docs - http​://bugs.debian.org/100195
[rt.cpan.org #36038] Document the Net​::SMTP 'Port' option
  DEBPKG​:fixes/processPL - http​://bugs.debian.org/357264
[rt.cpan.org #17224] Always use PERLRUNINST when building perl
modules.
  DEBPKG​:debian/perlivp - http​://bugs.debian.org/510895 Make perlivp
skip include directories in /usr/local
  DEBPKG​:debian/disable-zlib-bundling - Disable zlib bundling in
Compress​::Raw​::Zlib
  DEBPKG​:debian/cpanplus_definstalldirs -
http​://bugs.debian.org/533707 Configure CPANPLUS to use the site
directories by default.
  DEBPKG​:debian/cpanplus_config_path - Save local versions of
CPANPLUS​::Config​::System into /etc/perl.
  DEBPKG​:fixes/autodie-flock - http​://bugs.debian.org/543731 Allow
for flock returning EAGAIN instead of EWOULDBLOCK on linux/parisc
  DEBPKG​:debian/devel-ppport-ia64-optim -
http​://bugs.debian.org/548943 Work around an ICE on ia64
  DEBPKG​:fixes/cpanplus-without-home - http​://bugs.debian.org/577011
[rt.cpan.org #52988] Fix CPANPLUS test failures when HOME doesn't
exist
  DEBPKG​:debian/arm_optim - http​://bugs.debian.org/580334 Downgrade
the optimization of sv.c on arm due to a gcc-4.4 bug
  DEBPKG​:debian/deprecate-with-apt - http​://bugs.debian.org/580034
Point users to Debian packages of deprecated core modules
  DEBPKG​:fixes/hurd-ccflags - http​://bugs.debian.org/587901 Make
hints/gnu.sh append to $ccflags rather than overriding them
  DEBPKG​:debian/squelch-locale-warnings -
http​://bugs.debian.org/508764 Squelch locale warnings in Debian
package maintainer scripts
  DEBPKG​:fixes/lc-numeric-docs - http​://bugs.debian.org/379329 [perl
#78452] [903eb63] LC_NUMERIC documentation fixes
  DEBPKG​:fixes/lc-numeric-sprintf - http​://bugs.debian.org/601549
[perl #78632] [b3fd614] Fix sprintf not to ignore LC_NUMERIC with
constants
  DEBPKG​:fixes/concat-stack-corruption -
http​://bugs.debian.org/596105 [perl #78674] [e3393f5] Fix stack
pointer corruption in pp_concat() with 'use encoding'
  DEBPKG​:fixes/h2ph-gcc-4.5 - http​://bugs.debian.org/599933
[8d66b3f] h2ph fix for gcc 4.5
  DEBPKG​:fixes/casing-taint-cve-2011-1487 -
http​://bugs.debian.org/622817 [perl #87336] fix unwanted taint
laundering in lc(), uc() et al.
  DEBPKG​:fixes/correct-module-corelist-version - [a0a0e54] Correct
the version of Module​::CoreList that was released with v5.12.3
  DEBPKG​:fixes/module-build-home-directory -
http​://bugs.debian.org/624850 [rt.cpan.org #67893] Fix failing tilde
test when run under a UID without a passwd entry
  DEBPKG​:patchlevel - http​://bugs.debian.org/567489 List packaged
patches for 5.12.3-7 in patchlevel.h


@​INC for perl 5.12.3​:
  /etc/perl
  /usr/local/lib/perl/5.12.3
  /usr/local/share/perl/5.12.3
  /usr/lib/perl5
  /usr/share/perl5
  /usr/lib/perl/5.12
  /usr/share/perl/5.12
  /usr/local/lib/site_perl
  .


Environment for perl 5.12.3​:
  HOME=/home/yfwang
  LANG=zh_CN.UTF-8
  LANGUAGE=zh_CN​:zh
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/home/yfwang/bin​:/usr/local/bin​:/usr/bin​:/bin​:/usr/games
  PERL_BADLANG (unset)
  SHELL=/bin/bash

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 19, 2011

From @cpansprout

On Mon Jun 13 05​:04​:49 2011, uhuruh@​gmail.com wrote​:

After the default PerlIO layer for STDIN/STDOUT/STDERR been set with
the :std subpragma, a second call to `use open ...' without :std will
undo the settings of STDIN and/or STDOUT, while leave STDERR
untouched.
The expected behavior is to treat STDERR the same way as to STDOUT.

Example code​:

1. use open '​:encoding(UTF-8)', '​:std';
2. # the I/O layer of STDIN/STDOUT/STDERR is set to :encoding(UTF-8)
3. use open '​:encoding(UTF-8)';
4. # layer :encoding(UTF-8) is dropped for STDOUT, but not for STDERR

While they should be treated the same way, are you sure it’s STDERR, and
not STDIN/OUT, that’s buggy?

Doing anything with STD* handles without :std’s having been specified
seems like a bug to me.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 19, 2011

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

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 11, 2011

From @cpansprout

On Sun Jun 19 12​:20​:09 2011, sprout wrote​:

On Mon Jun 13 05​:04​:49 2011, uhuruh@​gmail.com wrote​:

After the default PerlIO layer for STDIN/STDOUT/STDERR been set with
the :std subpragma, a second call to `use open ...' without :std will
undo the settings of STDIN and/or STDOUT, while leave STDERR
untouched.
The expected behavior is to treat STDERR the same way as to STDOUT.

Example code​:

1. use open '​:encoding(UTF-8)', '​:std';
2. # the I/O layer of STDIN/STDOUT/STDERR is set to :encoding(UTF-8)
3. use open '​:encoding(UTF-8)';
4. # layer :encoding(UTF-8) is dropped for STDOUT, but not for STDERR

While they should be treated the same way, are you sure it’s STDERR, and
not STDIN/OUT, that’s buggy?

Doing anything with STD* handles without :std’s having been specified
seems like a bug to me.

What do others think about this?

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 11, 2011

From [Unknown Contact. See original ticket]

On Sun Jun 19 12​:20​:09 2011, sprout wrote​:

On Mon Jun 13 05​:04​:49 2011, uhuruh@​gmail.com wrote​:

After the default PerlIO layer for STDIN/STDOUT/STDERR been set with
the :std subpragma, a second call to `use open ...' without :std will
undo the settings of STDIN and/or STDOUT, while leave STDERR
untouched.
The expected behavior is to treat STDERR the same way as to STDOUT.

Example code​:

1. use open '​:encoding(UTF-8)', '​:std';
2. # the I/O layer of STDIN/STDOUT/STDERR is set to :encoding(UTF-8)
3. use open '​:encoding(UTF-8)';
4. # layer :encoding(UTF-8) is dropped for STDOUT, but not for STDERR

While they should be treated the same way, are you sure it’s STDERR, and
not STDIN/OUT, that’s buggy?

Doing anything with STD* handles without :std’s having been specified
seems like a bug to me.

What do others think about this?

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 12, 2011

From tchrist@perl.com

"Father Chrysostomos via RT" <perlbug-comment@​perl.org> wrote
  on Sun, 11 Sep 2011 16​:29​:19 PDT​:

Doing anything with STD* handles without :std�s having been specified
seems like a bug to me.

What do others think about this?

Yeah, kinda seems like it.

That said, I've been too burned by the fatal combo of use open
and use autodie to rely on anything working at all anymore.
You have to spell it all out, because it just doesn't work.
I don't know whether this is the same level of epic fail that
use encoding did, but right now it is not usable.

--tom

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 12, 2011

From @cpansprout

On Sun Sep 11 17​:13​:29 2011, tom christiansen wrote​:

"Father Chrysostomos via RT" <perlbug-comment@​perl.org> wrote
on Sun, 11 Sep 2011 16​:29​:19 PDT​:

Doing anything with STD* handles without :std’s having been specified
seems like a bug to me.

What do others think about this?

Yeah, kinda seems like it.

That said, I've been too burned by the fatal combo of use open
and use autodie to rely on anything working at all anymore.

(CPAN bug #54777)

autodie is completely broken, as it does not propagate pragmata, and
changes the parsing of anything with a * prototype.

If it were re-implemented in XS, it would probably take much much less
code, and it would be almost bug-free.

You have to spell it all out, because it just doesn't work.
I don't know whether this is the same level of epic fail that
use encoding did, but right now it is not usable.

--tom

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 12, 2011

From [Unknown Contact. See original ticket]

On Sun Sep 11 17​:13​:29 2011, tom christiansen wrote​:

"Father Chrysostomos via RT" <perlbug-comment@​perl.org> wrote
on Sun, 11 Sep 2011 16​:29​:19 PDT​:

Doing anything with STD* handles without :std’s having been specified
seems like a bug to me.

What do others think about this?

Yeah, kinda seems like it.

That said, I've been too burned by the fatal combo of use open
and use autodie to rely on anything working at all anymore.

(CPAN bug #54777)

autodie is completely broken, as it does not propagate pragmata, and
changes the parsing of anything with a * prototype.

If it were re-implemented in XS, it would probably take much much less
code, and it would be almost bug-free.

You have to spell it all out, because it just doesn't work.
I don't know whether this is the same level of epic fail that
use encoding did, but right now it is not usable.

--tom

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 12, 2011

From @Tux

On Sun, 11 Sep 2011 16​:29​:19 -0700, "Father Chrysostomos via RT"
<perlbug-comment@​perl.org> wrote​:

On Sun Jun 19 12​:20​:09 2011, sprout wrote​:

On Mon Jun 13 05​:04​:49 2011, uhuruh@​gmail.com wrote​:

After the default PerlIO layer for STDIN/STDOUT/STDERR been set with
the :std subpragma, a second call to `use open ...' without :std will
undo the settings of STDIN and/or STDOUT, while leave STDERR
untouched.
The expected behavior is to treat STDERR the same way as to STDOUT.

Example code​:

1. use open '​:encoding(UTF-8)', '​:std';
2. # the I/O layer of STDIN/STDOUT/STDERR is set to :encoding(UTF-8)
3. use open '​:encoding(UTF-8)';
4. # layer :encoding(UTF-8) is dropped for STDOUT, but not for STDERR

While they should be treated the same way, are you sure it’s STDERR, and
not STDIN/OUT, that’s buggy?

Doing anything with STD* handles without :std’s having been specified
seems like a bug to me.

What do others think about this?

I feel the described situation as inconsistent and thus buggy

There are way more difficult bugs (open) with open pragma and encoding.

Se e.g. https://rt.cpan.org/Ticket/Display.html?id=66474

--
H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/
using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3.
http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/
http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 12, 2011

From @pjcj

On Sun, Sep 11, 2011 at 06​:22​:55PM -0700, Father Chrysostomos via RT wrote​:

autodie is completely broken, as it does not propagate pragmata, and
changes the parsing of anything with a * prototype.

If it were re-implemented in XS, it would probably take much much less
code, and it would be almost bug-free.

If someone /were/ to undertake such a task, I would *really* like to see
autodie work with filehandles that are automatically closed, whether by
going out of scope or for some other reason.

(And if it's not quite backwards compatible, we can even give it a decent
name. *Ducks*)

--
Paul Johnson - paul@​pjcj.net
http​://www.pjcj.net

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 12, 2011

From @cpansprout

On Sun Sep 11 23​:25​:50 2011, hmbrand wrote​:

On Sun, 11 Sep 2011 16​:29​:19 -0700, "Father Chrysostomos via RT"
<perlbug-comment@​perl.org> wrote​:

On Sun Jun 19 12​:20​:09 2011, sprout wrote​:

On Mon Jun 13 05​:04​:49 2011, uhuruh@​gmail.com wrote​:

After the default PerlIO layer for STDIN/STDOUT/STDERR been set with
the :std subpragma, a second call to `use open ...' without :std
will
undo the settings of STDIN and/or STDOUT, while leave STDERR
untouched.
The expected behavior is to treat STDERR the same way as to STDOUT.

Example code​:

1. use open '​:encoding(UTF-8)', '​:std';
2. # the I/O layer of STDIN/STDOUT/STDERR is set to
:encoding(UTF-8)
3. use open '​:encoding(UTF-8)';
4. # layer :encoding(UTF-8) is dropped for STDOUT, but not for
STDERR

While they should be treated the same way, are you sure it’s
STDERR, and
not STDIN/OUT, that’s buggy?

Doing anything with STD* handles without :std’s having been specified
seems like a bug to me.

What do others think about this?

I feel the described situation as inconsistent and thus buggy

There are way more difficult bugs (open) with open pragma and encoding.

Se e.g. https://rt.cpan.org/Ticket/Display.html?id=66474

Ouch! I would definitely consider that a bug. But I have *no* idea how
to fix it without introducing a page of inefficient hacks.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 12, 2011

From [Unknown Contact. See original ticket]

On Sun Sep 11 23​:25​:50 2011, hmbrand wrote​:

On Sun, 11 Sep 2011 16​:29​:19 -0700, "Father Chrysostomos via RT"
<perlbug-comment@​perl.org> wrote​:

On Sun Jun 19 12​:20​:09 2011, sprout wrote​:

On Mon Jun 13 05​:04​:49 2011, uhuruh@​gmail.com wrote​:

After the default PerlIO layer for STDIN/STDOUT/STDERR been set with
the :std subpragma, a second call to `use open ...' without :std
will
undo the settings of STDIN and/or STDOUT, while leave STDERR
untouched.
The expected behavior is to treat STDERR the same way as to STDOUT.

Example code​:

1. use open '​:encoding(UTF-8)', '​:std';
2. # the I/O layer of STDIN/STDOUT/STDERR is set to
:encoding(UTF-8)
3. use open '​:encoding(UTF-8)';
4. # layer :encoding(UTF-8) is dropped for STDOUT, but not for
STDERR

While they should be treated the same way, are you sure it’s
STDERR, and
not STDIN/OUT, that’s buggy?

Doing anything with STD* handles without :std’s having been specified
seems like a bug to me.

What do others think about this?

I feel the described situation as inconsistent and thus buggy

There are way more difficult bugs (open) with open pragma and encoding.

Se e.g. https://rt.cpan.org/Ticket/Display.html?id=66474

Ouch! I would definitely consider that a bug. But I have *no* idea how
to fix it without introducing a page of inefficient hacks.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 12, 2011

From @Leont

On Mon, Sep 12, 2011 at 8​:25 AM, H.Merijn Brand <h.m.brand@​xs4all.nl> wrote​:

I feel the described situation as inconsistent and thus buggy

There are way more difficult bugs (open) with open pragma and encoding.

Se e.g. https://rt.cpan.org/Ticket/Display.html?id=66474

Yeah, I've got two bugs against open too (#96008 and #97822). Quite
frankly both open and autodie are ugly hacks with severe issues,
despite not being bad ideas.

Leon

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 16, 2011

From @cpansprout

On Sun Jun 19 12​:20​:09 2011, sprout wrote​:

On Mon Jun 13 05​:04​:49 2011, uhuruh@​gmail.com wrote​:

After the default PerlIO layer for STDIN/STDOUT/STDERR been set with
the :std subpragma, a second call to `use open ...' without :std will
undo the settings of STDIN and/or STDOUT, while leave STDERR
untouched.
The expected behavior is to treat STDERR the same way as to STDOUT.

Example code​:

1. use open '​:encoding(UTF-8)', '​:std';
2. # the I/O layer of STDIN/STDOUT/STDERR is set to :encoding(UTF-8)
3. use open '​:encoding(UTF-8)';
4. # layer :encoding(UTF-8) is dropped for STDOUT, but not for STDERR

While they should be treated the same way, are you sure it’s STDERR, and
not STDIN/OUT, that’s buggy?

Doing anything with STD* handles without :std’s having been specified
seems like a bug to me.

That’s now fixed with commit 73f1eac.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 16, 2011

From @cpansprout

On Mon Sep 12 02​:50​:31 2011, paul@​pjcj.net wrote​:

On Sun, Sep 11, 2011 at 06​:22​:55PM -0700, Father Chrysostomos via RT
wrote​:

autodie is completely broken, as it does not propagate pragmata, and
changes the parsing of anything with a * prototype.

If it were re-implemented in XS, it would probably take much much less
code, and it would be almost bug-free.

If someone /were/ to undertake such a task, I would *really* like to see
autodie work with filehandles that are automatically closed, whether by
going out of scope or for some other reason.

(And if it's not quite backwards compatible, we can even give it a decent
name. *Ducks*)

Like Fatal, perhaps?

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 16, 2011

From [Unknown Contact. See original ticket]

On Mon Sep 12 02​:50​:31 2011, paul@​pjcj.net wrote​:

On Sun, Sep 11, 2011 at 06​:22​:55PM -0700, Father Chrysostomos via RT
wrote​:

autodie is completely broken, as it does not propagate pragmata, and
changes the parsing of anything with a * prototype.

If it were re-implemented in XS, it would probably take much much less
code, and it would be almost bug-free.

If someone /were/ to undertake such a task, I would *really* like to see
autodie work with filehandles that are automatically closed, whether by
going out of scope or for some other reason.

(And if it's not quite backwards compatible, we can even give it a decent
name. *Ducks*)

Like Fatal, perhaps?

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 16, 2011

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

@p5pRT p5pRT closed this Sep 16, 2011
@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 17, 2011

From @cpansprout

On Mon Sep 12 06​:02​:42 2011, sprout wrote​:

On Sun Sep 11 23​:25​:50 2011, hmbrand wrote​:

There are way more difficult bugs (open) with open pragma and encoding.

Se e.g. https://rt.cpan.org/Ticket/Display.html?id=66474

Ouch! I would definitely consider that a bug. But I have *no* idea how
to fix it without introducing a page of inefficient hacks.

Attached is a page of efficient hacks. I still have to get it working
in 5.6 and 5.8. Is this type of hack acceptable? I think it’s robust
enough.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 17, 2011

From @cpansprout

Inline Patch
diff --git a/MANIFEST b/MANIFEST
index 1cd70f6..4ed4aa1 100644
--- a/MANIFEST
+++ b/MANIFEST
@@ -3172,6 +3172,7 @@ dist/IO/t/io_taint.t		See if the untaint method from IO works
 dist/IO/t/io_tell.t		See if seek()/tell()-related methods from IO work
 dist/IO/t/io_udp.t		See if UDP socket-related methods from IO work
 dist/IO/t/io_unix.t		See if UNIX socket-related methods from IO work
+dist/IO/t/io_utf8argv.t		See if <> respects open pragma
 dist/IO/t/io_utf8.t		See if perlio opens work
 dist/IO/t/io_xs.t		See if XSUB methods from IO work
 dist/lib/lib_pm.PL		For "use lib", produces lib/lib.pm
diff --git a/dist/IO/IO.pm b/dist/IO/IO.pm
index 09143f2..e6f5567 100644
--- a/dist/IO/IO.pm
+++ b/dist/IO/IO.pm
@@ -7,7 +7,7 @@ use Carp;
 use strict;
 use warnings;
 
-our $VERSION = "1.25_05";
+our $VERSION = "1.25_06";
 XSLoader::load 'IO', $VERSION;
 
 sub import {
diff --git a/dist/IO/IO.xs b/dist/IO/IO.xs
index d696603..ac56453 100644
--- a/dist/IO/IO.xs
+++ b/dist/IO/IO.xs
@@ -142,6 +142,27 @@ io_blocking(pTHX_ InputStream f, int block)
 #endif
 }
 
+static OP *
+io_pp_nextstate(pTHX)
+{
+    dVAR;
+    COP *old_curcop = PL_curcop;
+    OP *next = PL_ppaddr[PL_op->op_type](aTHX);
+    PL_curcop = old_curcop;
+    return next;
+}
+
+static OP *
+io_ck_lineseq(pTHX_ OP *o)
+{
+    OP *kid = cBINOPo->op_first;
+    for (; kid; kid = kid->op_sibling)
+	if (kid->op_type == OP_NEXTSTATE || kid->op_type == OP_DBSTATE)
+	    kid->op_ppaddr = io_pp_nextstate;
+    return o;
+}
+
+
 MODULE = IO	PACKAGE = IO::Seekable	PREFIX = f
 
 void
@@ -457,6 +478,18 @@ fsync(handle)
     OUTPUT:
 	RETVAL
 
+SV *
+_create_getline_subs(const char *code)
+    PREINIT:
+	SV *ret;
+    CODE:
+	OP *(*io_old_ck_lineseq)(pTHX_ OP *) = PL_check[OP_LINESEQ];
+	PL_check[OP_LINESEQ] = io_ck_lineseq;
+	RETVAL = SvREFCNT_inc(eval_pv(code,FALSE));
+	PL_check[OP_LINESEQ] = io_old_ck_lineseq;
+    OUTPUT:
+	RETVAL
+
 
 MODULE = IO	PACKAGE = IO::Socket
 
diff --git a/dist/IO/lib/IO/Handle.pm b/dist/IO/lib/IO/Handle.pm
index c15e5a3..68e6d90 100644
--- a/dist/IO/lib/IO/Handle.pm
+++ b/dist/IO/lib/IO/Handle.pm
@@ -268,7 +268,7 @@ use IO ();	# Load the XS module
 require Exporter;
 @ISA = qw(Exporter);
 
-$VERSION = "1.32";
+$VERSION = "1.33";
 $VERSION = eval $VERSION;
 
 @EXPORT_OK = qw(
@@ -430,14 +430,14 @@ sub say {
     print $this @_;
 }
 
+# Special XS wrapper to make them inherit lexical hints from the caller.
+_create_getline_subs( <<'END' ) or die $@;
 sub getline {
     @_ == 1 or croak 'usage: $io->getline()';
     my $this = shift;
     return scalar <$this>;
 } 
 
-*gets = \&getline;  # deprecated
-
 sub getlines {
     @_ == 1 or croak 'usage: $io->getlines()';
     wantarray or
@@ -445,6 +445,10 @@ sub getlines {
     my $this = shift;
     return <$this>;
 }
+1; # return true for error checking
+END
+
+*gets = \&getline;  # deprecated
 
 sub truncate {
     @_ == 2 or croak 'usage: $io->truncate(LEN)';
diff --git a/dist/IO/t/IO.t b/dist/IO/t/IO.t
index effd414..382e282 100644
--- a/dist/IO/t/IO.t
+++ b/dist/IO/t/IO.t
@@ -21,8 +21,10 @@ plan(tests => 18);
 
 	my @load;
 	local $^W;
+	my $xsl = \&XSLoader::load;
 	local *XSLoader::load = sub {
 		push @load, \@_;
+		&$xsl(@_);
 	};
 
 	# use_ok() calls import, which we do not want to do
diff --git a/dist/IO/t/io_utf8argv.t b/dist/IO/t/io_utf8argv.t
new file mode 100644
index 0000000..c97c260
--- /dev/null
+++ b/dist/IO/t/io_utf8argv.t
@@ -0,0 +1,38 @@
+#!./perl
+
+BEGIN {
+    unless ($] >= 5.008 and find PerlIO::Layer 'perlio') {
+	print "1..0 # Skip: not perlio\n";
+	exit 0;
+    }
+    require($ENV{PERL_CORE} ? "../../t/test.pl" : "./t/test.pl");
+}
+
+use utf8;
+
+
+plan(tests => 2);
+
+open my $fh, ">", 'io_utf8argv';
+print $fh
+   "\xce\x9c\xe1\xbd\xb7\xce\xb1\x20\xcf\x80\xe1\xbd\xb1\xcf\x80\xce".
+   "\xb9\xce\xb1\x2c\x20\xce\xbc\xe1\xbd\xb0\x20\xcf\x80\xce\xbf\xce".
+   "\xb9\xe1\xbd\xb0\x20\xcf\x80\xe1\xbd\xb1\xcf\x80\xce\xb9\xce\xb1".
+   "\xcd\xbe\x0a";
+close $fh or die "close: $!";
+
+
+use open ":std", ":utf8";
+
+use IO::Handle;
+
+@ARGV = ('io_utf8argv') x 2;
+is *ARGV->getline, "Μία πάπια, μὰ ποιὰ πάπια;\n",
+  'getline respects open pragma when magically opening ARGV';
+
+is join('',*ARGV->getlines), "Μία πάπια, μὰ ποιὰ πάπια;\n",
+  'getlines respects open pragma when magically opening ARGV';
+
+END {
+  1 while unlink "io_utf8argv";
+}
@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 17, 2011

From [Unknown Contact. See original ticket]

On Mon Sep 12 06​:02​:42 2011, sprout wrote​:

On Sun Sep 11 23​:25​:50 2011, hmbrand wrote​:

There are way more difficult bugs (open) with open pragma and encoding.

Se e.g. https://rt.cpan.org/Ticket/Display.html?id=66474

Ouch! I would definitely consider that a bug. But I have *no* idea how
to fix it without introducing a page of inefficient hacks.

Attached is a page of efficient hacks. I still have to get it working
in 5.6 and 5.8. Is this type of hack acceptable? I think it’s robust
enough.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 17, 2011

From tchrist@perl.com

"Father Chrysostomos via RT" <perlbug-comment@​perl.org> wrote
  on Sat, 17 Sep 2011 00​:10​:19 PDT​:

+use open "​:std", "​:utf8";
+
+use IO​::Handle;
+
+@​ARGV = ('io_utf8argv') x 2;
+is *ARGV->getline, "Μία πάπια, μὰ ποιὰ πάπια;\n",
+ 'getline respects open pragma when magically opening ARGV';
+
+is join('',*ARGV->getlines), "Μία πάπια, μὰ ποιὰ πάπια;\n",
+ 'getlines respects open pragma when magically opening ARGV';
+
+END {
+ 1 while unlink "io_utf8argv";
+}

What's the deal with how/whether the open works on magic ARGV?

Is the answer version-dependent?

--tom

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 17, 2011

From @cpansprout

On Sat Sep 17 09​:26​:32 2011, tom christiansen wrote​:

"Father Chrysostomos via RT" <perlbug-comment@​perl.org> wrote
on Sat, 17 Sep 2011 00​:10​:19 PDT​:

+use open "​:std", "​:utf8";
+
+use IO​::Handle;
+
+@​ARGV = ('io_utf8argv') x 2;
+is *ARGV->getline, "Μία πάπια, μὰ ποιὰ πάπια;\n",
+ 'getline respects open pragma when magically opening ARGV';
+
+is join('',*ARGV->getlines), "Μία πάπια, μὰ ποιὰ πάπια;\n",
+ 'getlines respects open pragma when magically opening ARGV';
+
+END {
+ 1 while unlink "io_utf8argv";
+}

What's the deal with how/whether the open works on magic ARGV?

<ARGV> does an implicit open using the lexical hints at the point where
the <ARGV> occurs.

That means that ‘use open ...; while(<>)’ will set the layers on ARGV
based on that ‘use open’ directive.

Because IO​::Handle​::getline is a Perl subroutine, the <ARGV> is called
from there, outside the scope of the open pragma.

My patch fiddles PL_curcop to make getline’s caller’s hints visible to <>.

Is the answer version-dependent?

No. In fact, with the #ifndef show below, my patch works all the way
back to 5.6, which suggests it’s the right way to go.

And that ‘No’ applies, whether you are referring to the IO​::Handle bug,
the behaviour of <>, or my patch.

#ifndef dVAR
# define dVAR dNOOP
#endif

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 17, 2011

From [Unknown Contact. See original ticket]

On Sat Sep 17 09​:26​:32 2011, tom christiansen wrote​:

"Father Chrysostomos via RT" <perlbug-comment@​perl.org> wrote
on Sat, 17 Sep 2011 00​:10​:19 PDT​:

+use open "​:std", "​:utf8";
+
+use IO​::Handle;
+
+@​ARGV = ('io_utf8argv') x 2;
+is *ARGV->getline, "Μία πάπια, μὰ ποιὰ πάπια;\n",
+ 'getline respects open pragma when magically opening ARGV';
+
+is join('',*ARGV->getlines), "Μία πάπια, μὰ ποιὰ πάπια;\n",
+ 'getlines respects open pragma when magically opening ARGV';
+
+END {
+ 1 while unlink "io_utf8argv";
+}

What's the deal with how/whether the open works on magic ARGV?

<ARGV> does an implicit open using the lexical hints at the point where
the <ARGV> occurs.

That means that ‘use open ...; while(<>)’ will set the layers on ARGV
based on that ‘use open’ directive.

Because IO​::Handle​::getline is a Perl subroutine, the <ARGV> is called
from there, outside the scope of the open pragma.

My patch fiddles PL_curcop to make getline’s caller’s hints visible to <>.

Is the answer version-dependent?

No. In fact, with the #ifndef show below, my patch works all the way
back to 5.6, which suggests it’s the right way to go.

And that ‘No’ applies, whether you are referring to the IO​::Handle bug,
the behaviour of <>, or my patch.

#ifndef dVAR
# define dVAR dNOOP
#endif

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 17, 2011

From @cpansprout

On Sat Sep 17 00​:10​:19 2011, sprout wrote​:

On Mon Sep 12 06​:02​:42 2011, sprout wrote​:

On Sun Sep 11 23​:25​:50 2011, hmbrand wrote​:

There are way more difficult bugs (open) with open pragma and
encoding.

Se e.g. https://rt.cpan.org/Ticket/Display.html?id=66474

Ouch! I would definitely consider that a bug. But I have *no* idea how
to fix it without introducing a page of inefficient hacks.

Attached is a page of efficient hacks. I still have to get it working
in 5.6 and 5.8. Is this type of hack acceptable? I think it’s robust
enough.

Now applied as 986a805.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 17, 2011

From [Unknown Contact. See original ticket]

On Sat Sep 17 00​:10​:19 2011, sprout wrote​:

On Mon Sep 12 06​:02​:42 2011, sprout wrote​:

On Sun Sep 11 23​:25​:50 2011, hmbrand wrote​:

There are way more difficult bugs (open) with open pragma and
encoding.

Se e.g. https://rt.cpan.org/Ticket/Display.html?id=66474

Ouch! I would definitely consider that a bug. But I have *no* idea how
to fix it without introducing a page of inefficient hacks.

Attached is a page of efficient hacks. I still have to get it working
in 5.6 and 5.8. Is this type of hack acceptable? I think it’s robust
enough.

Now applied as 986a805.

@p5pRT p5pRT added the type-library label Oct 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.