7.0 & Mt. Xinu's getpwuid()

[Barton E. Schaefer]

In article <11725 at thor.acc.stolaf.edu> fritchie at 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 at cse.ogi.edu (used to be cse.ogc.edu)