I'm running NetBSD/SPARC 1.0 (final release; not 1.0A/-current).  "xbiff" is
not working for me, because getlogin() is returning "root" instead of "earle".

netbsd4me:1:255 % whoami
earle

netbsd4me:1:256 % who am i
earle    ttyp2   Dec 15 16:52   (:0.0)

Yet we have

netbsd4me:1:257 % logname
root

Doh!

("logname" does little else but parrot what getlogin() returns - oh, btw, the
 logname(1) man page mentions "getlogin(3)" instead of "getlogin(2)" ... )

The only explanation I can think of is that I logged in from "xdm" and not
from a standard login, and I don't have any login shell windows (i.e., no
"xterm -ls" windows).  The only things that do a "setlogin()" are "init",
"rshd" and "login", so I assume the initial setlogin("root") that "init" does
is still lying around, inherited across all of its child processes if no
one else does a setlogin().  (And gee, what do you know, no logins since I
last rebooted and got on via "xdm".)

This begs the obvious question, why isn't this field - i.e., the "s_login"
field in the per-process session structure - being set to NULL?

I don't know what the proper fix is, but it seems like a process which becomes
a new session leader should default to NULL'ing out the s_login field, since
it looks like most programs pretty much know what to do if getlogin() returns
NULL (i.e., try $LOGNAME, or try getpwuid(getuid()) if all else fails).
(Then again, several programs think that getlogin() returning NULL is an error
 and they'd better tell you about it, with an errno to boot (-: )

On the other hand, I'm willing to listen to arguments that "xdm" should be
doing the setlogin(), either internally or via an external program; what do
all you XFree86-using folks think?

Anyway, I'm throwing this out because it seems like a bug but maybe I'm
unaware of some potential side issue with other ramifications.

	- Greg