JavaScript Endian Encoding?

Question

A response on SO got me thinking, does JavaScript guarantee a certain endian encoding across OSs and browsers?

Or put another way are bitwise shifts on integers "safe" in JavaScript?

Answer 1

Yes, they are safe. Although you're not getting the speed benefits you might hope for since JS bit operations are "a hack".

Answer 2

JavaScript doesn't have an integer type, only a floating point type. You can never get close enough to the implementation details to worry about this.

Answer 3

are bitwise shifts on integers "safe" in JavaScript?

Only for integers that fit within 32 bits (31+sign). Unlike, say, Python, you can't get 1<<40.

This is how the bitwise operators are defined to work by ECMA-262, even though JavaScript Numbers are actually floats. (Technically, double-precision floats, giving you 52 bits of mantissa, easily enough to cover the range of a 32-bit int.)

There is no issue of 'endianness' involved in bitwise arithmetic, and no byte-storage format where endianness could be involved is built into JavaScript.

Answer 4

Shifting is safe, but your question is flawed because endianness doesn't affect bit-shift operations anyway. Shifting left is the same on big-endian and little-endian systems in all languages. (Shifting right can differ, but only due to interpretation of the sign bit.)

Endianness only comes into play when you have the option of interpreting some block of memory as bytes or as larger integer values. Javascript doesn't give you that option since you don't get access to arbitrary blocks of memory, especially not the blocks of memory occupied by variables.

Endianness describes physical storage order, not logical storage order. Logically, the rightmost bit is always the least significant bit. Whether that bit's byte is the one that resides at the lowest memory address is a completely separate issue, and it only matters when your language exposes such a concept as "lowest memory address," which Javascript does not.

Answer 5

ECMA Script does actually have a concept of an integer type but it is implicitly coerced to or from a double-precision floating-point value as necessary (if the number represented is too large or if it has a fractional component).

Many mainstream Javascript interpreters (SpiderMonkey is an example) take a shortcut in implementation and interpret all numeric values as doubles to avoid checking the actual native type of the value for each instruction. As a result of the implementation hack, bit operations are implemented as a cast to an integral type followed by a cast back to a double representation. It is therefore not a good idea to use bit-level operations in Javascript and you won't get a performance boost anyway.