465638 - Get rid of especially silly integer typedefs in js

Status: RESOLVED DUPLICATE of bug 712034

(Core :: JavaScript Engine, enhancement)

Description

[Jason Orendorff [:jorendorff]]

intN is just a typedef for int on all platforms. JSIntn is just a typedef for intN. JSSize is a typedef for size_t. And so on. We should stop using these redundant typedefs (replace intN with int, for example) and delete the obsolete parts of jstypes.h.

We also want to start using stdint.h types where appropriate (e.g. int32_t instead of jsint) but that's a separate bug as it'll take some autoconf magic.

Comment 1

[Brendan Eich [:brendan]]

jst@moz had stdint.h woes a few years back doing the NPRuntime plugin API. Cc'ing him.

These names may be more familiar with s/JS/PR/ and a peek at prtypes.h. Used to be that SpiderMonkey depended on NSPR, but in 1998 it was made to stand alone in browser builds as well as its "JSRef" release form. The history is boring but it may help make sense of all this (maybe not :-P -- I was not in favor of the NSPR-ization of SpiderMonkey in 1998, but it wasn't my call as I'd moved on to found mozilla.org).

I'm an old Unix hacker, I can deal with _t typedef stems. Some find them ugly. But they're standard, and standards are good. Nanojit uses them, so we should too. The only special-pleading I'll do here is for jsint and jsuint as veneer on top of the very concrete "32" name-part. Not that we can change to 64-bit ints, but just as a conceptual separation.

/be

Comment 2

[Johnny Stenback (:jst)]

Yeah, the NPRuntime API uses C99 types, and to do that we ended up having to create this, and that's only for a very small set of C99 types:

http://mxr.mozilla.org/mozilla-central/source/modules/plugin/base/public/nptypes.h