Mark Dickinson <dicki...@gmail.com> added the comment: Interesting. I agree that that looks like a case where it would be desirable for a >> -n to do a << n.
By the way, I don't think your formula is quite correct: your crc is going to grow unboundedly as extra data bytes come in. I suspect that you want to mask the result with (1 << crc_width) - 1 after each update. (And what's the '& 0xFF' for? Isn't it redundant?) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1205239> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
