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]
