In Message <20021226231735.GA6942@mewburn.net> ,
   Luke Mewburn <lukem@netbsd.org> wrote:

=>On Thu, Dec 26, 2002 at 08:42:03AM -0500, Gary Duzan wrote:
=>  | In Message <20021226125359.2A213B42C@cvs.netbsd.org> ,
=>  |    Luke Mewburn <lukem@netbsd.org> wrote:
=>  | 
=>  | =>
=>  | =>Module Name:	src
=>  | =>Committed By:	lukem
=>  | =>Date:		Thu Dec 26 12:53:59 UTC 2002
=>  | =>
=>  | =>Modified Files:
=>  | =>	src/lib/libwrap: hosts_access.c
=>  | =>
=>  | =>Log Message:
=>  | =>If we're going to replace strtok() with strtok_r(), and the caller of the
=>  | =>latter is invoked recursively, use static (instead of automatic) storage
=>  | =>for the "last" pointer so that we remember where we're up to ...
=>  | 
=>  |    Hmm. Doesn't this make libwrap itself less reentrant?
=>
=>Yes, probably.
=>
=>However, I'm not sure libwrap is reentrant anyway, given the fact that
=>it used to use strtok() until it was recently changed to strtok_r()
=>in our sources (so that the use of strtok() in libwrap wouldn't interfere
=>with an application's use of it).

   I suspected that might be the case. I also expect that someone
will likely want to make all these libraries reentrant eventually,
especially once we get nathanw_sa+pthreads...

=>I just did the quickest & least intrusive fix to give us back at least
=>the functionality we had before the code was changed from strtok() to
=>strtok_r()

   Fair enough. I figured it was worth mentioning, anyway.

=>
=>  | =>Fixes bug with hosts.deny rules such as "rpcbind: ALL EXCEPT some.domain".
=>  | 
=>  |    How about something like the attached, instead?
=>
=>If we're going to muck around with that, I'd rather just use strsep()
=>than strtok_r()...

   I just did the quickest & least complicated transformation of
the existing code to restore some reentrancy without introducing
the inherent risks of actually applying thought processes to the
problem.  :-)

					Gary Duzan