Some of you have encountered the bug that, when running on some machines,
lemacs doesn't recognize certain (other) host names.  I've isolated this
bug a little further, and it confuses me greatly, so I'm going to describe
what I know about it in hope that some of you have ideas, because I'm out.

If emacs is linked against Sun's libc.a, then the gethostbyname() routine
that is linked in is one that knows about YP (Yellow Pages, aka NIS) and
not DNS (Domain Name Service, the standard which Sun has reinvented.)

If you are running the emacs executable on machine A, with $DISPLAY set to
machine B, then the emacs running on machine A needs to resolve the name
"B" to an address.  It does this by calling gethostbyname().  Normally 
this consults the YP database.

Now here's the problem: if the *logged in user* is present in the local
/etc/passwd file on machine A (as opposed to, or in addition to, being in
the "passwd" YP database) then gethostbyname() will *not* attempt to use
the contents of the YP host database to resolve hostnames to addresses.

Suppose "B" is in the YP database and "B.FOO.COM" is registered in DNS.
Emacs will work if $DISPLAY points at "B.FOO.COM", but not "B".  B.FOO.COM
need not be in the local /etc/hosts file.

The rule seems to be that, if emacs manages to find the logged-in user
information by using the local /etc/passwd file (which I presume it checks
first) then it doesn't EVER consult YP for the "/etc/hosts" information.  But
it will consult DNS.  Puzzle out that incestuous relationship, why don't you.

Now, one might ask, why is this a problem for emacs and not for anything
else?  That's a very good question.

One of the things that emacs does early in its startup is call tzsetwall().
If this is not done, then the dumped emacs will always think that it is in
the timezone in which it was dumped.  calling tzsetwall() makes emacs
refresh its idea about what the local timezone is.  The man page says:

     tzset() uses the value of the environment variable TZ to set
     time  conversion  information used by localtime().  If TZ is
     absent from the environment, the an available  approximation
     to  local  wall  clock  time  is used by localtime().  If TZ
     appears in the environment but its value is a  null  string,
     Greenwich Mean Time is used; if TZ appears and begins with a
     slash, it is used as the absolute pathname  of  the  tzfile-
     format  (see  tzfile(5))  file  from  which to read the time
     conversion information; if TZ  appears  and  begins  with  a
     character other than a slash, it is used as a pathname rela-
     tive to a system time conversion information directory.

     tzsetwall() sets things up so that localtime()  returns  the
     best available approximation of local wall clock time.

I don't know what the difference between tzset() and tzsetwall() is, but they
both seem to have the same effect.  Which is: if a dumped emacs calls either
of these tz functions, then the passwd/hosts problem exhibits itself.  If
neither of these tz functions is called, then there is no problem.

This only happens from dumped emacses, so possibly it has something to do
with static data being overwritten, or corrupted malloc lists, or something.
In particular, it doesn't happen when one codes up the obvious trivial
testcase (linking it either statically or dynamically.)

This is baffling not only because I don't have the source to Sun's tz,
host, and passwd functions, but because I don't have even a clue what they
are actually trying to DO.  Why do the tz functions have anything to do
with the userid and host routines?  Since the man page gives no information
on how the tz routines figure out what timezone they are in, perhaps they
use YP to figure it out.  Who knows.

Linking with the GNU libc.a doesn't shed any light on this, because the GNU
libc.a doesn't know about YP at all, so it's a non-issue.

I don't remember the details any more, but I found that if I caused YP to
be consulted before the first call to tzsetwall() (I think by calling
getpwuid() or something explicitly) then the problem didn't manifest
itself.

You won't notice this bug happening if you don't use YP, or if you have
exactly the same information in the YP host database as is in the DNS host
database; many sites have short local aliases in YP but not DNS, and those
aliases will stop working if this problem rears its ugly head.

So, to reiterate, my understanding of this bug is: once tzsetwall() is
called, *IF* the logged-in user is in the local /etc/passwd file, then the
YP host database is not consulted.  One could interpret this as meaning
that if YP is not consulted to find out the current user name, etc, then it
won't be consulted for host names either.

I expect that this only a problem (in the current incarnation, anyway) when
emacs is running on a Sun; do any non-Sun machines use YP?

The output from `trace' is pretty unilluminating.

I'm wide open to suggestions.

	-- Jamie
x-gateway: rodan.UU.NET from bug-lucid-emacs to alt.lucid-emacs.bug; Fri, 11 Sep 1992 01:46:55 EDT
Date: Fri, 11 Sep 1992 13:44:56 +0730
From: franks%ntu.ac.sg@lucid.com (Frank Siebenlist)
Subject: mouse completion of "dot"-files
Newsgroups: alt.lucid-emacs.bug