'RELENG_3_3_0_RELEASE'.

This commit was manufactured to restore the state of the 3.3-RELEASE image.
Releases prior to 5.3-RELEASE are omitting the secure/ and crypto/ subdirs.

This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.

Boy, I'm glad we're not using sup anymore.  This update would have been
insane otherwise.

- getservent:
  o put _yp_check() proto under #ifdef YP where it belongs
  o local YP buffers should be YPMAXRECORD + 2 bytes long and should
    be NUL terminated after copying

- gethostbynis:
  o local YP buffer should be YPMAXRECORD + 2 bytes long

- getnetbynis:
  o local YP buffer should be YPMAXRECORD + 2 bytes long and should
    be NUL terminated after copying

- ether_addr:
  o local YP buffers should be YPMAXRECORD + 2 bytes long and should
    be NUL terminated after copying (in this case it's BUFSIZ + 2 bytes,
    but it happens that BUFSIZ == YPMAXRECORD.

- gethostbydns:
  o nuke stray 'return(NULL)' in __dns_getanswer() (harmless but looks silly)

These are 2.2 candidates. I will wait a few days to make sure these don't
break anything and then, if there are no objections, move them to the 2.2
branch.

and he said:

	The 3rd agrument is new; looks like it was part of the upgrade to
	a new BIND with some IPv6 support. The third argument here should be
	AF_INET. In order for it to be anything else, I'd have to add new
	NIS functions to support IPv6 lookups. I don't even know what those
	look like yet.

So there ya go, add AF_INET as the 3rd argument to the call.

Submitted-by: wpaul

broken. The translation from network number to ASCII string was not
working correctly (you would sometimes get things like 0.244.0.0 instead
of 244.0.0).

Also copied results of yp_match() to a static buffer for consistency
with gethostbynis.c.

Note: _getnetbynisaddr() chops off trailing .0's, i.e. 244.0.0 is
truncated to 244. By contrast, getnetbyht.c code (for local /etc/networks
lookups) leaves the traling .0's in place. This means that the NIS
and local file lookups will match different things when looking up the
same network number. I'm not sure which is the correct behavior. (I
think the DNS lookup code tries all combinations -- should the NIS
and local host lookup routines do that too?)