* Various code inside and outside of JS uses JS_BYTES_PER_WORD, so I added it to js-config.h
* Existing code uses JS_BYTES_PER_DOUBLE, JS_BITS_PER_WORD_LOG2, and JS_ALIGN_OF_POINTER so I've added autoconf tests for those
r=crowder r=jimb
* Various code inside and outside of JS uses JS_BYTES_PER_WORD, so I added it to js-config.h
* Existing code uses JS_BYTES_PER_DOUBLE, JS_BITS_PER_WORD_LOG2, and JS_ALIGN_OF_POINTER so I've added autoconf tests for those
r=crowder r=jimb
At configure time, check for <stdint.h>. If we don't have it, find
integer types of various sizes. On Windows, where we can't run
compilation tests in configure, hard-code definitions suggesting the
use of the built-in __intN types for the exact-size types, and
<stddef.h> for the pointer-sized types.
Use namespace-clean names for the preprocessor macros we define.
Since these types are used in the public JavaScript API, the configure
script needs to place the definitions it finds in js-config.h, the
installed configure-generated header, so it can be used by jsapi.h and
that gang.
New header js/src/jsstdint.h does what it takes to get definitions for
the exact-size and pointer-size integral types. It includes
<stdint.h> when available, uses the types found by configure.in to
define the {,u}int{8,16,32,64,ptr}_t types itself, or uses the __intN
types and the <stddef.h> header.
Remove now-unnecessary and possibly conflicting definitions of intN_t
types from js/src/nanojit/avmplus.h.
