"Christopher J. Ruwe" <c...@cruwe.de> wrote: > On Sat, 22 Oct 2011 16:45:08 +0200 > Fabian Keil <freebsd-lis...@fabiankeil.de> wrote: > > > "Christopher J. Ruwe" <c...@cruwe.de> wrote: > > > > > On Fri, 21 Oct 2011 18:53:33 +0200 > > > "Christopher J. Ruwe" <c...@cruwe.de> wrote:
> > > As I stil do not know why the latter variant of my code worked and > > > the former does not, I would still appreciate any comment or > > > explanation which would help me understanding GETPWNAM and getpwnam. > > > > I'm not familiar with the code you're working with, > > but according to the man page getpwnam() isn't thread > > safe so you probably shouldn't mess with the returned > > pointer in the first place and only treat the one > > returned by the last call as valid. > > > > Did you try using getpwnam_r() instead? > You are quite right, GETPWNAM() is a macro to getpwnam(), which is not > thread safe. GETPWNAM() is called throughout the code of pw and pw > itself is not threaded, so it should not matter whether the functions > called are thread-safe or not. I am not completely sure on my last > statement though. Do you have other experience regarding this topic? My point is that if getpwnam() isn't thread safe because separate calls are using the same static buffer to return their result (which I didn't verify), and you do something like: pwd = GETPWNAM(...) [...] trgpwd = GETPWNAM(...) pwd->pw_uid = (uid_t) (trgpwd->pw_uid); the second getpwnam() call is going to reuse the memory pointed to by pwd. While I assume your intention was to only change pwd->pw_uid, the second getpwnam() call already had the side effect of overwriting all the other members as well. This would happen in a single-threaded application as well. Fabian
signature.asc
Description: PGP signature
