[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GCC 4.1 now the default GCC version for etch

Henning Makholm <henning@makholm.net> wrote:
> Scripsit Andreas Metzler <ametzler@downhill.at.eu.org>
>> On 2006-06-07 Matthias Klose <doko@cs.tu-berlin.de> 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;
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

Reply to: