Your message dated Wed, 16 Nov 2005 23:11:23 +0100
with message-id <[EMAIL PROTECTED]>
and subject line libogg0: not 64bit clean
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 25 Nov 2004 22:11:00 +0000
>From [EMAIL PROTECTED] Thu Nov 25 14:11:00 2004
Return-path: <[EMAIL PROTECTED]>
Received: from sardaukar.technologeek.org [213.41.134.11]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1CXRpL-00053x-00; Thu, 25 Nov 2004 14:11:00 -0800
Received: by sardaukar.technologeek.org (Postfix, from userid 1000)
id 6F5B137DB1; Thu, 25 Nov 2004 23:10:06 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============7325652775479110625=="
MIME-Version: 1.0
From: Julien BLACHE <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: libogg0: not 64bit clean
X-Mailer: reportbug 3.2
Date: Thu, 25 Nov 2004 23:10:06 +0100
Message-Id: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level:
This is a multi-part MIME message sent by reportbug.
--===============7325652775479110625==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Package: libogg0
Version: 1.1.0-1
Severity: important
Tags: patch
Hi,
libogg0 is not 64bit clean as it assumes sizeof(int) == sizeof(long); it is
especially problematic when dealing with bitwise operations, as does half of
libogg...
As it happens, it is not possible to read an OGG file containing a Theora
stream without this patch, as libtheora will (correctly) fail to recognize the
Theora stream.
The attached patch fixes the problem, by using an unsigned int instead of an
unsigned long. The two modified functions manipulate bits 0-31 as indicated in
the comments above the functions, so it's safe.
A first patch was sent over 2 years ago to the theora-dev list...
Please apply,
JB.
-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.9
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
Versions of packages libogg0 depends on:
ii libc6 2.3.2.ds1-18 GNU C Library: Shared libraries an
-- no debconf information
--===============7325652775479110625==
Content-Type: text/x-c; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="libogg_bitwise.c_64bit_fix.patch"
--- libogg-1.1.0.orig/src/bitwise.c
+++ libogg-1.1.0/src/bitwise.c
@@ -250,7 +250,7 @@
/* Read in bits without advancing the bitptr; bits <= 32 */
long oggpackB_look(oggpack_buffer *b,int bits){
- unsigned long ret;
+ unsigned int ret;
int m=32-bits;
bits+=b->endbit;
@@ -346,14 +346,14 @@
/* bits <= 32 */
long oggpackB_read(oggpack_buffer *b,int bits){
- unsigned long ret;
+ unsigned int ret;
long m=32-bits;
bits+=b->endbit;
if(b->endbyte+4>=b->storage){
/* not the main path */
- ret=-1UL;
+ ret=-1U;
if(b->endbyte*8+bits>b->storage*8)goto overflow;
}
--===============7325652775479110625==--
---------------------------------------
Received: (at 283007-done) by bugs.debian.org; 16 Nov 2005 22:11:25 +0000
>From [EMAIL PROTECTED] Wed Nov 16 14:11:25 2005
Return-path: <[EMAIL PROTECTED]>
Received: from 84-120-66-144.onocable.ono.com ([84.120.66.144]
helo=chistera.yi.org)
by spohr.debian.org with esmtp (Exim 4.50)
id 1EcVUy-0006MB-9x
for [EMAIL PROTECTED]; Wed, 16 Nov 2005 14:11:25 -0800
Received: from userid 1000 by chistera.yi.org with local (Exim 4.54)
id 1EcVUx-0005br-3i
for [EMAIL PROTECTED]; Wed, 16 Nov 2005 23:11:23 +0100
Date: Wed, 16 Nov 2005 23:11:23 +0100
From: Adeodato =?utf-8?B?U2ltw7M=?= <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: libogg0: not 64bit clean
Message-ID: <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED],
Adeodato =?utf-8?B?U2ltw7M=?= <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
X-No-CC: Please respect my Mail-Followup-To header
User-Agent: Mutt/1.5.11
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-3.0 required=4.0 tests=BAYES_00 autolearn=no
version=2.60-bugs.debian.org_2005_01_02
Version: 1.1.2-1
* Julien BLACHE [Thu, 25 Nov 2004 23:10:06 +0100]:
> Package: libogg0
> Version: 1.1.0-1
> Severity: important
> Tags: patch
> libogg0 is not 64bit clean as it assumes sizeof(int) == sizeof(long); it is
> especially problematic when dealing with bitwise operations, as does half of
> libogg...
* Ralph Giles [Wed, 29 Dec 2004 16:21:19 -0800]:
> This issue was fixed in the 1.1.1 upstream release. Our fix was more
> subtle than the attached patch, but resolves the issue correctly.
> A new package from of the latest (1.1.2) upstream release would resolve
> this bug along with a number of others.
Debian has 1.1.2 for a while now, closing.
--
Adeodato Simó
EM: dato (at) the-barrel.org | PK: DA6AE621
Listening to: The Magnetic Fields - I'm Sorry I Love You
One way to make your old car run better is to look up the price of a new model.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
