Date: Sun, 13 Feb 2011 21:09:22 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Bruce Cran <brucec@FreeBSD.org> Cc: Garrett Wollman <wollman@csail.mit.edu>, freebsd-doc@FreeBSD.org, freebsd-standards@FreeBSD.org Subject: Re: docs/143472: gethostname(3) references undefined value: HOST_NAME_MAX Message-ID: <20110213203708.R1205@besplex.bde.org> In-Reply-To: <201102122318.17338.brucec@freebsd.org> References: <201102122116.p1CLGtJm051987@freefall.freebsd.org> <36a85352-9802-460b-b616-00cf9f9e502f@email.android.com> <201102122318.17338.brucec@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 12 Feb 2011, Bruce Cran wrote: > On Saturday 12 February 2011 22:17:16 Garrett Wollman wrote: > >> The Standard uses special typography to indicate these parameters; we >> should, too. > > Having done further reading on opengroup.org I realised that the brackets do > indicate that it's a value that can be obtained through sysconf(3). > > However, it's not especially clear to readers unfamiliar with the Standard, > and has confused people in the past - for example http://www.mail- > archive.com/bug-gnulib@gnu.org/msg14789.html . I wonder if there's a way we > can improve the documentation to make it clear that these values aren't > necessarily preprocessor definitions? o Use the braces in the thousands of places that they are needed instead of in only a few places. o Document them in intro.2 if not already. o Remove the compile-time constant values, especially for things like {OPEN_MAX} which were never constant in BSD, so that things break properly when variables are misspelled as constants It would be nauseating to expand {FOO_MAX} in the thousands of places where the limit might be variable. > I've attached a patch to sysconf(3) which adds documentation of > {HOST_NAME_MAX} and others. The patch also replaces "cpu" by "machine". But "machine" is similar to "cpu" and is identical with the CPU name in many contexts, e.g.: - the MACHINE make variable on i386 systems, er machines, is i386 - for uname(1): - uname -m gives the machine name, which is something like i386 - uname -p gives the machine processor name, which is also something like i386 - uname -n gives the system name, which is normally the host name So gethostname(2) returns a system name, not a machine name, according to the terminology of uname(1). POSIX doesn't use this terminology for gethostname() however. The host name can be anything you want, although other entities may want it to be what they want or what it was. Changing it from my fake internet domain name to i386 works here according to hostname(1). I didn't keep this setting for long or test it with other entities. The details of what uname -n returns are undocumented in in uname(1), but uname(3) and <sys/utsname.h> says that the struct member `nodename' contains the "Network [node] name". POSIX says that `nodename' contains the "name of this node within an implementation-defined communications network". But uname(1) is not required to print the same strings that struct utsname holds, except as en extension, since there are large unportabilities in this area. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110213203708.R1205>