310495 - Patch to bug 9413 breaks build on 64-bit archs

Status: RESOLVED DUPLICATE of bug 310569

(Thunderbird :: General, defect)

Description

[Ilya Konstantinov]

Careless casts of void* to PRInt32. gcc 4.0 is more pedantic and fails with errors.

Comment 1

[Ilya Konstantinov]

Attachment: Fix to regression

First time, used intptr_t.
Second time, casting to int is simply unnecessary so the nsHashtable::Get
return value is used a pointer all along.

Comment 2

[Scott MacGregor]

Comment on attachment 197902 [details] [diff] [review]
Fix to regression

I'd be surprised if this is really the right fix since we don't use intptr_t
int he core mozilla code base.

Comment 3

[Ilya Konstantinov]

intptr_t is C99. Do we allow C99 stuff (like 'long long') in Mozilla or is it
off boundaries? If so, what platform stops us?

If not, what's the Portable Runtime equivalent of an intptr_t type (= integer
which can safely accomodate a pointer's address)?

Comment 4

[Wolfgang Rosenauer [:wolfiR]]

other places in mozilla code are using
NS_PTR_TO_INT32 and similar
http://lxr.mozilla.org/mozilla1.8/source/xpcom/base/nscore.h#423

Comment 5

[Ilya Konstantinov]

Is this really safe? To me, it looks like NS_PTR_TO_INT32 loses data. For
example,  see the 2nd case I fix in my patch: if we used NS_PTR_TO_INT32 there
(admitedly the solution was not to use pointers at all), then every 64bit
pointer on a modulus-2^32 boundary would've equivalented to 0, thus making the
comparison fail.

I don't see why we can't have an intptr_t-like type. (Also, you haven't brought
me a single example of a supported platform on which intptr_t does not exist.)

Comment 6

[Ilya Konstantinov]

I meant "the solution was not to use integers at all, but rather to use pointers
all the way".

Comment 7

[Scott MacGregor]

*** This bug has been marked as a duplicate of 310569 ***