[Bug libc/3662] Implementation bugs in random_r and friends

["glibcbugs0000 at cneufeld dot ca" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From glibcbugs0000 at cneufeld dot ca  2009-11-25 14:50 -------
So, if I understand your objection, you feel that the random_r class of
functions is used for the internal implementation details of the non-reentrant
functions.  You feel that the internal details of random_data should not be
exposed to the users, and that only changes to documentation be used to address
the issues brought up in this bug report.

I am not trying to be difficult here, I'm trying to help.  I will write and
attach a patch that does the following:

1) Remove the documentation for srandom_r() because without an understanding of
the internal implementation of random_data there is literally no way to call
this function without segfaulting.  Instead I will note that this function is
for internal use only and must not be called by the user.

2) Document that initstate_r() must be given a static-duration buffer for its
second argument.  Also document that the previous value of the state information
is not returned by this function, as is currently claimed.

3) Document the way setstate_r() might be usable in the context of
initstate_r(), based on my reading of the source code.

Note that this patch will not fix the random_r.3 manpage, which will continue to
claim that srandom_r() is a usable function.


Here is what the patch will NOT do, but I'd like to record these thoughts
alongside this bug for future reference.  I suggest that if the random_data
structure were augmented with an array of length 256 appended to the end,
correctly aligned for integer access, that the srandom_r() function could be
rescued in a backward-compatible way by making 'state' point to this new
internal buffer.  The initstate_r() function could also be fixed up, still
backwardly compatible with older binaries, with the old state being returned in
the passed buffer.  Further, a random_data structure would now be a
self-contained object that could be written to disk and loaded at a later time,
unlike the current condition where the structure contains a pointer that points
outside itself, to a block of unknown length.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=3662

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.