Re: GCC 4.1 now the default GCC version for etch
On Sat, Jun 17, 2006 at 09:47:10AM +0200, Falk Hueffner wrote: > On Fri, Jun 16, 2006 at 07:06:06PM -0500, Ron Johnson wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Falk Hueffner wrote: > > > On Thu, Jun 08, 2006 at 07:58:23AM +0200, Bastian Blank wrote: > > >> long is not appropriate to save pointers, you need to use intptr_t or > > >> uintptr_t. > > > > > > C90 basically promised it would work, and it is widely considered a > > > bug in C99 that there is no such guarantee. sizeof(void*) == > > > sizeof(long) is also assumed all over the place in Linux, and there is > > > > "Linux == kernel" or "Linux == distro"? > > Both. No. Linux == kernel GNU/Linux == what distros are generally based on. -- Brett Parker -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On Mon, Jun 19, 2006 at 03:49:01PM +0200, Bastian Blank wrote: > On Mon, Jun 19, 2006 at 02:59:37PM +0200, Henning Makholm wrote: > > The fix should be somehow unclumsified, though. Currently I inject > > some horrible runtime testing in the configure script to find out > > whether the clib supports the %zu format of C99, but that breaks > > crosscompilability (which I'm not sure worked before, but still...) > > What is the problem with just assuming that %zu works? C99 is not 7 > years old and this is one of the easier things. Not all of us have the luxury of assuming C99 systems. One major project recently bumped its minimum toolchain requirements from K&R to C89, and is quite a ways from being able to assume C99 features yet. signature.asc Description: Digital signature
Re: GCC 4.1 now the default GCC version for etch
On 6/19/06, Bastian Blank <[EMAIL PROTECTED]> wrote: > Would it be safe to assume that a size_t can always be cast losslessly > to an unsigned long (and then printed with %lu), or are there systems > on which only an unsigned long long will do? unsigned long is not sufficient. OTOH, you could weigh up the chance that the number you're going to output is greater than 2^32. If the chance is small, you cast it to long and print using %lu. No chance of compiler errors, the display will just look odd if you do try to print a larger number. -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On Mon, Jun 19, 2006 at 02:59:37PM +0200, Henning Makholm wrote: > The fix should be somehow unclumsified, though. Currently I inject > some horrible runtime testing in the configure script to find out > whether the clib supports the %zu format of C99, but that breaks > crosscompilability (which I'm not sure worked before, but still...) What is the problem with just assuming that %zu works? C99 is not 7 years old and this is one of the easier things. > Would it be safe to assume that a size_t can always be cast losslessly > to an unsigned long (and then printed with %lu), or are there systems > on which only an unsigned long long will do? unsigned long is not sufficient. Bastian -- Captain's Log, star date 21:34.5... signature.asc Description: Digital signature
Re: GCC 4.1 now the default GCC version for etch
Scripsit Goswin von Brederlow <[EMAIL PROTECTED]> > Henning Makholm <[EMAIL PROTECTED]> writes: >> Scripsit Falk Hueffner <[EMAIL PROTECTED]> >>> Henning Makholm wrote: Another related bug type that I found lurking in my packages when I investigated the warnings in this list, is trying to format a size_t value with a %u or %d format string, >>> Since any sane ABI pads arguments to word size, this is only a problem >>> on big endian 64-bit architectures (that is, no current release >>> architecture). >> Hm, that makes sense. Perhaps I should back out my (clumsy) fixes for >> it, then. > No, the bug remains and should be fixed. The fix should be somehow unclumsified, though. Currently I inject some horrible runtime testing in the configure script to find out whether the clib supports the %zu format of C99, but that breaks crosscompilability (which I'm not sure worked before, but still...) Would it be safe to assume that a size_t can always be cast losslessly to an unsigned long (and then printed with %lu), or are there systems on which only an unsigned long long will do? -- Henning Makholm "Jeg forstår mig på at anvende sådanne midler på folks legemer, at jeg kan varme eller afkøle dem, som jeg vil, og få dem til at kaste op, hvis det er det, jeg vil, eller give afføring og meget andet af den slags." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Blars Blarson schrieb am Sonntag, 18. Juni 2006 um 14:24:35 -0700: > In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: > > >there appears to currently be a sparc release of debian, > >http://www.debian.org/ports/sparc/ > > (not currently a release candidate for etch) > According to http://release.debian.org/etch_arch_qualify.html it is a release candidate, but I think this might be wrong. -- Jörg Friedrich There are only 10 types of people: Those who understand binary and those who don't. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On Sun, Jun 18, 2006 at 02:24:35PM -0700, Blars Blarson wrote: > (amd64 is only faster in 64-bit mode because of all the poorly > designed x86 32-bit instruction set.) "x86 32-bit instruction set" and "designed" in one sentence? Hah. -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: >there appears to currently be a sparc release of debian, >http://www.debian.org/ports/sparc/ (not currently a release candidate for etch) >and it appears to claim to support some kind of limited 64bit support. >There are some unstated things from the page that I would like to bring to >the table as relevant: > >1. since it is sparc, I would presume debian/sparc is "big endian" Yes. >2. since the amd64 arch now has 64bit applications (?) I would guess that > at some point, the debian sparc folks may follow suit. It does support 64-bit applications. However, in almost all cases compiling for 64-bit just makes the application slower. Don't expect all 64-bit mode support for sparc. (amd64 is only faster in 64-bit mode because of all the poorly designed x86 32-bit instruction set.) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Henning Makholm <[EMAIL PROTECTED]> writes: > Scripsit Falk Hueffner <[EMAIL PROTECTED]> >> Henning Makholm wrote: > >>> Another related bug type that I found lurking in my packages when I >>> investigated the warnings in this list, is trying to format a size_t >>> value with a %u or %d format string, which will break if size_t is 64 >>> bits (unless the actual number is small and it is the last argument >>> and the endianness of the architecture happens to match its stack >>> growth direction). > >> Since any sane ABI pads arguments to word size, this is only a problem >> on big endian 64-bit architectures (that is, no current release >> architecture). > > Hm, that makes sense. Perhaps I should back out my (clumsy) fixes for > it, then. No, the bug remains and should be fixed. It just doesn't cause crashes or even show any signs at all as long as there is no overflow. For examle %d for size_t will work only up to 2GiB and then display the wrong values. If all you use are number 0-100 then you will not hit the bug on any debian archtecture. The next port could be a 64bit big endian system though. It really is better to fix it now instead of worrying about it again in the future. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Scripsit Falk Hueffner <[EMAIL PROTECTED]> > Henning Makholm wrote: >> Another related bug type that I found lurking in my packages when I >> investigated the warnings in this list, is trying to format a size_t >> value with a %u or %d format string, which will break if size_t is 64 >> bits (unless the actual number is small and it is the last argument >> and the endianness of the architecture happens to match its stack >> growth direction). > Since any sane ABI pads arguments to word size, this is only a problem > on big endian 64-bit architectures (that is, no current release > architecture). Hm, that makes sense. Perhaps I should back out my (clumsy) fixes for it, then. -- Henning Makholm"*Jeg* tænker *strax* på kirkemødet i Konstantinopel i 381 e.Chr. om det arianske kætteri..." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On Sun, Jun 18, 2006 at 07:40:13AM +0200, Tollef Fog Heen wrote: > Philip Brown skrev: > >So to deliberately ignore an issue, becuase > >"we dont support big-endian 64bit *right now*", would seem to be rather > >short sighted to me. > ia64 has been supported for quite a while and is a pure 64 bit architecture. But not big-endian. Bastian -- Dismissed. That's a Star Fleet expression for, "Get out." -- Capt. Kathryn Janeway, Star Trek: Voyager, "The Cloud" signature.asc Description: Digital signature
Re: GCC 4.1 now the default GCC version for etch
Philip Brown skrev: So to deliberately ignore an issue, becuase "we dont support big-endian 64bit *right now*", would seem to be rather short sighted to me. ia64 has been supported for quite a while and is a pure 64 bit architecture. - tfheen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On Sat, Jun 17, 2006 at 03:40:10PM +0200, Goswin von Brederlow wrote: > I'm not sure how fused they are but last I heard someone was working > on a Debian port with range checking with some success. That sounds really interesting -- having a chroot with bounds-checking gcc (and libraries supporting it) would be really neat as a debugging tool. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Falk Hueffner <[EMAIL PROTECTED]> writes: >> On Sat, Jun 17, 2006 at 02:17:23AM +0200, Goswin von Brederlow wrote: >>> Falk Hueffner <[EMAIL PROTECTED]> writes: >>> > So in summary, if you don't care about portability to 64-bit windows, >>> > assuming sizeof(void*) == sizeof(long) is just fine. >>> >>> Unless you compile with range checking pointers. >> >> The current implementation of range checking in gcc (mudflap) uses >> normal-sized pointers. > > Even in 32bit? How do they cram all that info in there? By using an object database lookup. See http://gcc.fyxm.net/summit/2003/mudflap.pdf -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Falk Hueffner <[EMAIL PROTECTED]> writes: > On Sat, Jun 17, 2006 at 02:17:23AM +0200, Goswin von Brederlow wrote: >> Falk Hueffner <[EMAIL PROTECTED]> writes: >> > So in summary, if you don't care about portability to 64-bit windows, >> > assuming sizeof(void*) == sizeof(long) is just fine. >> >> Unless you compile with range checking pointers. > > The current implementation of range checking in gcc (mudflap) uses > normal-sized pointers. > > -- > Falk Even in 32bit? How do they cram all that info in there? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes: > On Sat, Jun 17, 2006 at 02:17:23AM +0200, Goswin von Brederlow wrote: >>> So in summary, if you don't care about portability to 64-bit windows, >>> assuming sizeof(void*) == sizeof(long) is just fine. >> Unless you compile with range checking pointers. > > Are these patches fused into gcc nowadays, or do they still exist as separate > patch sets? > > /* Steinar */ I'm not sure how fused they are but last I heard someone was working on a Debian port with range checking with some success. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Ron Johnson <[EMAIL PROTECTED]> writes: > Goswin von Brederlow wrote: >> Falk Hueffner <[EMAIL PROTECTED]> writes: >> >>> On Thu, Jun 08, 2006 at 07:58:23AM +0200, Bastian Blank wrote: On Wed, Jun 07, 2006 at 11:53:24PM +0100, Darren Salt wrote: > [snip] >>> So in summary, if you don't care about portability to 64-bit windows, >>> assuming sizeof(void*) == sizeof(long) is just fine. >> >> Unless you compile with range checking pointers. > > Has Pascal risen from the grave? No, that's range checking arrays. > Never mind. > > Of course, we could always use COBOL and never have to worry about > such issues... In C a pointer is only valid in the range allocated plus one and may only be dereferenced within the range allocated. Anything else is implementation defined. gcc is totaly within its rights to abort any such case, esspecialy if you think about what harm buffer overflows can mean. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On Sat, Jun 17, 2006 at 02:17:23AM +0200, Goswin von Brederlow wrote: >> So in summary, if you don't care about portability to 64-bit windows, >> assuming sizeof(void*) == sizeof(long) is just fine. > Unless you compile with range checking pointers. Are these patches fused into gcc nowadays, or do they still exist as separate patch sets? /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On Sat, Jun 17, 2006 at 02:17:23AM +0200, Goswin von Brederlow wrote: > Falk Hueffner <[EMAIL PROTECTED]> writes: > > So in summary, if you don't care about portability to 64-bit windows, > > assuming sizeof(void*) == sizeof(long) is just fine. > > Unless you compile with range checking pointers. The current implementation of range checking in gcc (mudflap) uses normal-sized pointers. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On Fri, Jun 16, 2006 at 07:06:06PM -0500, Ron Johnson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Falk Hueffner wrote: > > On Thu, Jun 08, 2006 at 07:58:23AM +0200, Bastian Blank wrote: > >> long is not appropriate to save pointers, you need to use intptr_t or > >> uintptr_t. > > > > C90 basically promised it would work, and it is widely considered a > > bug in C99 that there is no such guarantee. sizeof(void*) == > > sizeof(long) is also assumed all over the place in Linux, and there is > > "Linux == kernel" or "Linux == distro"? Both. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On Fri, Jun 16, 2006 at 02:39:26PM -0700, Philip Brown wrote: > On Fri, Jun 16, 2006 at 11:15:32PM +0200, Falk Hueffner wrote: > > Henning Makholm wrote: > > > > > Another related bug type that I found lurking in my packages when I > > > investigated the warnings in this list, is trying to format a size_t > > > value with a %u or %d format string > > > > Since any sane ABI pads arguments to word size, this is only a problem > > on big endian 64-bit architectures (that is, no current release > > architecture). > > So to deliberately ignore an issue, becuase > "we dont support big-endian 64bit *right now*", would seem to be rather > short sighted to me. I didn't suggest to ignore the issue. I'm just providing information to help people to prioritize. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Darren Salt wrote: > I demand that Goswin von Brederlow may or may not have written... > > > [snip] >> But other sources pass a pointer as int and there you loose 32 >> valuable bits and get a segfault when the int is used as >> pointer again. [...] > > And here's me thinking that you lose them. :-) You loose them to roam the ether. Think of them as free-range bits. - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEk1OXS9HxQb37XmcRAmbJAJ4oLV8AudxQDxxkUmF5Lx8Vr4o48QCcClvZ wU992EYchlBIrmGec6c/u3Y= =/cEw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
I demand that Goswin von Brederlow may or may not have written... [snip] > But other sources pass a pointer as int and there you loose 32 valuable > bits and get a segfault when the int is used as pointer again. [...] And here's me thinking that you lose them. :-) -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Buy local produce. Try to walk or cycle. TRANSPORT CAUSES GLOBAL WARMING. It seems to make a car driver mad if he misses you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Goswin von Brederlow wrote: > Falk Hueffner <[EMAIL PROTECTED]> writes: > >> On Thu, Jun 08, 2006 at 07:58:23AM +0200, Bastian Blank wrote: >>> On Wed, Jun 07, 2006 at 11:53:24PM +0100, Darren Salt wrote: [snip] >> So in summary, if you don't care about portability to 64-bit windows, >> assuming sizeof(void*) == sizeof(long) is just fine. > > Unless you compile with range checking pointers. Has Pascal risen from the grave? No, that's range checking arrays. Never mind. Of course, we could always use COBOL and never have to worry about such issues... - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEk085S9HxQb37XmcRAkWlAKCfKXy0p7+2zCkaKCzqbeb42barIwCfZcX8 svcwsJbULFgnJ3zMhQCnSCQ= =hbXV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Falk Hueffner <[EMAIL PROTECTED]> writes: > On Thu, Jun 08, 2006 at 07:58:23AM +0200, Bastian Blank wrote: >> On Wed, Jun 07, 2006 at 11:53:24PM +0100, Darren Salt wrote: >> > The others are trivially fixable; of these, the one in libavcodec is >> > already >> > fixed in CVS. I've committed the rest (they're basically s/int/long/) and >> > am >> > forwarding them appropriately. >> >> long is not appropriate to save pointers, you need to use intptr_t or >> uintptr_t. > > C90 basically promised it would work, and it is widely considered a > bug in C99 that there is no such guarantee. sizeof(void*) == > sizeof(long) is also assumed all over the place in Linux, and there is > not a chance in hell that will ever change. The only relevant system > that does not have sizeof(void*) == sizeof(long) is 64-bit windows. > > So in summary, if you don't care about portability to 64-bit windows, > assuming sizeof(void*) == sizeof(long) is just fine. Unless you compile with range checking pointers. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Falk Hueffner wrote: > On Thu, Jun 08, 2006 at 07:58:23AM +0200, Bastian Blank wrote: >> On Wed, Jun 07, 2006 at 11:53:24PM +0100, Darren Salt wrote: >>> The others are trivially fixable; of these, the one in libavcodec is already >>> fixed in CVS. I've committed the rest (they're basically s/int/long/) and am >>> forwarding them appropriately. >> long is not appropriate to save pointers, you need to use intptr_t or >> uintptr_t. > > C90 basically promised it would work, and it is widely considered a > bug in C99 that there is no such guarantee. sizeof(void*) == > sizeof(long) is also assumed all over the place in Linux, and there is "Linux == kernel" or "Linux == distro"? > not a chance in hell that will ever change. The only relevant system > that does not have sizeof(void*) == sizeof(long) is 64-bit windows. > > So in summary, if you don't care about portability to 64-bit windows, > assuming sizeof(void*) == sizeof(long) is just fine. > - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEk0duS9HxQb37XmcRArB5AJ9JoHqZYhbzp9FrlDXfnfMMXudjSwCfR9gU 2xTOchvxvlHJ+9R0zsulklA= =aJHY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On Fri, Jun 16, 2006 at 11:15:32PM +0200, Falk Hueffner wrote: > Henning Makholm wrote: > > > Another related bug type that I found lurking in my packages when I > > investigated the warnings in this list, is trying to format a size_t > > value with a %u or %d format string, which will break if size_t is 64 > > bits (unless the actual number is small and it is the last argument > > and the endianness of the architecture happens to match its stack > > growth direction). > > Since any sane ABI pads arguments to word size, this is only a problem > on big endian 64-bit architectures (that is, no current release > architecture). > odd.. there appears to currently be a sparc release of debian, http://www.debian.org/ports/sparc/ and it appears to claim to support some kind of limited 64bit support. There are some unstated things from the page that I would like to bring to the table as relevant: 1. since it is sparc, I would presume debian/sparc is "big endian" 2. since the amd64 arch now has 64bit applications (?) I would guess that at some point, the debian sparc folks may follow suit. So to deliberately ignore an issue, becuase "we dont support big-endian 64bit *right now*", would seem to be rather short sighted to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On 16-Jun-06, 08:18 (CDT), Henning Makholm <[EMAIL PROTECTED]> wrote:
> Another related bug type that I found lurking in my packages when I
> investigated the warnings in this list, is trying to format a size_t
> value with a %u or %d format string, which will break if size_t is 64
> bits (unless the actual number is small and it is the last argument
> and the endianness of the architecture happens to match its stack
> growth direction). This too produces a warning on all relevant gcc
> versions, but only when compiling to a 64-bit target.
Actually, it will provide a warning on 32-bit platforms too, if one chooses the
appropriate options (-Wall, or specifically -Wformat):
$ cat tprint.c
#include
int main(void) {
int i;
size_t st;
printf("%d %lu\n", i, st);
return 0;
}
$ gcc -Wall tprint.c
tprint.c: In function 'main':
tprint.c:8: warning: format '%lu' expects type 'long unsigned int', but
argument 3 has type 'size_t'
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Henning Makholm wrote: > Another related bug type that I found lurking in my packages when I > investigated the warnings in this list, is trying to format a size_t > value with a %u or %d format string, which will break if size_t is 64 > bits (unless the actual number is small and it is the last argument > and the endianness of the architecture happens to match its stack > growth direction). Since any sane ABI pads arguments to word size, this is only a problem on big endian 64-bit architectures (that is, no current release architecture). -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On Thu, Jun 08, 2006 at 07:58:23AM +0200, Bastian Blank wrote: > On Wed, Jun 07, 2006 at 11:53:24PM +0100, Darren Salt wrote: > > The others are trivially fixable; of these, the one in libavcodec is already > > fixed in CVS. I've committed the rest (they're basically s/int/long/) and am > > forwarding them appropriately. > > long is not appropriate to save pointers, you need to use intptr_t or > uintptr_t. C90 basically promised it would work, and it is widely considered a bug in C99 that there is no such guarantee. sizeof(void*) == sizeof(long) is also assumed all over the place in Linux, and there is not a chance in hell that will ever change. The only relevant system that does not have sizeof(void*) == sizeof(long) is 64-bit windows. So in summary, if you don't care about portability to 64-bit windows, assuming sizeof(void*) == sizeof(long) is just fine. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Henning Makholm <[EMAIL PROTECTED]> wrote: > Scripsit Andreas Metzler <[EMAIL PROTECTED]> >> On 2006-06-07 Matthias Klose <[EMAIL PROTECTED]> wrote: >>> We did pick two compiler warnings and scanned the build logs of one >>> archive rebuild on alpha (64bit), where wrong code may be generated. >>> - cast from pointer to integer of different size >>>cast to pointer from integer of different size >> i.e. if a package is currently in the archive, suffers from this >> issues and the binary packages *currently* in the archive have been >> built with gcc-4.0, should I >> b) simply continue, as the package won't be broken more with gcc-4.1 >> than it was with gcc-4.0? > If the code is really nont 64bit-clean (i.e. it tries to store a > pointer in a 32-bit integer and expects to be able to cast it back and > still locate the data the original pointer pointed to), I cannot see > how gcc-4.0 would have been able to create working code either. I have since talked to upstream, and it seems to be more of a cosmetic issue, they are storing 32bit integers in pointers. Following glib's example and depending on the size of void on an arch either casting p = (void*) (long) 42; or p = (void*) 42; will get rid of the warnings, too. Thanks for your explanations (also to Goswin), cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Andreas Metzler <[EMAIL PROTECTED]> writes: > On 2006-06-07 Matthias Klose <[EMAIL PROTECTED]> wrote: > [...] >> We did pick two compiler warnings and scanned the build logs of one >> archive rebuild on alpha (64bit), where wrong code may be generated. > [...] >> - cast from pointer to integer of different size >>cast to pointer from integer of different size > >>These warnings may point to code which is not 64bit clean. They are >>most likely not seen on 32bit architectures. See the amd64, alpha >>and ia64 build logs for these architecture specific warnings. > [...] > > Hello, > as this was sent in conjunction with gcc 4.1, I wonder whether gcc 4.1 > is more strict in this matter, too. This has always been a bug and great cause for segfaults. They just have automated looking for the compiler warnings for the problem now instead of users looking at segfaults. > i.e. if a package is currently in the archive, suffers from this > issues and the binary packages *currently* in the archive have been > built with gcc-4.0, should I > > a) refrain from making a upload before the > issue is fixed as the packages will break horribly with gcc-4.1, > > or > b) simply continue, as the package won't be broken more with gcc-4.1 > than it was with gcc-4.0? > > thanks, cu andreas The brokenness does not change, the generated code does not change. The bug remains if it actualy is a bug. Sometimes you have code that pases an int (and other things at different places) along as void* and deeper down casts it back to int. This will generate the warning, is bad C (implementation defined behaviour), but with gcc it will work perfectly. The extra 32 high-bits you gain you loose again. No harm done _in_this_case. But other sources pass a pointer as int and there you loose 32 valuable bits and get a segfault when the int is used as pointer again. The warnings ware the same. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Scripsit Andreas Metzler <[EMAIL PROTECTED]> > On 2006-06-07 Matthias Klose <[EMAIL PROTECTED]> wrote: >> We did pick two compiler warnings and scanned the build logs of one >> archive rebuild on alpha (64bit), where wrong code may be generated. >> - cast from pointer to integer of different size >>cast to pointer from integer of different size > i.e. if a package is currently in the archive, suffers from this > issues and the binary packages *currently* in the archive have been > built with gcc-4.0, should I > b) simply continue, as the package won't be broken more with gcc-4.1 > than it was with gcc-4.0? If the code is really nont 64bit-clean (i.e. it tries to store a pointer in a 32-bit integer and expects to be able to cast it back and still locate the data the original pointer pointed to), I cannot see how gcc-4.0 would have been able to create working code either. As I read Matthias' posting, these warnings were ones that were found as a kind of bonus outcome from the compile-everything-with-gcc4.1 experiment. Another related bug type that I found lurking in my packages when I investigated the warnings in this list, is trying to format a size_t value with a %u or %d format string, which will break if size_t is 64 bits (unless the actual number is small and it is the last argument and the endianness of the architecture happens to match its stack growth direction). This too produces a warning on all relevant gcc versions, but only when compiling to a 64-bit target. Somebody ought to create a tool that could easily compare the buildd logs for a package on different architectures and flag warnings that appear only for some but not arches, indicating a possible portability bug. -- Henning Makholm"What the hedgehog sang is not evidence." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On 2006-06-07 Matthias Klose <[EMAIL PROTECTED]> wrote: [...] > We did pick two compiler warnings and scanned the build logs of one > archive rebuild on alpha (64bit), where wrong code may be generated. [...] > - cast from pointer to integer of different size >cast to pointer from integer of different size >These warnings may point to code which is not 64bit clean. They are >most likely not seen on 32bit architectures. See the amd64, alpha >and ia64 build logs for these architecture specific warnings. [...] Hello, as this was sent in conjunction with gcc 4.1, I wonder whether gcc 4.1 is more strict in this matter, too. i.e. if a package is currently in the archive, suffers from this issues and the binary packages *currently* in the archive have been built with gcc-4.0, should I a) refrain from making a upload before the issue is fixed as the packages will break horribly with gcc-4.1, or b) simply continue, as the package won't be broken more with gcc-4.1 than it was with gcc-4.0? thanks, cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
* Mike Hommey <[EMAIL PROTECTED]> [2006-06-08 07:46]: > > Mike Hommey > > xulrunner 1.8.0.1-11 > > What I quite don't get is why xulrunner gets warnings while firefox > and thunderbird don't... I compiled with both gcc 4.1 and 4.2. GCC 4.2 cannot compile thunderbird because of a compiler bug, and the box with the logs from 4.1 is currently down. I'll email you private when it's up again. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
* Mike Hommey <[EMAIL PROTECTED]> [2006-06-09 16:21]: > Moreover, I don't understand how you managed to build xulrunner with gcc > 4.1. I just tried and got loads of > error: no suitable 'operator delete' for 'whateverClass' > on delete operators defined as operator delete(void *, size_t). >From what I understand, this problem only appeared only recently, and might be related to the patch we reverted to fix another but. Anyway, I think a fix for this is coming soon. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Martin Michlmayr <[EMAIL PROTECTED]> wrote: > * Matthias Klose <[EMAIL PROTECTED]> [2006-06-07 02:20]: >> We did pick two compiler warnings and scanned the build logs of one >> archive rebuild on alpha (64bit), where wrong code may be generated. >> These warnings can be found in 1600 packages [4]; they are: >> [4] http://people.debian.org/~tbm/logs/pointer/ > Here is a list of maintainers and their packages which exhibit such > warnings: [...] > Andreas Metzler > gnutls12 1.2.9-2.1 Seems to still apply to 1.2.11. - However I'll let this version propagate to testing first (it was still built with gcc-4.0). > newsx 1.6-2 Hummpf. Still not adopted. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On Thu, Jun 08, 2006 at 07:46:06AM +0200, Mike Hommey <[EMAIL PROTECTED]> wrote: > On Wed, Jun 07, 2006 at 10:28:29AM +0200, Martin Michlmayr <[EMAIL > PROTECTED]> wrote: > > * Matthias Klose <[EMAIL PROTECTED]> [2006-06-07 02:20]: > > > We did pick two compiler warnings and scanned the build logs of one > > > archive rebuild on alpha (64bit), where wrong code may be generated. > > > These warnings can be found in 1600 packages [4]; they are: > > > [4] http://people.debian.org/~tbm/logs/pointer/ > > > > Here is a list of maintainers and their packages which exhibit such > > warnings: > > > > Mike Hommey > > xulrunner 1.8.0.1-11 > > What I quite don't get is why xulrunner gets warnings while firefox and > thunderbird don't... Moreover, I don't understand how you managed to build xulrunner with gcc 4.1. I just tried and got loads of error: no suitable 'operator delete' for 'whateverClass' on delete operators defined as operator delete(void *, size_t). Which will obviously fail on firefox and thunderbird as well... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Martin Michlmayr wrote: Simon Kelley dnsmasq 2.31-1 Looks pretty trivial, it will fixed in the next upstream/upload. Cheers, Simon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Hi, quite some of the "dereferencing type-punned pointer" problems are really problems in the wxwindows 2.6 library. Greetings, Joost Damad -- The planet Andete is famous for it's killer edible poets. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Selon Martin Michlmayr <[EMAIL PROTECTED]>: > * Matthias Klose <[EMAIL PROTECTED]> [2006-06-07 02:20]: > > We did pick two compiler warnings and scanned the build logs of one > > archive rebuild on alpha (64bit), where wrong code may be generated. > > These warnings can be found in 1600 packages [4]; they are: > > [4] http://people.debian.org/~tbm/logs/pointer/ > > Here is a list of maintainers and their packages which exhibit such > warnings: [...] > Debian ACE+TAO maintainers > ace 5.4.7-9 Upstream has fixed these, I will backport them ASAP. Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On 6/7/06, Martin Michlmayr <[EMAIL PROTECTED]> wrote: * Matthias Klose <[EMAIL PROTECTED]> [2006-06-07 02:20]: > We did pick two compiler warnings and scanned the build logs of one > archive rebuild on alpha (64bit), where wrong code may be generated. > These warnings can be found in 1600 packages [4]; they are: > [4] http://people.debian.org/~tbm/logs/pointer/ [...] Zak B. Elep gnome-ppp 0.3.21-2 opendchub 0.7.14-2 robotour 3.2.1-2 gnome-ppp is already at 0.3.23-1, and opendchub will be fixed in the next sponsored upload. I'm stumped with robotour, however, due to #360950 :/... Cheers, Zakame -- Zak B. Elep || http://zakame.spunge.org [EMAIL PROTECTED] || [EMAIL PROTECTED] 1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Martin Michlmayr wrote: > Colin Tuckley > ploticus 2.20-4 This and several other benign warnings will be fixed in the next upload. Colin -- Colin Tuckley | [EMAIL PROTECTED] | PGP/GnuPG Key Id +44(0)1903 236872 | +44(0)7799 143369 | 0x1B3045CE "Apple" (c) Copyright 1767, Sir Isaac Newton. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
On Wed, Jun 07, 2006 at 11:53:24PM +0100, Darren Salt wrote: > The others are trivially fixable; of these, the one in libavcodec is already > fixed in CVS. I've committed the rest (they're basically s/int/long/) and am > forwarding them appropriately. long is not appropriate to save pointers, you need to use intptr_t or uintptr_t. Bastian -- If some day we are defeated, well, war has its fortunes, good and bad. -- Commander Kor, "Errand of Mercy", stardate 3201.7 signature.asc Description: Digital signature
Re: GCC 4.1 now the default GCC version for etch
On Wed, Jun 07, 2006 at 10:28:29AM +0200, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > * Matthias Klose <[EMAIL PROTECTED]> [2006-06-07 02:20]: > > We did pick two compiler warnings and scanned the build logs of one > > archive rebuild on alpha (64bit), where wrong code may be generated. > > These warnings can be found in 1600 packages [4]; they are: > > [4] http://people.debian.org/~tbm/logs/pointer/ > > Here is a list of maintainers and their packages which exhibit such > warnings: > > Mike Hommey > xulrunner 1.8.0.1-11 What I quite don't get is why xulrunner gets warnings while firefox and thunderbird don't... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Am Mittwoch, 7. Juni 2006 10:28 schrieb Martin Michlmayr: > Hendrik Sattler > obexftp 0.19-4 Those can be ignored for now, as they are double casts: uint32_t -> char* -> int Not nice but won't harm, I guess (or do we have 16bit architectures?). And not related to GCC-4.1 at all. HS pgpdUjcVT8ATn.pgp Description: PGP signature
Re: GCC 4.1 now the default GCC version for etch
On Wed, Jun 07, 2006 at 10:28:29AM +0200, Martin Michlmayr wrote: > * Matthias Klose <[EMAIL PROTECTED]> [2006-06-07 02:20]: > > We did pick two compiler warnings and scanned the build logs of one > > archive rebuild on alpha (64bit), where wrong code may be generated. > > These warnings can be found in 1600 packages [4]; they are: > > [4] http://people.debian.org/~tbm/logs/pointer/ > Here is a list of maintainers and their packages which exhibit such > warnings: > Steve Langasek > freetds 0.63-2 > unixodbc 2.2.11-13 The unixodbc warnings are in a couple of insignificant demo drivers. The freetds ones should be fixed already with 0.63-3. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: GCC 4.1 now the default GCC version for etch
I demand that Martin Michlmayr may or may not have written... > * Matthias Klose <[EMAIL PROTECTED]> [2006-06-07 02:20]: >> We did pick two compiler warnings and scanned the build logs of one >> archive rebuild on alpha (64bit), where wrong code may be generated. These >> warnings can be found in 1600 packages [4]; they are: [4] >> http://people.debian.org/~tbm/logs/pointer/ > Here is a list of maintainers and their packages which exhibit such > warnings: [snip] > Darren Salt > libjsw 1:1.5.5-1 Will look at - hmm, 1.5.6 is available... [snip] > Siggi Langauf > xine-lib 1.1.1-1.1 The warnings for src/libreal/xine_decoder.c are a problem, but only if the relevant RealPlayer 8 codecs are installed. (Do 64-bit versions exist?) The others are trivially fixable; of these, the one in libavcodec is already fixed in CVS. I've committed the rest (they're basically s/int/long/) and am forwarding them appropriately. [snip] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Output *more* particulate pollutants. BUFFER AGAINST GLOBAL WARMING. Avoid GOTOs completely if you can keep the program readable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
* Matthias Klose <[EMAIL PROTECTED]> [2006-06-07 02:20]: > We did pick two compiler warnings and scanned the build logs of one > archive rebuild on alpha (64bit), where wrong code may be generated. > These warnings can be found in 1600 packages [4]; they are: > [4] http://people.debian.org/~tbm/logs/pointer/ Here is a list of maintainers and their packages which exhibit such warnings: A. Maitland Bottoms cmake 2.2.3-1 predict 2.2.2-6 vtk 4.4.2-10 ARAKI Yasuhiro openggsn 0.84-1 Aaron M. Ucko fltk1.1 1.1.7-2 goo 0.155-5 ncbi-tools6 6.1.20060507-2 Adam F. Rogoyski le 1.9.1-4.1 Adam Lazur screen 4.0.2-4.1 Adeodato Simó mutt 1.5.11+cvs20060403-1 Adriaan Peeters link-monitor-applet 1.3-4 Adrian Bridgett cftp 0.12-4 gmemusage 0.2-10 hunt 1.5-4 nighthawk 1.0-15.1 tgif 1:4.1.44-4 xmove 2.0beta2-8 xonix 1.4-21.1 Adrian von Bidder rapple 1.0-1 Akira TAGOH at-spi 1.7.7-2 gail 1.8.11-2 gtk+1.2 1.2.10-18 libgail-gnome 1.1.3-2 Al Stone laptop-net 2.26-3 qprof 0.5.2-1 Alan Bain rbootd 2.0-8 Alastair McKinstry ltp 20050107-3 newt 0.52.2-4 Alberto Gonzalez Iniesta icmpinfo 1.11-5 irda-utils 0.9.16-11 netkit-rusers 0.17-6 paketto 1.10-6 sing 1.1-11 Alen Zekulic the 3.1-4 Alex Hudson hula 0.1.0+svn379-2.1 Alex Pennace dircproxy 1.0.5-4 Alex Romosan xrn 9.02-7.1 Alexander Wirt fisg 0.3.8-2 keepalived 1.1.11-3 Alexandre Fayolle xmldiff 0.6.7-2 Alexandre Pineau ire 0.92-2 nedit 1:5.5-2 Alioth Games Devel Team netpanzer 0.8+svn20060319-1 Alvaro Lopez Ortega cherokee 0.5.2-1 Anand Kumria libsndfile 1.0.15-3 sweep 0.9.0-2 tap-plugins 0.7.0-2 zeroconf 0.9-1 Andre Filipe de Assuncao e Brito notification-daemon 0.3.4-4 update-notifier 0.41.3-1 Andreas Barth libapache-mod-dav 1.0.3-10 mgetty 1.1.35-2 netpbm-free 2:10.0-10.1 Andreas Metzler gnutls12 1.2.9-2.1 newsx 1.6-2 Andreas Rottmann guile-gnome-platform 2.7.99-4 serveez 0.1.5-2 sqlite 2.8.16-1 zinf 2.2.5-5.2 Andreas Tille fastlink 4.1P-fix91-1 Andrew Lau cinepaint 0.20-1-1.2 gnome-nettool 1.4.1-1 gtksourceview 1.4.2-2 tsclient 0.140-3 Andrew Mitchell pnet 0.7.4-1 Andrew Pollock argus-client 2.0.6.fixes.1-3 argus 1:2.0.6.fixes.1-11 elfsign 0.2.2-2 Andrew Stribblehill cfengine2 2.1.20-1 unlambda 2.0.0-5 Andrew Suffield tla 1.3.3-3.2 Andrés Roldán lilo 1:22.6.1-7 Angel Ramos cronosii 0.2.2.23.1-3 Anibal Monsalve Salazar fdutils 5.5-20050303-2 rpm 4.4.1-8 Anselm Lingnau abcmidi 20060422-1 tkdvi 0.3.1-1.2 Anthony Fok freetype1 1.4pre.20050518-0.3 iterm 0.5-5.1 xcin2.3 2.3.04.3-3.1 xcin 2.5.2.99.pre2+cvs20030224-1.1 Anthony Towns netkit-base 0.10-10.3 Ari Pollak drscheme 1:301-15 gimp 2.2.11-1 libgimp-perl 2.0.dfsg+2.2pre1.dfsg-1 librcov-ruby 0.3.0-1 Arjan Oosting gaim-extendedprefs 0.5-2 Arnaud Patard control-center 1:2.12.3-2 teatime 2.4-2 Artur R. Czechowski t1lib 5.1.0-2 Ashley T. Howes lavaps 2.7-4 Atsuhito KOHDA lynx-cur 2.8.6-20 Atsushi KAMOSHIDA aish 1.13-5 Atsushi Mitsuka canna 3.7p3-3 Aurelien Jarno gcc-m68hc1x 1:3.3.6+3.1-1 ksimus-datarecorder 0.3.6-9 ksimus-floatingpoint 0.3.6-9 ksimus 0.3.6-2-10 sdcc 2.5.0-11 zziplib 0.12.83-5 Balbir Thomas xppaut 5.85-3.2 Bao C. Ha libecgi 0.6.2-2.3 Barak A. Pearlmutter gtkboard 0.11pre0-5 xgraph 12.1-5 Bart Martens libiodbc2 3.52.4-3 libtk-tablematrix-perl 1.22-1 open-cobol 0.32-2 screentest 1.0-4 Bartosz Fenski adesklets 0.5.0-2 fuse 2.5.3-2 libparagui1.0 1.0.4-10.2 xmms-find 0.5.2-1 Baruch Even mdk 1.2.1-1.1 xmbdfed 4.7patch1-3 Bas Zoetekouw exscalibar 1.0.4-5 freesci 0.3.5-2 Bastian Blank ibm-3270 3.3.4p6-3 omniorb4 4.0.6-2 python-omniorb2 2.6-3 Bastian Kleineidam libgringotts 1.2.1-9 libpam-mount 0.13-2 Bdale Garbee dds2tar 2.5.2-3 yforth 0.1beta-18 Ben Armstrong lmemory 0.6c-1.1 snowflake 0.01a-7 Ben Burton python-pgsql 2.4.0-7 regina-normal 4.3.1-1 Ben Collins sxid 4.0.5 Benjamin Drieu grisbi 0.5.8-1 w9wm 0.4.2-5 xbvl 2.2-5.1 Benjamin Seidenberg easyh10 1.2.1-2 Bernd Eckenfels ircii 20051015-1 net-tools 1.60-17 Bernhard R. Link wm2 4-9 xbuffy 3.3.bl.3.dfsg-3 xfm 1.5-1 Bill Allombert flwm 1.00-9 gap 4r4p7-1 Botond Botyanszki gjiten 2.5-1 Bradley Bell bakery2.3 2.3.11-2 gtk+extra17 0.99.17-2.2 gtk+extra 1.0.0-1 gtkmm2.0 2.2.12-2 gtkmm2.4 1:2.6.5-1 gtkmm 1.2.10-8 Brendan O'Dea vile 9.5-g2 Brent A. Fulgham gnustep-netclasses 0.0.20040112-2.1 Brian Mays netcdf 3.6.0+3.6.1-beta3-0.1 Bruno Barrera C. giftoxic 0.0.10-4 portsentry 1.2-10 xmms-defx 0.9.9-2 C.M. Connelly lcdf-typetools 2.36-1 Cai Qian d4x 2.5.7.1-2 gkrellm 2.2.9-1 Camm Maguire codebreaker 1.2.1-5 gcl 2.6.7-14 lam 7.1.1a-1.1 Carlo Contavalli ne 1.42-1 Carlo Segre fityk 0.7.3-1 Celso González ap-utils 1.4.1+1.5pre1-1 Chad Walstrom clamsmtp 1.6-1 Changwoo Ryu ami 1.2.3-2 imh
