On Thu, Sep 13, 2001 at 02:26:18PM -0500, Steve Langasek wrote: > On Wed, 12 Sep 2001, Nalin Dahyabhai wrote: > > I tried this route, and discovered that if getpwnam_r fails, you have > > no guarantees about the value of the parameters you passed in (pwd > > may be unchanged, or it may point to the struct passwd, or to some > > other location), so it's probably better to do this: > > Hmm. I've never used any of these functions before, so I know only what's > found in libc.info. There, it's claimed that the pointer given as the last > argument will be set to NULL if the call fails, but if that doesn't stand up > to empirical testing, then I'll keep that in mind. 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. > 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. > 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. It also doesn't copy over the pw_uid and pw_gid members of the passwd struct being used. Nalin
