Re: BUG: strange behaviour with 'use open IN => ":byte"'

Quoth rgarciasuarezgmail.com ("Rafael
Garcia-Suarez"):
> On 17/09/2007, David Cantrell <davidcantrell.org.uk> wrote:
> > On Sat, Sep 15, 2007 at 02:44:27PM +0200,
macosx.perl.orgxmlizer.biz wrote:
> >
> > > [[
> > >     use open IN  =>
":encoding(UTF16-BE)";
> > >     use constant A => 1;
> > > ]]
> > >
> > > I get this error:
> > >   Unrecognized character xE0 at
> /System/Library/Perl/5.8.6/constant.pm line 1.
> >
> > I get similar with 5.8.7 and 5.9.5 on
NetBSD/Alpha, and 5.10.0 patch 31863
> > on Solaris/SPARC.  Congratulations, it looks like
you've found a bug in
> > perl!

No, not really. Things are working as documented. There is a
more
general problem here, which is that open.pm tries to apply
random PerlIO
layers to module files. In general this is not going to
work. Should
perhaps C<require MODULE> (as opposed to C<require
STRING>) be changed
to not honour the default open layers?  Does that introduce
back-compat
issues?  Otherwise the only even slightly safe way to use
open.pm is in
an INIT block.

Ben

On 17/09/2007, Ben Morrow <benmorrow.me.uk> wrote:
> No, not really. Things are working as documented. There
is a more
> general problem here, which is that open.pm tries to
apply random PerlIO
> layers to module files. In general this is not going to
work. Should
> perhaps C<require MODULE> (as opposed to
C<require STRING>) be changed
> to not honour the default open layers?  Does that
introduce back-compat
> issues?

I don't think so : I can't imagine someone relying on the
current
behaviour of open wrt perl modules. Well, actually I can,
but not
without some amount of perversion. Thus I consider this a
bug,
although a bit difficult to fix given the current IO
internals.

Your suggestion of using open in an INIT block doesn't
stand. open is
a compile-time pragma, affecting its enclosing lexical
block. I expect
that putting open in an INIT block gets rid of this effect.