Improve compatibility of FDC command responses

This commit is contained in:
Jeff Parsons 2014-10-29 12:45:06 -07:00 • committed by jeffpar
commit 234d6bbfd8
7 changed files with 819 additions and 786 deletions

View file

@ -125,7 +125,7 @@ I still tend to follow Charles Simonyi's "[Hungarian](http://en.wikipedia.org/wi
conventions -- or rather, a naming convention loosely inspired by Hungarian.
For example, if I need a string or numeric variable representing a "thing," I will name it "sThing" if it's a
string or "iThing" if it's a number (or possibly "nThings" if it represents a total of Things or or "cThings"
string or "iThing" if it's a number (or possibly "nThings" if it represents a total of Things or "cThings"
if it's a counter of Things). If a string or numeric variable has a very short-term use, I'll probably just name
it "s" or "i".

View file

@ -18,8 +18,10 @@ To verify, type the following into any JavaScript REPL (eg, Node):
-1526726656
> n &= 0x80808080
-2147483648
> n.toString(16)
'-80000000'
> n == 0x80000000
false
> n == -0x80000000
true
So the notion that bitwise operators yield 32-bit results isn't exactly right; the sign (bit 31) of every 32-bit
result is always extended into the entire 52 "significand" bits of the underlying 64-bit float. And it's
@ -42,19 +44,19 @@ an operation as innocuous-looking as:
> n.toString(16)
'-80000000'
Viola: instant negative number! To continue the fun, now "or" one into bit 0:
Viola: instant negative number! To continue the fun, set bit 0 of 0x80000000, which should give you 0x80000001:
> n |= 1
-2147483647
> n.toString(16)
'-7fffffff'
Viola: all low 32 bits have instantly flipped!
WTF? Have all the low 32 bits flipped instead?
Actually, no, this time, I'm pulling your leg. The low 32 bits of the internal value are exactly what you would
expect: 0x80000001 (the internal representation looks more like 0xFFFFF80000001). The toString() method is
just a little misleading. As the MDN docs explain, for a negative number, toString() returns the positive
representation of the number, preceded by a - sign, *not* the "two's complement" of the number.
expect: 0x80000001 (the internal representation is more like 0xFFFFF80000001). But as the [MDN Docs](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/toString)
explain, for a negative number, toString() returns the positive representation of the number, preceded by a - sign,
*not* the "two's complement" of the number.
*[@jeffpar](http://twitter.com/jeffpar)*
*October 26, 2014*