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
>
> > Since the architectures where testsuite fails have little in common,
> > it could be that this bug is a bug in the testsuite rather than
> > testsuite exposing bugs in libaudio-flac-header-perl code.
>
> No, it seems to be a "real" bug. I could reproduce this on hppa
> (paer.d.o), and the failing test is due to differing cuesheet information:
> hppa gives
>
> REM FLAC__lead-in 1604068
> REM FLAC__lead-out 170 153200460
>
> where it's supposed to be
>
> REM FLAC__lead-in 88200
> REM FLAC__lead-out 170 153200460
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);
I can't really say I understand what's happening. The UVuf macro is
defined as "lu" (in /usr/lib/perl/5.8/CORE/config.h), and
fprintf(stderr, "%lu\n", cs->lead_in)
gives 88200 as expected.
This is starting to look like a Perl bug in Perl_newSVpvf()...
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
