Change CSipHasher's count variable to uint8_t #19931

SipHash technically supports arbitrarily long inputs (at least, I couldn't find a limit in the paper), but only the low 8 bits of the length matter. Because of that we should use an unsigned type to track the length (as any signed type could overflow, which is UB). uint8_t is sufficient, however.

Fixes #19930.

Very nice and straightforward solution. ACK e3318f4b06a5dfc3bf5a2a1592ac16ff7b306560

@sipa I'm afraid the fix is incorrect: to get rid of the signed integer overflow you'll have to change also the local variable c in CSipHasher::Write to uint8_t :)

FWIW this is also fixed in #18014 but I like the decrese in the size of CSipHasher :) utACK 812037cb80f72096738cf2b0c15b39536c6c1e24

@practicalswift Fixed.

@elichai It's not actually a decrease in size, as its alignment is 8 bytes (at least on 64 bit platforms), so the size is 24 bytes before and after.

Thanks for the swift (and practical!) fix! :)

ACK 812037cb80f72096738cf2b0c15b39536c6c1e24

@elichai It's not actually a decrease in size, as its alignment is 8 bytes (at least on 64 bit platforms), so the size is 24 bytes before and after.

It's not like we store millions of SipHashers for this to matter anyway. Nor does it matter for performance on any supported architecture :smile: (oh, crap, it might even be slower because the &0xff sometimes needs to be done explicitly)

anyhow re-ACK 812037cb80f72096738cf2b0c15b39536c6c1e24

ACK 812037cb80f72096738cf2b0c15b39536c6c1e24

@elichai It's not actually a decrease in size, as its alignment is 8 bytes (at least on 64 bit platforms), so the size is 24 bytes before and after.

I guess you meant 6*8 = 48 bytes?