Lazy `-b` evaluation
resilar opened this issue · 2 comments
Currently -b 4: for a long input (e.g., 1GB) is handled non-lazily by allocating a huge array to store all the input bits following the 4th byte. This is stupid. Be smarter.
Maybe consider simply limiting the maximum number of selected bits to w (e.g. 32 for CRC-32) for unbounded -b slices. This might work well enough in practice.
59e3e3d commit limits the maximum number of bits selected by a single -b slice to w, i.e., the CRC polynomial (register) width. Rudimentary testing shows that this approach works well in practice and does not seem to make forging fail in situations where it previously succeeded with the old code. Note that this is not obvious because the w bits chosen by an unbounded -b are not necessarily contiguous if the step parameter of the slice is not equal to 1 bit, so even if -o 420 which selects w contiguous bits is guaranteed to make forging successful, the same may not hold for an -b slice that also selects w bits because they may be non-contiguous.
I think we should consider deprecating offset switches -o/-O at some point because -b switches are now expressive and user-friendly enough to offer the same functionality: -o 42 and -b 42: are essentially identical. Similarly, -O 42 and -b -42: are equivalent to each other. The only disadvantage of -b command-line options is that appending to the input is unsupported when forging CRC checksums, whereas -o and -O do support appending to the end of the input message. However, the current append mechanism should probably be rewritten anyway to support prepending also (as discussed in issue #11). I'm creating a new issue regarding the deprecation of -o/-O in favor of -b.
Closing this issue, at least until it turns out there are some cases where the previous behavior forged some messages correctly while the new "select at most w bits" approach fails.