我们使用 opentype.js 加载字体文件，并在我们的代码、V8 引擎或 Chromium 中发现了一个错误，该错误返回以下结果：DataView.getInt16() as 65536低于或高于应有的水平。这种情况很少发生（~0.25%），但对于我们的用户来说，每天仍然会发生数百次。因此，我们只能在几台计算机上重现它，而且不一致。某些浏览器选项卡始终有效，而其他浏览器选项卡始终给出不正确的值。
我不是二元运算专家，但了解基础知识。
这是一个例子：假设我们期望513.
在二进制中我们期望：00000000000000000000001000000001 (513)
如果结果是+65536，我们可以通过翻转第 17 位来解释这一点：00000000000000010000001000000001（66049 - 65536 = 513）
如果结果是-65536，我们可以通过翻转前面 16 位的完整集合来解释这一点：11111111111111110000001000000001(-65023 + 65536 = 513)
似乎有时，不知何故，第 17 位会被翻转为1或者将前面填充的整组位以满足16位到32位的转换翻转为1包括两者的补码。
我们已经调试了几天，正在寻求帮助来解决这个问题。我们想确认这个问题是我们的代码还是最近引入到 chromium 或 v8 中的问题。
猜测：这可能是crbug.com/1466088 https://crbug.com/1466088。该修复已经通过发布渠道进行。
如果这个猜测是正确的，那么：
- 此错误仅发生在arm64硬件上，例如配备 M1/M2 芯片的 Mac 以及大多数 Android 设备。 Intel/AMD CPU 上永远不会发生这种情况。
- 仅当启用新的“Maglev”优化编译器时才会出现此错误。启动一个新的 Chrome 实例
--js-flags="--maglev"使它更有可能发生，启动 Chrome--js-flags="--no-maglev"防止它发生。
- 仅当您正在加载的值的两个字节的最高有效位不同时，才会出现此错误。这意味着您的示例中的 513 不会发生这种情况；对于像这样的值会发生这种情况
0b1xxxxxxx0xxxxxxx or 0b0xxxxxxx1xxxxxxx (where x意思是“0或1，并不重要”）。
您能证实这些观察结果吗？
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
