| Subject: | FLAC application blocks containing binary data not extracted correctly |
I happen to use a FLAC application block to store binary data (specifically, a cover art image as jpeg or png) and found that the XS version of Audio::FLAC::Header doesn't extract the data block correctly. In _read_metadata on line 181 of Header.xs, it reads the application data block by calling newSVpv() with a length argument of 0, which tells Perl to guess the length using strlen(). Of course this truncates my binary application blocks at the first 0x00.
I have attached a trivial patch that uses block->length as the length argument instead of 0, which appears to solve the problem in my application. It doesn't seem that this would have any undesired side effects for application blocks containing null-terminated strings, but somebody who knows what they are doing will want to check that.
(I don't believe it matters, but I am using Perl 5.8.7 from Debian unstable , built for x86_64-linux-thread-multi. I used the Audio-FLAC-Header-1.4.tar.gz source distribution from CPAN.)
--- Header.xs.orig 2005-10-31 01:18:52.000000000 -0800
+++ Header.xs 2005-10-31 00:36:33.000000000 -0800
@@ -133,7 +133,7 @@
appId = newSVpvf("%ld", strtol(SvPV_nolen(tmpId), NULL, 16));
if (block->data.application.data != 0) {
- my_hv_store(app, SvPV_nolen(appId), newSVpv(block->data.application.data, 0));
+ my_hv_store(app, SvPV_nolen(appId), newSVpv(block->data.application.data, block->length));
}
my_hv_store(self, "application", newRV_noinc((SV*) app));