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 fix is to restrict n to [0,MAX-7)

One can do it without restricting the range as well, if the full range of inputs is needed.

In C:

    (n / 8) + !!(n % 8);

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.

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)

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.

There's no branch required on architectures I'm familiar with. What branch do you refer to?