Re: Easy removals: B
Pierre Habouzit <madcoder@debian.org> writes:
> Le Lun 29 Mai 2006 04:27, Goswin von Brederlow a écrit :
>> Pierre HABOUZIT <madcoder@debian.org> writes:
>> > tag 362959 =
>> > tag 362959 + patch
>> > thanks
>> >
>> > I confirm. I have tracked that issue down, it's because upstream
>> > takes pointer on things that should be gsizes (aka 64 bits on
>> > amd64) on things that are gints (32bits).
>>
>> Pointer should be put into intpointer_t if you must. Or better make a
>> union of int and pointer if you have to mix the two. glib should have
>> its own type for intpointer_t or use that itself. Reusing gsizes
>> sounds awfully wrong.
>
>> Isn't that 64bit on 32bit cpus as well?
> it does not seems so, else the bug would be reproducible on 32bits
> machines as well. I think gsize is the size_t from classical C, which
> is 32bits on 32bits CPU (aka an int) and 64bits on 64bits CPU (aka a
> long).
>
> the problem is that they use a glib (gtk ?) API to read files, that has
> a third argument beeing an out argument for the size of the file. I
> don't see where my patch is incorrect, and gcc didn't complained about
> comparisons loosing precision or such. I think upstream uses 32bits
> devel machines, and never saw the problem of mixing g(u)ints with
> gsizes, which is definitely the error.
> --
> ·O· Pierre Habouzit
> ··O madcoder@debian.org
> OOO http://www.madism.org
Ahh, sorry, I misunderstood the problem. You aren't storing the
address of something in an int but are just passing a pointer to a
gint instead of gsize. Changing it to the proper gsize is correct
then.
MfG
Goswin
Reply to: