Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!mit-eddie!husc6!ut-sally!std-unix
From: std-unix@ut-sally.UUCP
Newsgroups: mod.std.unix
Subject: Re: node name
Message-ID: <6977@ut-sally.UUCP>
Date: Wed, 28-Jan-87 12:11:43 EST
Article-I.D.: ut-sally.6977
Posted: Wed Jan 28 12:11:43 1987
Date-Received: Thu, 29-Jan-87 06:27:54 EST
References: <6788@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 48
Approved: jsq@sally.utexas.edu

From: seismo!gatech!hpcnof!hpfcla!hpfcdc!rml (Bob Lenk)
Date: Thu, 8 Jan 87 20:20:47 mst

> From: cbosgd!mark@seismo.css.gov (Mark Horton)
> 
> 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.

Since the publication of the trial use standard, the working group has
agreed to drop the constant SYS_NMLN and any requirement that all
five fields be the same length.  All fields are now specified simply
as null-terminated character arrays.  Increasing the length can still
cause binary compatibility problems, but there are (ugly) ways of
dealing with binary compatibility.

> I am also unaware of any application that makes use of the other four
> fields.

I can imagine applications using the fields in some type of reports,
but I don't know of any portable applications which use them, or of
any strong reason why they are needed.

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

If we use such an approach, we still need to specify a symbolic constant
(in <limits.h>) for the maximum length of a hostname on an
implementation, so that applications don't need to deal with having
truncated names returned to them.  Uname handles this by the inclusion
of the string within a structure.  Given that, the only difference from
uname is the existence of other fields.  For binary compatibilty, I
don't see much difference between an implementation having two calls
both called "uname" or one called "uname" and the other called
"gethostname", which return names of different lengths.

		Bob Lenk
		{ihnp4, hplabs}!hpfcla!rml

Volume-Number: Volume 9, Number 30