User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.10 Safari/537.36 Steps to reproduce: Build on Windows in a 64bit config, with clang. Actual results: ..\..\third_party\nss\nspr\pr\src\threads\combined\pruthr.c(82,23) : warning(clang): cast to 'char *' from smaller integer type 'long' [-Wint-to-pointer-cast] stack->stackTop = (char*) ((((long)&type + _pr_pageSize - 1) ^ ..\..\third_party\nss\nspr\pr\src\threads\combined\pruthr.c(182,25) : warning(clang): cast to 'char *' from smaller integer type 'long' [-Wint-to-pointer-cast] ts->allocBase = (char*) ((((long)&ts + _pr_pageSize - 1) ^ 2 warnings generated. long is only 32bit on 64bit Windows ( http://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models ), so this is a real bug. These two lines should use intptr_t instead of long. Expected results: These two lines should use intptr_t, then the code would be correct and clang wouldn't warn.

Here's a patch.

thakis: thank you for the bug report and the patch. NSPR has been using its own (poorly named) PRWord type for this purpose. PRWord is defined as either long or PRInt64: http://mxr.mozilla.org/nspr/ident?i=PRWord So I changed intptr_t to PRWord in this patch. At some point we should declare it is OK to use intptr_t in NSPR and make the switch throughout the source code. Patch checked in on the NSPR trunk: https://hg.mozilla.org/projects/nspr/rev/931b8f39bbf5

Comment on attachment 8529183 [details] [diff] [review] nspr-no-pointers-in-longs.patch Review of attachment 8529183 [details] [diff] [review]: ----------------------------------------------------------------- ::: nspr/pr/src/threads/combined/pruthr.c @@ +73,4 @@ > #ifndef HAVE_CUSTOM_USER_THREADS > stack = PR_NEWZAP(PRThreadStack); > #ifdef HAVE_STACK_GROWING_UP > + stack->stackTop = (char*) ((((intptr_t)&type) >> _pr_pageShift) I think casting to an unsigned type (uintptr_t) would be better so that we don't need to worry about whether the right-shift is an arithmetic shift or logical shift. In this case whether the right shift is arithmetic or logical doesn't matter because we are immediately left-shifting by the same number of bits.