Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

jDataView should not have intrinsic endianness #22

Mithgol opened this Issue Jun 30, 2012 · 5 comments


None yet
3 participants

Mithgol commented Jun 30, 2012

According to the current (Editor's Draft 02 April 2012) and the previous (Version 1.0, 08 February 2011) version of DataView specifications,

  • the constructor of DataView has only three arguments (buffer, byteOffset, byteLength), but does not have the fourth (littleEndian);
  • consequently, the DataView object does not have any endianness of its own;
  • when optional boolean argument littleEndian in any of the read/write multi-byte methods is missing, it does not mean “use the object's endianness given in the constructor”, it simply means that the value is stored in big-endian byte order.

The current implementation of jDataView does not correspond to the above mentioned details of DataView specifications:

  • the constructor of jDataView has four arguments (buffer, byteOffset, byteLength, littleEndian);
  • the fourth of those arguments (littleEndian) defines the object's intrinsic endianness (_littleEndian property);
  • when optional boolean argument littleEndian in any of the read/write multi-byte methods is missing, the value of _littleEndian property is used instead of the big-endian byte order.

The difference between jDataView and DataView does not exist unless someone actually gives some fourth argument to the constructor — and that person probably knows what it means, I presume.

However, this difference adds an unnecessary processing complexity to the implementation. For each read/write multi-byte operation, an additional check becomes necessary:

if (littleEndian === undefined) {
   littleEndian = this._littleEndian;

That's why I believe that jDataView implementation may become faster if the littleEndian argument in the constructor and the _littleEndian property in the object are eliminated (with all of the code lines that use them).


vjeux commented Jun 30, 2012

I created this library to make it easy to parse binary files in Javascript before I knew about DataView specification. Then I heard about it and found that I could be compatible with it with.

But I find that the DataView API is too low-level for my usage. For example, it is really a pain to have to maintain the cursor in the client code. Everything I read is in little endian, it is also really annoying to have to pass true for every single read.

This is why I extended the API, while being compatible with the standard API at the cost of a slight performance penalty.

(I'm not really sure I want to keep the little endian by default and therefore breaking with the official API though)


Mithgol commented Jun 30, 2012

Maintaining the cursor is great. (According to the specs, byteOffset is required, and that means you may do whatever you want when that argument is missing and still jDataView would work with any DataView code.)

Little-endianness is the other thing: if you keep it in jDataView by default, this library is incompatible with the DataView specs.

(I don't know why exactly is that the spec authors were to make big-endianness the default. Maybe they had their reasons, WebGL-related. Maybe that's because IP is big-endian, so called “network byte order”.)

I suggest making jDataView big-endian by default as DataView. However, after that you'll have to rewrite the tests and the jParser.


vjeux commented Jun 30, 2012

I think It's best to switch back to big-endian by default to be compatible with the spec.


Mithgol commented Jun 30, 2012


Merge #17 to get the big-endian.


Mithgol commented Aug 8, 2012

#17 is closed in favour of #24.

@RReverser RReverser closed this Jun 1, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment