develooper Front page | perl.perl5.porters | Postings from April 2016

[perl #125723] IO::File fails on win32 (Strawberry Perl) 5.16 andlower due to ord?

From:
Leon Timmermans via RT
Date:
April 8, 2016 16:36
Subject:
[perl #125723] IO::File fails on win32 (Strawberry Perl) 5.16 andlower due to ord?
Message ID:
rt-4.0.18-27749-1460133390-0.125723-15-0@perl.org
On Wed Jul 29 22:59:45 2015, TODDR wrote:
> http://matrix.cpantesters.org/?dist=IO+1.35_01
> 
> I'm doing a review of the IO in blead to see if we can publish the
> dual life module to CPAN. I'm finding that Strawberry Perl below 5.18
> are failing on t/io_utf8.t
> 
> I've simplified the program as much as possible:
> 
> #!./perl
> 
> use IO::File;
> 
> unlink "io_utf8";
> 
> my $io = IO::File->new;
> $io->open("io_utf8", ">:utf8");
> print $io chr(256);
> undef $io;
> 
> $io = IO::File->new;
> $io->open("io_utf8", "<:utf8");
> ord(<$io>);
> 
> my $i = 5;
> my $got = $io->ungetc($i);
> print "want $i; got $got\n";
> 
> The output looks like this:
> 
> C:\strawberry\cpan\build\IO-1.35_01-yI3WZZ>perl t/io_utf8.t
> want 5; got -1
> 
> If I take out the ord line, the program passes. Switching the ord to a
> $io->getc doesn't behave the same, so I'm guessing this isn't an EOF
> issue and something more magical going on with IO::File?

Before 5.18 (or actually ec1da995), unread (the primitive used by ungetc) was quite unreliable on :crlf. This was a bug in core, not in IO. Though I suppose IO could work around such a failure by pushing a ":pending" layer on top and redoing the ungetc.

Leon

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=125723



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About