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 a
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 support
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
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'
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 t
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:/
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",
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 th
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 str
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 (unles
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
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]
wi
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 supportin
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,
>>> > assu
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.
>>
>>
"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 po
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
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
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.
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.
> >
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
-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. [...]
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
-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 abo
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 r
-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'v
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 si
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
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 a
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
> > forward
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.
>>>
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
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
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 d
* 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, a
* 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 w
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];
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
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]
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? Co
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 [
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 packag
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
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
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.
> > Thes
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
pgpdUjcVT
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 fou
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
* 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/log
49 matches
Mail list logo
