cvs commit: src/lib/libc/gen arc4random.c

[Brian F. Feldman]

David Schultz <das at FreeBSD.ORG> wrote:
> On Wed, Mar 24, 2004, Brian F. Feldman wrote:
> > > On Wed, 24 Mar 2004, David Schultz wrote:
> > > 
> > > > >   Add locking so that arc4random(3) functions are all reentrant for
> > > > >   pthreads.
> > > >
> > > > I think you mean thread-safe, not reentrant.  Also:
> [...]
> > There's no reason to make a distinction.  Quoth the OED: 
> > "b. Computers. Of, pertaining to, or designating a program or
> > subprogram which may be called or entered many times concurrently
> > from one or several programs without alteration of the results
> > obtained from any one execution."
> 
> Some people use ``reentrant'' to convey a stronger notion than
> ``thread safe''.  Specifically, reentrancy implies that multiple
> invocations of the function can execute correctly in parallel,
> rather than having a big lock around the whole thing.  But in this
> case, you're right that there's no need to make a distinction, and
> it was silly of me to mention it.

Yeah, whether the code is actually entirely thread-independent or utilizes 
mutual exclusion to achieve that effect is probably something we should also 
document.

> > Agreed.  We should be providing reentrant interfaces except where explicitly 
> > unable to do so, run-time cost not being the primary concern.  That said, 
> > the man pages for all non-reentrant interfaces should be annotated as such.
> > The submitter has hinted that he may compile a full list of all of those :-)
> 
> That would be great!  For all POSIX functions, there's already a
> list of non-thread-safe functions at:
> http://www.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_09.html
> For most of these, e.g. gethostbyname(), it's clear that thread
> safety is impossible, so it isn't even necessary to document the
> fact.  But for functions such as arc4random(), I think it's a fair
> question whether thread-safety is provided or not; that's why I
> brought it up.

Well, according to POSIX, random(3) is supposed to be thread-safe in the 
same manner -- shared data between all threads.  Unfortunately, since ours 
does not provide that ability transparently, it's certainly not pthreads-
compliant.  Since arc4random(3) is meant as mostly a much stronger 
replacement for random(3), it seems right to give it the same semantics.
Here's a cursory list of "most of" the files in libc that are unsafe.  I 
didn't even try to look for static non-globals and non-static globals, so 
there's undoubtedly some of every category missing.

posix1e/mac.c
gen/fstab.c
gen/getcap.c
gen/getgrent.c
gen/getnetgrent.c
gen/getpwent.c
gen/getpwent.c
gen/getttyent.c
gen/getusershell.c
gen/getvfsent.c
gen/syslog.c
gen/readpassphrase.c
locale/setlocale.c
locale/lmessages.c
locale/lmonetary.c
locale/lnumeric.c
net/gethostbydns.c
net/gethostbyht.c
net/gethostbynis.c
net/getnetbydns.c
net/getnetbyht.c
net/getprotoent.c
net/getservent.c
net/hesiod.c
net/gethostnamadr.c
net/nsparser.y
rpc/auth_time.c
rpc/clnt_perror.c
rpc/clnt_simple.c
rpc/getnetconfig.c
rpc/getrpcent.c
rpc/key_call.c
rpc/rpcdname.c
rpc/svc_auth_des.c
rpc/svc_auth.c
rpc/clnt_dg.c
rpc/rpcb_clnt.c
stdlib/rand.c
stdlib/random.c
stdlib/hcreate.c
stdlib/getopt_long.c
stdtime/timelocal.c
yp/yplib.c

This is more difficult because of the sheer abundance of non-const constants 
in use, but is probably mostly accurate.

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\