crc32 seems to be different than what fift generates

[flcoder]

I have ...

run()

async function run() {
  // Create some cells
  const c2 = new TonWeb.boc.Cell();
  c2.bits.writeUint(42, 7);

  const c3 = new TonWeb.boc.Cell();
  c3.bits.writeUint(73, 255);

  const c1 = new TonWeb.boc.Cell();
  c1.bits.writeUint8(0);
  c1.refs.push(c2);
  c1.refs.push(c3); 

  const boc = toHex(await c1.toBoc())
  console.log({boc})
}

function toHex (buffer) {
  return Array
      .from (new Uint8Array (buffer))
      .map (b => b.toString (16).padStart (2, "0"))
      .join ("")
}

producing {boc: "b5ee9c72c1010301002a000005080202000102000155003f00…00000000000000000000000000000000000000093f985b405"}

and

<b 0 8 u, <b 42 7 u, b> ref, <b 73 255 u, b> ref, b>
2 boc+>B Bx.

producing B5EE9C7241010301002A000202000102000155003F0000000000000000000000000000000000000000000000000000000000000093355B1411

[flcoder]

I think there are different crc32 algos, and if I recall correctly, ton uses crc32c. Perhaps this could account for the different results.

[EmelyanenkoK]

Yes, TON uses crc32c algorithm so as this library. Differences in example above origin from different serialization flags:
by default toBoc uses following:
has_idx = true, hash_crc32 = true, has_cache_bits = false, flags = 0
https://github.com/toncenter/tonweb/blob/master/src/boc/Cell.js#L196-197
At the same time fift command 2 boc+>B Bx. means that you require serialization only with crc32c hash sum, without index.
If you want to get serialization using TonWeb which coincide with your fift result, change
const boc = toHex(await c1.toBoc())
to
const boc = toHex(await c1.toBoc(false, true, false, 0))

[flcoder]

Awesome, thanks!