drivers/char/random.c: Open ended int size, makes assumption always4 bytes.

[Mike Mestnik]

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);
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/