Source-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/lib/libwrap



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

=>On Thu, Dec 26, 2002 at 08:42:03AM -0500, Gary Duzan wrote:
=>  | In Message <20021226125359.2A213B42C%cvs.netbsd.org@localhost> ,
=>  |    Luke Mewburn <lukem%netbsd.org@localhost> 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





Home | Main Index | Thread Index | Old Index