4

Does the JavaScript code

var n = 8; // or some arbitrary integer literal
n >> 1;

always denote "integer devision by 2 without remainer"? My concern is the endianess if the integer literal is larger than one byte.

The background of my question is the following:

I have an integer variable in the range from 0 to 2^32-1 that would fit into an uint32 if I had a typed programming language different than JS. I need to convert this into an Uint4Array with four elements in little endian order.

My current JavaScript approach is:

function uInt32ToLEByteArray( n ) {
  var byteArray = new Uint8Array(4);
    for( var i = 0; i < 4; i++ ) {
      byteArray[i] = n & 255;
      n >> 8;
    }
  return byteArray;
}

This code works in my browser, but I wonder if this would do everywhere. The principal idea is the fill the array by taking the LSB and divdiding by 256. But a real divions "/" would convert the variable into a floating point variable. So I use ">>8" but this actually assumes big endianness.

user2690527
  • 1,729
  • 1
  • 22
  • 38
  • "This code works in my browser, but I wonder if this would do everywhere." You mean in other languages? Or are you asking to confirm that `x >> y` casts `x` to a (signed) _Int32_. It also keeps the left-most bits (they don't become `0`, which is what would happen if you used `>>>`). – Paul S. Aug 16 '13 at 20:09
  • With "everywhere" I wanted to say "in every browser on every machine". My computers are all Intel-compatible, so I cannot confirm what would happen on devices with big endianness. – user2690527 Aug 16 '13 at 21:17

1 Answers1

2

The code you have given has absolutely no relevancy to endianess.

However, if you were to reinterpret the byte array in say uint32 array, then the result would be different depending on the endianess of the machine the browser runs on.

First, fix the bug in the code:

function uInt32ToLEByteArray(n) {
    var byteArray = new Uint8Array(4);
    for (var i = 0; i < 4; i++) {
        byteArray[i] = n & 255;
        n >>>= 8; //simply doing n >> 8 has no effect actually
    }
    return byteArray;
}

Then

var a = uInt32ToLEByteArray(0xFF)
console.log(a);
//always [255, 0, 0, 0]

var b = new Uint32Array(a.buffer);
console.log(b);
//[255] on little endian machines
//[4278190080] on big endian machines
Esailija
  • 138,174
  • 23
  • 272
  • 326
  • Hi. Sorry, `n >> 8` was a typo. That is obvious. The second part of your respons answers my question ` var a = uInt32ToLEByteArray(0xFF) console.log(a); //always [255, 0, 0, 0]` is what I hoped to to hear, although I do not understand why you say endianess is irrelevant. – user2690527 Aug 16 '13 at 21:18
  • @user2690527 cos it is - it is always same result for that regardless of endianess thus endianess is not relevant – Esailija Aug 16 '13 at 22:18
  • I thought the following could be true: Assume we have an integer with decimal value 992, this is 0x03E0 as a hex literal. On a big endian machine this is stored as the byte sequence "0x03,0xE0". Now we do a right shift by four bits (>>4). The result is "0x00,0x3E". Back to decimal representation this equals 62. In summary, ">>4" is equivalent to a devision by 2^4=16. Now we come to my false assumption for little endian machines. 992 is equal to 0x03E0 and stored as "0xE0,0x03". A shift by 4 bits yields "0x0E,0x00" which is 0x000E as a numeric literal or 14 as a decimal number. – user2690527 Aug 17 '13 at 17:08
  • @user2690527 the shift is not performed in the memory, but it is first loaded from memory into a CPU register (where endianess is irrelevant since you cannot address the register in bytes). It will therefore have same logical result (62). The number 62 itself is then stored in memory with endianess dependent format. – Esailija Aug 17 '13 at 18:55
  • @user2690527 I have found some articles for you so you can understand when endianess matters http://en.wikipedia.org/wiki/Endianess http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/Data/endian.html – Esailija Aug 17 '13 at 19:05