node name

[Moderator, John Quarterman]

From: cbosgd!mark at seismo.css.gov (Mark Horton)
Date: 4 Jan 87 21:19:54 GMT
Organization: AT&T Bell Laboratories, Columbus, Oh

I was just going through POSIX and noticed that the only mechanism
for determining the node name is uname (4.4.1.)  I think it's clear
that, while uname is adequate for UUCP, the 8 character limit on
the node name is inadequate for other networks, especially domain
networks such as the ARPANET, CSNET, and the UUCP Zone.  It won't
be adequate for OSI, either, although it isn't currently clear what
would be, since host names may not even be character strings in OSI.

While P.1003 does not restrict implementations to SYS_NMLN=9 (including
the null) it requires that all 5 fields support the full length.
I don't know of any way to increase SYS_NMLN while maintaining binary
compatibility with older programs, which is a typical requirement.

I am also unaware of any application that makes use of the other four
fields.  (Of course, as soon as I say that, several people will point
some out, but I don't know of a runtime use for those fields that is
sufficiently motivating to be included in POSIX.)  A similar feature
would be useful at compile time (predefined preprocessor variables to
allow conditional compilation based on the version) but the typical
program needs to make these decisions at compile time, not runtime.

Wouldn't it make more sense to standardize on a simple long character
string for the node name?  Assuming that OSI names can somehow be
encoded as character strings (a fairly safe assumption, I think)
this ought to handle all the cases.  The 4.2BSD gethostname function,
which passes the length of the buffer:
	gethostname(buffer, bufferlen)
	char *buffer;
	int bufferlen;
seems perfectly suited to this problem.

I believe that uname will have to be phased out in favor of a more
general mechanism over the next few years.  Why is it in the standard?

	Mark

Volume-Number: Volume 9, Number 12