Xref: utzoo comp.mail.mush:609 comp.unix.questions:20651 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!decwrl!ogicse!schaefer From: schaefer@ogicse.ogi.edu (Barton E. Schaefer) Newsgroups: comp.mail.mush,comp.unix.questions Subject: Re: 7.0 & Mt. Xinu's getpwuid() Message-ID: <8077@ogicse.ogi.edu> Date: 17 Mar 90 04:50:55 GMT References: <11725@thor.acc.stolaf.edu> Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR Lines: 36 In article <11725@thor.acc.stolaf.edu> fritchie@thor.acc.stolaf.edu (Scott Fritchie; Systems Programmer) writes: } Greetings Net-Land, } } We're running 4.3 More/BSD with NFS from Mt. Xinu on 2 VAX 11/780's. } In init.c:init(), the call to getpwuid() gets stuck/never returns. } Poking around the code for the C library, I've found that an RPC call } within libc/yp/yp_match.c:yp_match() gets a bad exit status, so } yp_match() sleeps for a few seconds and tries again. Unfortunately, the } RPC call never succeeds, so the function never exits. The problem isn't getpwuid() itself, it's the combination with getuid(). I checked the Mt. Xinu man pages and /usr/include/{sys/types.h,pwd.h} files and discovered: typedef u_short uid_t; The man page says to declare: extern uid_t getuid(); but of course getpwuid() expects an int as argument, so it's throwing an invalid uid around. This doesn't cause any problems, apparently, unless you are running yp (which we aren't). You'll have to add a correct declaration for getuid() somewhere, and cast the call in the argument of getpwuid() to int. How the heck is one supposed to know how to portably declare things like getuid()? I presume uid_t is POSIX-compliant, but how do you detect at compile time that such a typedef exists? (And why the devil didn't Xinu use the *same* type as the argument to getpwuid()?) -- Bart Schaefer "EARTH: Surrender IMMEDIATELY or we PICKLE DAN QUAYLE" "THPPFT!" schaefer@cse.ogi.edu (used to be cse.ogc.edu)