Better support for negative bitLength about jdataview HOT 11 CLOSED

From the end of what?

from jdataview.

From the end of the byte, obviously.

from jdataview.

Not very obvious - could be the end of the buffer as well. It sounds like this should be already doable via combination of skip + reading bits, if you want to ignore those in the beginning.

from jdataview.

It doesn't work right.

var jd = new jDataView(2);
jd.writeUint8(0xFE); // 0b11111110
jd.writeUint8(0xFE); // 0b11111110
for (;;) {
  console.log(jd.getUnsigned(-1));
}

Output:

0
63
31
15
7
3
1
0
0
63
31
15
7
3
1
0
0
RangeError

(Did I just put in 16 bits and read back 17 bits? Apparently. And they weren't even right.)

from jdataview.

You are reading negative length - as I said above, this is not supported. You should be using combination of skip + reading bits if you want to read only some bits in the end of byte.

from jdataview.

I want to read the bits backwards. (Lovely compression format I'm dealing with does little-endian BIT order)

from jdataview.

Oh my... :( Well, what I can recommend is to look into jBinary and simply define custom type that would perform bit-by-bit reversion. This is not kind of stuff that is supported natively on any platforms or even widely used, so I don't think it should be in scope of jDataView, but should be pretty easy to implement as custom reusable type.

from jdataview.

Well in assembly you just shift left/right and test the carry bit...

from jdataview.

Well if you need only one last bit, then it's easy here as well - just getUint8() & 1 (or, if you need the highest and not lowest - getUint8() >>> 7).

from jdataview.

Why was this closed?

from jdataview.

I replied above that it's both already possible to do what you want (and even provided how), and adding it to base API just for sugar in specific cases doesn't make much sense.

from jdataview.