On 05-Sep-13 19:52, Kurt Roeckx wrote:
> Pretty please stop using longs as something that can hold a
> pointer. In general you should not cast a pointer to any integer
> type. If you really have to, use an intptr_t type.
Believe me, a 'long' will do. There is no architecture where
a 'long' can not hold a full pointer. The linux kernel as
just one example heavily relies on the fact that
sizeof(long)>=sizeof(pointer).
Using 'intptr_t' will lead to problems because older C environments do
not know about it and sometimes 'configure' scripts do ugly things with
'intptr_t'. As an example, 'e2fsprogs' broke with gcc-4.0 because it
used 'intptr_t'.
> > @@ -141,7 +141,7 @@
> > {
> > jint rc = 0;
> > XPCOM_NATIVE_ENTER(env, that, PR_1Malloc_FUNC);
> > - rc = (jint)PR_Malloc(arg0);
> > + rc = (long)PR_Malloc(arg0);
>
> So you avoid an error by first casting it from a pointer to a
> long and then casting it (implicitly) to an jint (int) instead of
> doing it with only 1 cast? Of course this will now compile, but
> how useful is this if it doesn't run?
>
> I'm happy g++ considers casting a pointer to an int as an error.
> Too bad gcc only gives a warning about it. But it doesn't help
> if people just "shut up the warning".
The package worked this way on 64-bit architectures with gcc-3.3
for a long time and nobody complained about that as far as I know.
The patch just restores the status quo that was used with gcc-3.3.
Of course a real fix which perhaps redefines 'jint' as 'long' would
be better.
Regards
Andreas Jochens
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
