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 pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073