From @Leont

This is a bug report for perl from fawaka@​gmail.com,
generated with the help of perlbug 1.39 running under perl 5.14.2.

Pushing :bytes does the exact opposide of pushing :utf8. That is, it
disables the UTF-8 flag. This is problematic because this is not a
sane thing to do for many layers, such as :encoding.
"<​:encoding(EUC-KO)​:bytes" has the surprising semantics of converting
the input to utf8 encoded bytestream. I don't think this behavior is
desired or useful. :bytes should pop off any layer that is not
intended for doing byte-IO.

Flags​:
  category=core
  severity=medium

Site configuration information for perl 5.14.2​:

Configured by Leon Timmermans at Fri Oct 14 13​:06​:29 CEST 2011.

Summary of my perl5 (revision 5 version 14 subversion 2) configuration​:

  Platform​:
  osname=linux, osvers=2.6.18-274.3.1.el5, archname=x86_64-linux-thread-multi
  uname='linux ciliate.bio.uu.nl 2.6.18-274.3.1.el5 #1 smp fri aug
26 18​:49​:02 edt 2011 x86_64 x86_64 x86_64 gnulinux '
  config_args='-de
-Dprefix=/home/leont/perl5/perlbrew/perls/perl-5.14.2 -Dusethreads
-Duselargefiles -Dcccdlflags=-fPIC -Dpager=/usr/bin/sensible-pager
-Doptimize=-O2 -Dcf_by=Leon Timmermans -Dcf_email=fawaka@​gmail.com'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=define, usemultiplicity=define
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=define, use64bitall=define, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing
-pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
  optimize='-O2',
  cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe
-fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.1.2 20080704 (Red Hat 4.1.2-50)',
gccosandvers=''
  intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64
  libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
  perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
  libc=/lib/libc-2.5.so, so=so, useshrplib=false, libperl=libperl.a
  gnulibc_version='2.5'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib
-fstack-protector'

Locally applied patches​:

@​INC for perl 5.14.2​:
  /home/leont/perl5/perlbrew/perls/perl-5.14.2/lib/site_perl/5.14.2/x86_64-linux-thread-multi
  /home/leont/perl5/perlbrew/perls/perl-5.14.2/lib/site_perl/5.14.2
  /home/leont/perl5/perlbrew/perls/perl-5.14.2/lib/5.14.2/x86_64-linux-thread-multi
  /home/leont/perl5/perlbrew/perls/perl-5.14.2/lib/5.14.2
  .

Environment for perl 5.14.2​:
  HOME=/home/leont
  LANG=en_US.UTF-8
  LANGUAGE (unset)
  LC_ALL=en_US.UTF-8
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/home/leont/perl5/perlbrew/bin​:/home/leont/perl5/perlbrew/perls/perl-5.14.2/bin​:/home/leont/bin​:/opt/bin​:/usr/local/bin​:/bin​:/usr/bin​:/usr/X11R6/bin
  PERLBREW_HOME=/home/leont/.perlbrew
  PERLBREW_PATH=/home/leont/perl5/perlbrew/bin​:/home/leont/perl5/perlbrew/perls/perl-5.14.2/bin
  PERLBREW_PERL=perl-5.14.2
  PERLBREW_ROOT=/home/leont/perl5/perlbrew
  PERLBREW_VERSION=0.28
  PERL_BADLANG (unset)
  SHELL=/bin/bash

From @xdg

On Mon, Mar 5, 2012 at 8​:27 AM, Leon Timmermans
<perlbug-followup@​perl.org> wrote​:

:bytes should pop off any layer that is not
intended for doing byte-IO.

I worry about that as an API. The "layers" metaphor is pretty much
wrecked when pushing layers pops off other layers. Yes, :raw already
does that, but I'd like to see us move to a more consistent API rather
than a more confusing one.

What you're describing sounds more like :raw anyway -- eliminating
layers that aren't suitable for binary data. How would your proposal
for :bytes be different?

Maybe :bytes just needs better documentation and some examples of why
someone would want to use it as implemented. Or, perhaps it should
just be deprecated. Or perhaps it should be an alias for :raw if
semantically they should be identical.

-- David

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

From @Leont

On Mon, Mar 5, 2012 at 5​:09 PM, David Golden <xdaveg@​gmail.com> wrote​:

I worry about that as an API.  The "layers" metaphor is pretty much
wrecked when pushing layers pops off other layers.  Yes, :raw already
does that, but I'd like to see us move to a more consistent API rather
than a more confusing one.

A fair point, but sadly it's the only way we have to manipulate IO layers.

What you're describing sounds more like :raw anyway -- eliminating
layers that aren't suitable for binary data.  How would your proposal
for :bytes be different?

The main difference would be that it wouldn't pop off a layer like :crlf.

Maybe :bytes just needs better documentation and some examples of why
someone would want to use it as implemented.

I don't see why anyone would want to current semantics. They just
don't make any sense to me​: it just doesn't take into account the
existence of a layer like :encoding at all.

Leon