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
Attachment:
pgpSydYKPk7qi.pgp
Description: PGP signature