| Subject: | Question about wide character use in memGzip between version 2.004 and 2.005 |
Hello and thanks for Compress::Zlib.
I am upgrading from Compress::Zlib from 1.41 to 2.009 and as part
of the upgrade I ran 1.41's tests against 2.009, I noticed a
change in the behaviour of IO::Compress::memGzip and how it
treats wide characters.
Prior to 2.005 IO::Compress::memGzip did not have:
$] >= 5.008 and (utf8::downgrade($$string, 1)
or croak "Wide character in memGzip");
and the encoding test also had:
my $s = "\x{df}\x{100}";
my $cs = Compress::Zlib::memGzip($s);
I did read the Changes file for Compress::Zlib but this change was
not mentioned, I also read the docs and the FAQ.
I did find in the Changes file for IO::Compress::Zlib
2.005 18 June 2007
* IO::Compress::Gzip & IO::Uncompress::Gunzip
- RFC1952 says that the FNAME & FCOMMENT header fields must be ISO
8859-1 (LATIN-1) characters. The code can optionally police this.
Added a fix for this logic when running on EBCDIC.
This explains why the wide char check was added to memGunzip
(I think). Just wondering if you could shed some light on the change
to memGzip?
Many thanks,
Peter (Stig) Edwards