Bug#462249: libaudio-flac-header-perl: FTBFS on armel, hppa, m68k, powerpc, s390, sparc

[Niko Tyni]

forwarded 462249 http://rt.cpan.org/Public/Bug/Display.html?id=32630
thanks

On Wed, Jan 23, 2008 at 11:33:21PM +0200, Niko Tyni wrote:
> On Wed, Jan 23, 2008 at 06:17:15PM +0200, Niko Tyni wrote:
> > On Wed, Jan 23, 2008 at 03:07:48PM +0200, Riku Voipio wrote:
> > > Package: libaudio-flac-header-perl
> > > Version: 1.9-1
> > > Severity: serious
> > > Justification: no longer builds from source

> OK, I'm as far as seeing that this code (in Header.xs:250 or so)
> 
>  newSVpvf("REM FLAC__lead-in %"UVuf"\n", cs->lead_in);
> 
> where cs->lead_in is a FLAC__uint64 and contains 88200, gives the Perl
> string "REM FLAC__lead-in 1604068" on hppa. An explicit cast fixes it:
> 
>  newSVpvf("REM FLAC__lead-in %"UVuf"\n", (unsigned int) cs->lead_in);

Upstream bug filed as CPAN #32630. This is what I wrote there:

 The problem seems to be the newSVpvf() calls around Header.xs:250 - they
 are using the "UVuf" format, which expands at least here to "lu"
 (/usr/lib/perl/5.8/CORE/Config.h), while passing in a FLAC__int64 value.
 This means that the newSVpvf() stdarg function is expecting an "unsigned
 long" (32 bits) and getting an "unsigned long long" (64 bits).

 I don't claim to understand exactly what happens here; I suppose the
 behaviour is undefined, and apparently the caller and the callee are
 disagreeing about the register where the value should be stored. The
 wrong value (1604068 above) varies a bit, and seems to be whatever
 happens to be in r25 just before the function call.

 One fix is to explicitly cast the value to "unsigned long" in the
 newSVpvf() calls, but I guess this would lose information on >4G (32
 bits) FLAC files. A better solution might be to do the decimal
 conversion on the C side with sprintf() and the "%llu" format before
 calling newSV*().

Waiting a while for upstream to respond before trying to patch this.
-- 
Niko Tyni   ntyni at debian.org