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 [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
