The gethostbyname() routines in the C run-time libraries distributed
with SunOS 4.x *never* consult the DNS directly.  They use the NIS
hosts map or /etc/hosts if there is no NIS.

The recommended (by Sun, not by me) way to use the DNS is to
configure the NIS server to do DNS lookup in case it doesn't find
a host or IP address in the local NIS map.  This can be done by
hacking /var/yp/Makefile as documented in Sun's manuals.

Now many people want to avoid the overhead of NIS because all host
information is in the DNS anyway, so they follow the advice of the
Net and replace the gethost...() routines in the dynamic libc by
the BIND versions of these routines that use the resolver to query
the DNS nameserver directly.  These routines are distributed by
Sun in /usr/lib/libresolv.a library (but you can also use a newer
BIND version).

Jamie Zawinski writes:

> 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.)

Hmmm... not here.  It is true that most people who want to use DNS
for hostname resolution only change their dynamic libc, but I
think it is a good idea to keep the dynamic and static versions of
the library consistent; so I put the resolver routines into libc.a
as well (this is even easier than patching libc.so.x.y).

> 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.

As I said, Sun's gethostby...() routines don't know how to talk to
the DNS directly so this puzzles me.

> 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.)

Oh, I see.  Very good detective work! There's a known off-by-one
error in one of the tzset routines which causes the ninth byte of
an eight-byte buffer to be overwritten; maybe you are hitting this
bug? It was in SunOS 4.1 and 4.1.1 and fixed by official patch
100267-04 (and probably earlier versions).  I don't know whether
it has resurfaced in 4.1.2 or 4.1.3.  The bug's official name is:

	1038500  localtime or tzsetwall corrupts malloc space

And it was the reason for USE_SYSTEM_MALLOC in the SunOS 4.1
config files of GNU Emacs.  Sun's malloc() rounds up the buffer's
size so that the illegal access doesn't cause any harm.  It is
probably not easy to work around this bug in an elegant way
because the buffer is allocated by tzsetwall() rather than Emacs.

> 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?

Yes! NIS is part of ONC (Open Network Computing) and many vendors
other than Sun use it: Hewlett-Packard, Silicon Graphics, and
Digital all ship it with their workstation OSes (that's all brands
I could check).
-- 
Simon.