Posted on

RFC1925 – The 12 Truths.

(1) It Has To Work.

(2) No matter how hard you push and no matter what the priority,
you can’t increase the speed of light.

(2a) (corollary). No matter how hard you try, you can’t make a
baby in much less than 9 months. Trying to speed this up
*might* make it slower, but it won’t make it happen any
quicker.

(3) With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead.

(4) Some things in life can never be fully appreciated nor
understood unless experienced firsthand. Some things in
networking can never be fully understood by someone who neither
builds commercial networking equipment nor runs an operational
network.

(5) It is always possible to aglutenate multiple separate problems
into a single complex interdependent solution. In most cases
this is a bad idea.

(6) It is easier to move a problem around (for example, by moving
the problem to a different part of the overall network
architecture) than it is to solve it.

(6a) (corollary). It is always possible to add another level of
indirection.

(7) It is always something

(7a) (corollary). Good, Fast, Cheap: Pick any two (you can’t
have all three).

(8) It is more complicated than you think.

(9) For all resources, whatever it is, you need more.

(9a) (corollary) Every networking problem always takes longer to
solve than it seems like it should.

(10) One size never fits all.

(11) Every old idea will be proposed again with a different name and
a different presentation, regardless of whether it works.

(11a) (corollary). See rule 6a.

(12) In protocol design, perfection has been reached not when there
is nothing left to add, but when there is nothing left to take
away.

https://tools.ietf.org/html/rfc1925

Posted on

Javascript: Debugging Bitwise Operators

Most people are never going to even use bitwise ops, especially in JavaScript. But if you really must, beware all is not what it seems!

Problem 1’s Complement
1’s complement seems slightly off?!
console.log(~0xFF); //gives -256

Explanation
You might then automatically assume that JavaScript implementation of 1’s complement is fundamental borked, a cursory Google might even back up that. Obviously its hard to believe that handling of bitwise ops are so broken in a language that is so widely used, but given that few if any web developers’ would actually need bitwise ops maybe its the case. (There are plenty of stack overflow posts that recommend the abuse of the ~ operator)

Taking a closer look at the ECMA script definition you see the definition of NOT as the following[1]:

      Let expr be the result of evaluating UnaryExpression.
      Let oldValue be ToInt32(GetValue(expr)).
      Return the result of applying bitwise complement to oldValue. The result is a signed 32-bit integer.

Now this is where things get interesting. You would naturally assume if you give the NOT operator a 8-bit value you’d get an 8-bit field back, but this is clearly not the case. If you want to dig even further the real concrete instance of the value is a 64-bit IEEE 754 representation see [2].

So that neatly explains why ~0xff transforms to -256

1111 1111
becomes
0000 0000 0000 0000 0000 0000 1111 1111
apply ~ (NOT)
1111 1111 1111 1111 1111 1111 0000 0000
aka -256

But that still leaves a problem, how can you easily debug a value that isn’t a Number but is represented as one…

If you’ve got this far there is probably a very good reason you’re using bitwise ops, otherwise you might have given up on them altogether. So it would be somewhat handy to look at the real value, and not the Int32 representation, which console.log and friends are going to give a misleading value for.

Getting at the full representation
A nice simple function to show all the bits for the input value.

function fullBinaryString(input){
//coerce javascript to show full 32bit integer underneath.
return (input>>>0).toString(2);
}
view raw bits.js hosted with ❤ by GitHub

>>> Operator coerce the value input a 32-bit representation by right shifting and filling in with zeros, depending on your usage you can also slice the value, to only show the 8-bits that are needed to debug, like so:

function to8bitString(input){
//clamp the value to 8-bits by and with 0xFF
var clampedValue = (input&0xFF).toString(2);
//pad the string to make it easier to read.
return String("00000000" + clampedValue).slice(-8);
}
view raw bits.js hosted with ❤ by GitHub

General Rule
If dealing with bits, clamp the field to the proper bit length before assignment. Using an 8-Bit clamped array is no guarantee that the value will be assigned properly, there are cases where the value can be assigned to zero instead of the proper bit value. For an 8-bit you would use array[i] = bits&0xFF this will make sure the value is appropriately truncated and does not get evaluated as a Number.

[1] http://www.ecma-international.org/ecma-262/5.1/#sec-11.4.8
[2] http://www.ecma-international.org/ecma-262/5.1/#sec-4.3.19

Posted on

Factory of the Future

The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment. Warren G. Bennis