[Xorp-cvs] XORP cvs commit: xorp/libxorp

[Pavlin Radoslavov]

> > I was thinking about trivial work-around in the code itself like:
> > 
> >     unsigned long junk = 0;
> >     unsigned long junk_seed[2];
> > 
> >     junk = junk_seed[1];
> > 
> > 
> > What OS and compiler version are you using?
> > I have FreeBSD-7.0 (amd64) with the following compiler version
> > and the original code was compiling for me without a warning:
> > 
> > gcc (GCC) 4.2.1 20070719  [FreeBSD]
> 
> That's still referencing un-init memory (which is what you
> are trying to do, after all).  Whenever someone fixes the compiler
> (or uses something to detect bogus memory accesses),
> it will break again.

I don't have the environment to trigger the warning that Bruce saw
so I can play a bit with this, but even if the compiler complains
about the uninitialized junk_seed, using something like the
following might pacify it:

  junk_seed[0] = 0;

The idea is that with an array we can leave some uninitialized
holes, and I doubt that even future versions of the compilers are
going to track the initialization of all elements in an array.

> Maybe instead just use the low-order bits of gettimeofday
> by itself?  Surely that is random enough by itself?

This is relatively random (as relative as time itself :)
The idea is to add a low-complexity solution to get a bit better
randomness.

Anyway, I think we are spending too much time about a small issue.
Bruce, please try the array-with-a-hole work-around and see whether
it pacifies your compiler.

Thanks,
Pavlin