Messages in this thread | | | Date | Wed, 09 Nov 2011 22:49:14 -0600 | From | Mike Mestnik <> | Subject | drivers/char/random.c: Open ended int size, makes assumption always 4 bytes. |
| |
Given that 64bit systems are farilly common it stands to reason that calculations that need to use 32bit int/float(s) are appropriately type cast. I understand that while 64bit systems have pointers that are 64bit and that the size of int may well be 32bit, it's important that type casts and shifts such as these take sizeof(int) into account... Even if sizeof(int) can be assured to always be 4.
In this case I believe it would be best to use more specific typecasts to get accurate calculations.
Note the sifts here are 4bits, not 4bytes. Still I think there is room for problems here if these functions are passed int(s) with bits above 32set.
http://j.mp/uj0JZC http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/char/random.c;h=63e19ba56bbea5a12ee784f023bd13a758eaf611;hb=HEAD#l683
On another note, I can't discover what "uint code" should be. It seams like a good place to avoid hitting the repeat squelch. For my project I may have two 6 sided dice and there is a good chance they would hit the same total for adjacent iterations, dropping this result seams like something to avoid if the goal is to pool randomness. At the same time I'd wonder if I should shift/xor to undo the effects of this function or if this is merely the first step in massaging the data into random output. One wonders what I should do.
My first thought would be to do something like: void putc_randomness(unsigned char code) { static unsigned char last_value; value^=1; add_input_randomness(32768, code ^ (code >> 4) ^ value, value); }
| |