Larry Rosenman wrote: > > Where does it say that you have to use getpwuid_r() to be thread safe? > > I don't see any mention in the docs. It does say about getpwuid: > > > > For getpwent, getpwuid, getpwnam, setpwent, endpwent, and > > fgetpwent, all information is contained in a static area, so it must be > > copied if it is to be > > > > but that in itself doesn't mean it isn't thread safe. If you are not > > sure, would you write a little thread program to test if it works if two > > threads try it at the same time. > I only have a UP box. > > Since the _r version uses OUR OWN buffer, it is safer to use > the _r version. > > Since we do NOT have the _r alternative for strerror and > gethostbyname, that's the best we can do.
Uh, that's not the logic I use. I have some *_r functions on BSD/OS, but the normal libc functions are thread-safe, so I just use those. I think I have the *_r functions because the standards require them to exist, not because they are required for thread-safety, and like Unixware, I have some of them, but not others (no strerror_r). Because Unixware is similar in that it has some *_r functions and not others, I want to know if getpwuid_r() is required. gethostbyname() also returns data from a static area. Why is that thread-safe on Unixware and getpwuid() is not? My guess is that both are thread-safe but some software requires getpwuid_r() so they added it. Again, on those OS's, it is better to just use the libc versions. "Safer" isn't an issue. Either it is safe or unsafe. I also don't care about locking overhead in the libc versions of these functions. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
