xoring until the smaller buffer ends is not semantically correct

[dbkaplun]

In theory you can xor two whole numbers of any size. Since there is a natural, one-to-one mapping between whole numbers and buffers, it makes sense that the xor operation can and should be preserved across the mapping. That means that, when applied to Buffers, it should treat the shorter array as if it was padded with 0s to the longer array's length, instead of ignoring the longer array's extra data. This is the implementation on current master:

module.exports = function xor (a, b) {
  var length = Math.min(a.length, b.length)
  var buffer = new Buffer(length)

  for (var i = 0; i < length; ++i) {
    buffer[i] = a[i] ^ b[i]
  }

  return buffer
}

It should look more like:

module.exports = function xor (a, b) {
  var length = Math.max(a.length, b.length)
  var buffer = new Buffer(length)

  for (var i = 0; i < length; ++i) {
    buffer[i] = (a[i] || 0) ^ (b[i] || 0) // unoptimized, mathematically sound xor
  }

  return buffer
}

Hope that's clear. Let me know if that doesn't make sense. Thanks!

[fanatid]

@dbkaplun a[i] | 0 is faster than a[i] || 0, x ^ undefined = x ^ 0 = x

optimized version with max:

module.exports = function xor (a, b) {
  if (a.length >= b.length) {
    a = new Buffer(a)
  } else {
    var t = a
    a = new Buffer(b)
    b = t
  }

  for (var i = 0; i < b.length; ++i) a[i] ^= b[i]
  return a
}

[dbkaplun]

Good point. In that case, this can be implemented with a one-line change from the existing implementation:

module.exports = function xor (a, b) {
  var length = Math.max(a.length, b.length) // instead of Math.min
  var buffer = new Buffer(length)

  for (var i = 0; i < length; ++i) {
    buffer[i] = a[i] ^ b[i]
  }

  return buffer
}

[dcousens]

That means that, when applied to Buffers, it should treat the shorter array as if it was padded with 0s to the longer array's length, instead of ignoring the longer array's extra data.

I'm not sure I understand your reasoning behind this?

[dbkaplun]

@dcousens because numbers are represented this way when they are xored.

Consider the expression 15 ^ 3. It can be calculated like so:

• 15 ^ 3 = 1111b ^ 11b (xor operates on binary digits, so we convert each number to binary)
• 1111b ^ 0011b (pad with 0s in preparation for xor. 11b is equivalent to 0011b)
• perform bitwise xor for each binary digit to achieve 1100b = 12. Node confirms this. (Note that a ^ 0 = a for any number or binary digit.)

In the same same way we are performing xor on Buffers, which are really just memory-efficient representations of numbers. The only difference is that our current implementation crops the buffers, meaning that the 15 ^ 3 example would come out to 11b ^ 11b = 0. So it is clearly more correct to xor excess buffer indices with 0 than to drop them altogether.

[dcousens]

Oh, true. Of course.

I agree with this 👍