On Thu, 13 Sep 2001, Nalin Dahyabhai wrote: > It surprised me, too, but I couldn't find anything in the specifications > that mentioned the value of the pointer when the call fails. But anyhow. At the very least, there's a bug in the glibc documentation for claiming that the pointer /will/ be set to NULL. >> Seems to trade reentrancy problems in the system as a whole for reentrancy >> problems within the modules. I'd rather that each function/module that's a >> consumer of getpwnam_r() be expected to keep track of its own buffers and free >> them when necessary. > I'd prefer just the opposite. Expecting each module to handle the ERANGE > error independently is going to require large-scale changes, and I'd > rather that the logic to do so be put in one place to avoid the need to > change similar code in numerous places in the future if something is found > to be incorrect in the implementation. But if we don't do this, we're no closer to having thread-safe modules, even on systems that provide the necessary libc functions. I don't particularly /like/ needing to maintain the code in a dozen places, but I don't see any other way to solve this particular problem. > > If any wrappers are to be used, it should be to provide a getpwnam_r() > > work-alike for systems that lack this function call. This would minimize (but > > of course, not eliminate) race conditions surrounding the use of these static > > buffers. Insert a semaphore locking mechanism too, if you like. > This still destroys the contents of the buffer used by libc (which may > still be referenced by the calling application), so I don't think we'd > gain anything doing things this way. In the case where the calling application is expecting the buffer to not change, you're correct; that problem can only be fixed by fixing the applications that are making broken assumptions. It may alleviate some of the pain and suffering that results from running threaded apps on systems that don't have a thread-safe libc. But if it's not worth it to provide a wrapper, no worries; I'm not /overly/ concerned about vendors whose OSes don't include a sane libc to begin with. > It also doesn't copy over the pw_uid and pw_gid members of the passwd struct > being used. Whoops... oversight on my part. Consider those two lines inserted in red. :) Steve Langasek postmodern programmer
