3 ms·

Interesting. And the tl;dr for the bug is: byte_count := (n+7) / 8; When n is near max size, it overflows to a small number, then (small number) / 8 = 0 the

• jjnoakes 9y ago
  One can do it without restricting the range as well, if the full range of inputs is needed. In C: (n / 8) + !!(n % 8);
  • adrianratnapala 9y ago
    This is correct, and is sometimes necessary, but is a last-ditch save, since as written, it involves a branch. Much better if you can let the n+7 expand to a wider integer type. Or better yet, if you can ensure that it won't overflow in the first place -- which is what they did by restricting the type.
    • jjnoakes 9y ago
      There's no branch required on architectures I'm familiar with. What branch do you refer to?
    • einmaliger 9y ago
      My x86-assembly has become very rusty, but couldn't it work like this, not using a branch: (with eax being the unsigned 32-bit input word) xor ebx, ebx test al, 7 stnz bl shr eax, 3 add eax, ebx (edit: replaced a movzx with an xor)
      • adrianratnapala 9y ago
        My assembly is probably worse than yours: and that is why I weaseled with "as written". I expect good compiler -- such as the ones we use every day will get this right. But clever compiler still give me the willies, with their less-than-literal interpretations of the meaning of what I wrote. I prefer code that is efficient good (whether that means fast, or something else appropriate to the circumstance) when taken literally, and then trust trust the compiler to smooth over my naivity about what efficiency really means.