Skip Menu |

This queue is for tickets about the Data-Dump CPAN distribution.

Report information
The Basics
Id: 60103
Status: resolved
Priority: 0/
Queue: Data-Dump

People
Owner: Nobody in particular
Requestors: FANY [...] cpan.org
Cc: 10130344 [...] ticket.noris.net
AdminCc:

Bug Information
Severity: Normal
Broken in:
  • 1.08
  • 1.17
Fixed in: (no value)



CC: 10130344 [...] ticket.noris.net
Subject: internal recoding of strings when MIME::Base64::encode() is used
While I love Data::Dump for saving me probably many hours of worktime since I use it, it just cost me some hours until I noticed that the use of pp() internally utf8::downgrade()s strings when MIME::Base64::encode() is used to dump the string, which in turn led to a database query using that string used it with a wrong encoding. (There's probably another bug in our database code which triggers that behaviour, but anyway I think that a module like Data::Dump used for debugging purposes should preferably not alter data in any way.) Please find a script to reproduce this issue attached. The output should be as follows: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $s before pp(): SV = PV(0x739090) at 0x7599c0 REFCNT = 1 FLAGS = (PADMY,POK,pPOK,UTF8) PV = 0x75f9b0 "\303\204\303\217\303\215\303\205\303\216 ROLANDBERGER.RU: \303\222\303\205\303\207\303\211\303\223\303\224\303\222\303\201\303\203\303\211\303\221 \303\220\303\222\303\217\303\204\303\214\303\205\303\216\303\201 \303\204\303\217 01-MAY-2004"\0 [UTF8 "\x{c4}\x{cf}\x{cd}\x{c5}\x{ce} ROLANDBERGER.RU: \x{d2}\x{c5}\x{c7}\x{c9}\x{d3}\x{d4}\x{d2}\x{c1}\x{c3}\x{c9}\x{d1} \x{d0}\x{d2}\x{cf}\x{c4}\x{cc}\x{c5}\x{ce}\x{c1} \x{c4}\x{cf} 01-MAY-2004"] CUR = 84 LEN = 85 pp($s): do { require MIME::Base64; MIME::Base64::decode("xM/Nxc4gUk9MQU5EQkVSR0VSLlJVOiDSxcfJ09TSwcPJ0SDQ0s/EzMXOwSDEzyAwMS1NQVktMjAwNA=="); } $s after pp(): SV = PVMG(0x7be9b0) at 0x7599c0 REFCNT = 1 FLAGS = (PADMY,SMG,POK,pPOK) IV = 0 NV = 0 PV = 0x75f9b0 "\304\317\315\305\316 ROLANDBERGER.RU: \322\305\307\311\323\324\322\301\303\311\321 \320\322\317\304\314\305\316\301 \304\317 01-MAY-2004"\0 CUR = 58 LEN = 85 MAGIC = 0x760b60 MG_VIRTUAL = &PL_vtbl_utf8 MG_TYPE = PERL_MAGIC_utf8(w) MG_LEN = 58 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This could IMHO be easily fixed by making a copy of the string before calling MIME::Base64::encode(); a minimal patch that introduces this changed is attached, too. I will also open a bug report for MIME::Base64 for this issue. Regards, fany
Subject: data-dump-base64
Download data-dump-base64
application/octet-stream 441b

Message body not shown because it is not plain text.

Subject: data-dump-base64.patch
--- /usr/local/lib/perl5/site_perl/5.12.1/Data/Dump.pm 2010-06-12 11:05:28.000000000 +0200 +++ Data/Dump.pm 2010-08-05 13:53:43.403968203 +0200 @@ -505,7 +505,7 @@ { $require{"MIME::Base64"}++; return "MIME::Base64::decode(\"" . - MIME::Base64::encode($_[0],"") . + MIME::Base64::encode( ( my $copy = $_[0] ), "" ) . "\")"; } return "pack(\"H*\",\"" . unpack("H*", $_[0]) . "\")";
The patch is fine; but I'll see if I can come up with something that avoids the copy. Also note that a workaround for you would be to set '$Data::Dump::TRY_BASE64 = 0' before you call any functions. This disabled the invocation of MIME::Base64::encode() on any string.
Resolved it with <http://github.com/gisle/data- dump/commit/758732bfe4d6829c441999b98ffa680428d7c72a>