[PATCH 1/2] uname.2: fix standard reference wording

[PATCH 1/2] uname.2: fix standard reference wording

[наб]

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]

Issue 6:
    IEEE Std 1003.1-2001/Cor 2-2004, item XBD/TC2/D6/27 is applied,
changing the description of nodename within the utsname structure from
``an implementation-defined communications network'' to
``the communications network to which this node is attached, if any''.

Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
 man2/uname.2 | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/man2/uname.2 b/man2/uname.2
index 94c9c951a..b43f5d8d6 100644
--- a/man2/uname.2
+++ b/man2/uname.2
@@ -29,8 +29,8 @@ struct is defined in
 .EX
 struct utsname {
     char sysname[];    /* Operating system name (e.g., "Linux") */
-    char nodename[];   /* Name within "some implementation\-defined
-                          network" */
+    char nodename[];   /* Name within communications network
+                          to which the node is attached, if any */
     char release[];    /* Operating system release
                           (e.g., "2.6.28") */
     char version[];    /* Operating system version */
@@ -73,9 +73,10 @@ So, four of the fields of the struct are meaningful.
 On the other hand, the field
 .I nodename
 is meaningless:
-it gives the name of the present machine in some undefined
-network, but typically machines are in more than one network
-and have several names.
+it gives the name of the present machine in some "the" network
+to which it's attached,
+but typically machines are in more than one network
+and have several names by which they're reachable.
 Moreover, the kernel has no way of knowing
 about such things, so it has to be told what to answer here.
 The same holds for the additional
-- 
2.30.2


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH 2/2] uname.2: deweirdify

[наб]

[-- Attachment #1: Type: text/plain, Size: 4491 bytes --]

The NOTES were not only weirdly reductionist, but also highly
opinionated in the wrong direction.

Yes, it's a syscall in SysIII; not in 4.4BSD.
Well, in general, it exists in 4.4BSD for obvious conformace reasons.
No, it doesn't "know" (and if it does, that's not relevant),
historically and practically this is the broad CPU/machine type
(compare SunOS 3 mach => SysVr4 uname -p (=> SunOS 5 => NetBSD),
 which is the actual CPU model (usually)).
Everywhere, ex def., the nodename is what the BSD calls the hostname.
"No standard" also speaks of sethostname(), so.
Historical precedent (i.e. all implementations, save *maybe* for weirdo
XENIX, who cares about weirdo XENIX) defines the hostname to be uname -n
(indeed, SVr3 uname -S sets /both/ nodename /and/ sysname!
 that's not relevant here;
 SunOS gets it from the network (unless configured manually)).
Someone clearly cited SysVr4's "Internet hostnames" comment w/o credit;
fix that.
8-byte truncation is really quite secondary here (indeed, that's what
 SysVr4 does for pre-SysVr4 uname() callers that haven't been rebuilt.
 you will never encounter it).
The hostname is not meaningless, obviously??
Also fix machine to say "hardware type", like the standard;
"hardware identifier" would be hostid. I wrote six seething pages about
hostid, and machine is /not/ hostid.

Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
Here's a preprint of uname history (3.3 pages):
  https://twitter.com/nabijaczleweli/status/1537013517257265152
and the 6 scathing pages:
  https://twitter.com/nabijaczleweli/status/1531611680639225863

 man2/uname.2 | 49 ++++++++++++-------------------------------------
 1 file changed, 12 insertions(+), 37 deletions(-)

diff --git a/man2/uname.2 b/man2/uname.2
index b43f5d8d6..b0da6270b 100644
--- a/man2/uname.2
+++ b/man2/uname.2
@@ -34,7 +34,7 @@ struct utsname {
     char release[];    /* Operating system release
                           (e.g., "2.6.28") */
     char version[];    /* Operating system version */
-    char machine[];    /* Hardware identifier */
+    char machine[];    /* Hardware type identifier */
 #ifdef _GNU_SOURCE
     char domainname[]; /* NIS or YP domain name */
 #endif
@@ -57,49 +57,23 @@ is set to indicate the error.
 .I buf
 is not valid.
 .SH CONFORMING TO
-POSIX.1-2001, POSIX.1-2008, SVr4.
-There is no
-.BR uname ()
-call in 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, SVr4, 4.4BSD.
 .PP
 The
 .I domainname
 member (the NIS or YP domain name) is a GNU extension.
 .SH NOTES
-This is a system call, and the operating system presumably knows
-its name, release, and version.
-It also knows what hardware it runs on.
-So, four of the fields of the struct are meaningful.
-On the other hand, the field
+The kernel has the name, release, version, and supported machine type built in.
+Conversely, the
 .I nodename
-is meaningless:
-it gives the name of the present machine in some "the" network
-to which it's attached,
-but typically machines are in more than one network
-and have several names by which they're reachable.
-Moreover, the kernel has no way of knowing
-about such things, so it has to be told what to answer here.
-The same holds for the additional
+field is configured by the administrator to match the network
+(this is what the BSD historically calls the "hostname",
+and is set via
+.BR sethostname (2)).
+Similarly, the
 .I domainname
-field.
-.PP
-To this end, Linux uses the system calls
-.BR sethostname (2)
-and
+field is set via
 .BR setdomainname (2).
-Note that there is no standard that says that the hostname set by
-.BR sethostname (2)
-is the same string as the
-.I nodename
-field of the struct returned by
-.BR uname ()
-(indeed, some systems allow a 256-byte hostname and an 8-byte nodename),
-but this is true on Linux.
-The same holds for
-.BR setdomainname (2)
-and the
-.I domainname
-field.
 .PP
 The length of the fields in the struct varies.
 Some operating systems
@@ -114,7 +88,8 @@ or
 .BR _UTSNAME_LENGTH .
 Clearly, it is a bad
 idea to use any of these constants; just use sizeof(...).
-Often 257 is chosen in order to have room for an internet hostname.
+SVr4 uses 257, "to support Internet hostnames"
+\(em this is the largest value likely to be encountered in the wild.
 .PP
 Part of the utsname information is also accessible via
 .IR /proc/sys/kernel/ { ostype ,
-- 
2.30.2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 1/2] uname.2: fix standard reference wording

[Stefan Puiu]

Hi Наб,

On Wed, Jun 15, 2022 at 1:15 PM наб <nabijaczleweli@nabijaczleweli.xyz> wrote:
>
> Issue 6:
>     IEEE Std 1003.1-2001/Cor 2-2004, item XBD/TC2/D6/27 is applied,
> changing the description of nodename within the utsname structure from
> ``an implementation-defined communications network'' to
> ``the communications network to which this node is attached, if any''.
>
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
> ---
>  man2/uname.2 | 11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/man2/uname.2 b/man2/uname.2
> index 94c9c951a..b43f5d8d6 100644
> --- a/man2/uname.2
> +++ b/man2/uname.2
> @@ -29,8 +29,8 @@ struct is defined in
>  .EX
>  struct utsname {
>      char sysname[];    /* Operating system name (e.g., "Linux") */
> -    char nodename[];   /* Name within "some implementation\-defined
> -                          network" */
> +    char nodename[];   /* Name within communications network
> +                          to which the node is attached, if any */
>      char release[];    /* Operating system release
>                            (e.g., "2.6.28") */
>      char version[];    /* Operating system version */
> @@ -73,9 +73,10 @@ So, four of the fields of the struct are meaningful.
>  On the other hand, the field
>  .I nodename
>  is meaningless:
> -it gives the name of the present machine in some undefined
> -network, but typically machines are in more than one network
> -and have several names.
> +it gives the name of the present machine in some "the" network

Maybe "in one network" sounds better here?

> +to which it's attached,
> +but typically machines are in more than one network
> +and have several names by which they're reachable.

I'm not sure the use case of many networks and many names is typical,
though it is common. Maybe we can rephrase this to "Note the machine
might sit in more than one network and have several names"?

Thanks,
Stefan.

>  Moreover, the kernel has no way of knowing
>  about such things, so it has to be told what to answer here.
>  The same holds for the additional
> --
> 2.30.2
>

Re: [PATCH 1/2] uname.2: fix standard reference wording

[наб]

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

Hi!

On Wed, Jun 15, 2022 at 02:58:27PM +0300, Stefan Puiu wrote:
> On Wed, Jun 15, 2022 at 1:15 PM наб <nabijaczleweli@nabijaczleweli.xyz> wrote:
> > @@ -73,9 +73,10 @@ So, four of the fields of the struct are meaningful.
> >  On the other hand, the field
> >  .I nodename
> >  is meaningless:
> > -it gives the name of the present machine in some undefined
> > -network, but typically machines are in more than one network
> > -and have several names.
> > +it gives the name of the present machine in some "the" network
> 
> Maybe "in one network" sounds better here?

Typo! This was supposed to be "some network". I've updated this locally
but 2/2 replaces this line, so not resending (yet).

> > +to which it's attached,
> > +but typically machines are in more than one network
> > +and have several names by which they're reachable.
> 
> I'm not sure the use case of many networks and many names is typical,
> though it is common. Maybe we can rephrase this to "Note the machine
> might sit in more than one network and have several names"?

It's 100% the case on all systems; your machine is reachable as both
$(uname -n) and localhost (and, likely, $(uname -n).your.FQDN, and
probably localhost6).

localhost (and localhost6) is routed through a different network
(obviously your LAN isn't 127/8;
 the addressof localhost == addressof $(uname -n) 4.2BSDism
 has died with 4.3BSD)
and /through a different NIC/
(the lo prefix dates back to at least 4.2BSD).

Also: a machine may only have one name (well, ex def., but also because
what other nomenclatural facility beside uname -n is there? you could
make the case for SVr3 uname -S that also wrote to sysname,
but that's an abuse, and forbidden by the standard).
That it's /reachable/ by multiple names doesn't change its utsname.

I still think that as a small wording-fixup diff this diff stands,
and the larger rewrite in 2/2 avoids this issue completely:
> Conversely, the nodename field is configured by the administrator to
> match the network (this is what the BSD historically calls the
> "hostname", and is set via sethostname(2)).

Best,
наб

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 1/2] uname.2: fix standard reference wording

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2009 bytes --]

Hi наб,

On 6/15/22 12:04, наб wrote:
> Issue 6:
>      IEEE Std 1003.1-2001/Cor 2-2004, item XBD/TC2/D6/27 is applied,
> changing the description of nodename within the utsname structure from
> ``an implementation-defined communications network'' to
> ``the communications network to which this node is attached, if any''.
> 
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
> ---
>   man2/uname.2 | 11 ++++++-----
>   1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/man2/uname.2 b/man2/uname.2
> index 94c9c951a..b43f5d8d6 100644
> --- a/man2/uname.2
> +++ b/man2/uname.2
> @@ -29,8 +29,8 @@ struct is defined in
>   .EX
>   struct utsname {
>       char sysname[];    /* Operating system name (e.g., "Linux") */
> -    char nodename[];   /* Name within "some implementation\-defined
> -                          network" */
> +    char nodename[];   /* Name within communications network
> +                          to which the node is attached, if any */
>       char release[];    /* Operating system release
>                             (e.g., "2.6.28") */
>       char version[];    /* Operating system version */
> @@ -73,9 +73,10 @@ So, four of the fields of the struct are meaningful.
>   On the other hand, the field
>   .I nodename
>   is meaningless:
> -it gives the name of the present machine in some undefined
> -network, but typically machines are in more than one network
> -and have several names.
> +it gives the name of the present machine in some "the" network

That reads a bit weird.  Is it a typo, or is it intended?

Regards,

Alex

> +to which it's attached,
> +but typically machines are in more than one network
> +and have several names by which they're reachable.
>   Moreover, the kernel has no way of knowing
>   about such things, so it has to be told what to answer here.
>   The same holds for the additional

-- 
Alejandro Colomar
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 1/2] uname.2: fix standard reference wording

[наб]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

Hi!

On Wed, Jun 15, 2022 at 05:36:34PM +0200, Alejandro Colomar wrote:
> > @@ -73,9 +73,10 @@ So, four of the fields of the struct are meaningful.
> >   On the other hand, the field
> >   .I nodename
> >   is meaningless:
> > -it gives the name of the present machine in some undefined
> > -network, but typically machines are in more than one network
> > -and have several names.
> > +it gives the name of the present machine in some "the" network
> 
> That reads a bit weird.  Is it a typo, or is it intended?

Typo! Supposed to've been "in some network". Would you like a resend?
This line is replaced in 2/2.

Best,
наб

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 1/2] uname.2: fix standard reference wording

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 336 bytes --]

Hi!

On 6/15/22 18:29, наб wrote:
>> That reads a bit weird.  Is it a typo, or is it intended?
> 
> Typo! Supposed to've been "in some network". Would you like a resend?
> This line is replaced in 2/2.

Yes, please :)

Thanks,

Alex

> 
> Best,
> наб

-- 
Alejandro Colomar
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH v2 1/2] uname.2: fix standard reference wording

[наб]

[-- Attachment #1: Type: text/plain, Size: 1731 bytes --]

Issue 6:
    IEEE Std 1003.1-2001/Cor 2-2004, item XBD/TC2/D6/27 is applied,
changing the description of nodename within the utsname structure from
``an implementation-defined communications network'' to
``the communications network to which this node is attached, if any''.

Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
 man2/uname.2 | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/man2/uname.2 b/man2/uname.2
index 94c9c951a..fa991edfc 100644
--- a/man2/uname.2
+++ b/man2/uname.2
@@ -29,8 +29,8 @@ struct is defined in
 .EX
 struct utsname {
     char sysname[];    /* Operating system name (e.g., "Linux") */
-    char nodename[];   /* Name within "some implementation\-defined
-                          network" */
+    char nodename[];   /* Name within communications network
+                          to which the node is attached, if any */
     char release[];    /* Operating system release
                           (e.g., "2.6.28") */
     char version[];    /* Operating system version */
@@ -73,9 +73,10 @@ So, four of the fields of the struct are meaningful.
 On the other hand, the field
 .I nodename
 is meaningless:
-it gives the name of the present machine in some undefined
-network, but typically machines are in more than one network
-and have several names.
+it gives the name of the present machine in some network
+to which it's attached,
+but typically machines are in more than one network
+and have several names by which they're reachable.
 Moreover, the kernel has no way of knowing
 about such things, so it has to be told what to answer here.
 The same holds for the additional
-- 
2.30.2


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH v2 2/2] uname.2: deweirdify

[наб]

[-- Attachment #1: Type: text/plain, Size: 4265 bytes --]

The NOTES were not only weirdly reductionist, but also highly
opinionated in the wrong direction.

Yes, it's a syscall in SysIII; not in 4.4BSD.
Well, in general, it exists in 4.4BSD for obvious conformace reasons.
No, it doesn't "know" (and if it does, that's not relevant),
historically and practically this is the broad CPU/machine type
(compare uname -p on SysVr4 (=> SunOS 5 => NetBSD),
 which is the actual CPU model (usually)).
Everywhere, ex. def., the nodename is what the BSD calls the hostname.
"No standard" also speaks of sethostname(), so.
Historical precedent (i.e. all implementations, save *maybe* for weirdo
XENIX, who cares about weirdo XENIX) defines the hostname to be uname -n
(indeed, SVr3 uname -S sets /both/ nodename /and/ sysname!
 that's not relevant here;
 SunOS gets it from the network (unless configured manually)).
Someone clearly cited SysVr4's "Internet hostnames" comment w/o credit;
fix that.
8-byte truncation is really quite secondary here (indeed, that's what
 SysVr4 does for pre-SysVr4 uname() callers that haven't been rebuilt.
 you will never encounter it).
The hostname is not meaningless, obviously??
Also fix machine to say "hardware type", like the standard;
"hardware identifier" would be hostid. I wrote six seething pages about
hostid, and machine is /not/ hostid.

Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
 man2/uname.2 | 49 ++++++++++++-------------------------------------
 1 file changed, 12 insertions(+), 37 deletions(-)

diff --git a/man2/uname.2 b/man2/uname.2
index fa991edfc..b0da6270b 100644
--- a/man2/uname.2
+++ b/man2/uname.2
@@ -34,7 +34,7 @@ struct utsname {
     char release[];    /* Operating system release
                           (e.g., "2.6.28") */
     char version[];    /* Operating system version */
-    char machine[];    /* Hardware identifier */
+    char machine[];    /* Hardware type identifier */
 #ifdef _GNU_SOURCE
     char domainname[]; /* NIS or YP domain name */
 #endif
@@ -57,49 +57,23 @@ is set to indicate the error.
 .I buf
 is not valid.
 .SH CONFORMING TO
-POSIX.1-2001, POSIX.1-2008, SVr4.
-There is no
-.BR uname ()
-call in 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, SVr4, 4.4BSD.
 .PP
 The
 .I domainname
 member (the NIS or YP domain name) is a GNU extension.
 .SH NOTES
-This is a system call, and the operating system presumably knows
-its name, release, and version.
-It also knows what hardware it runs on.
-So, four of the fields of the struct are meaningful.
-On the other hand, the field
+The kernel has the name, release, version, and supported machine type built in.
+Conversely, the
 .I nodename
-is meaningless:
-it gives the name of the present machine in some network
-to which it's attached,
-but typically machines are in more than one network
-and have several names by which they're reachable.
-Moreover, the kernel has no way of knowing
-about such things, so it has to be told what to answer here.
-The same holds for the additional
+field is configured by the administrator to match the network
+(this is what the BSD historically calls the "hostname",
+and is set via
+.BR sethostname (2)).
+Similarly, the
 .I domainname
-field.
-.PP
-To this end, Linux uses the system calls
-.BR sethostname (2)
-and
+field is set via
 .BR setdomainname (2).
-Note that there is no standard that says that the hostname set by
-.BR sethostname (2)
-is the same string as the
-.I nodename
-field of the struct returned by
-.BR uname ()
-(indeed, some systems allow a 256-byte hostname and an 8-byte nodename),
-but this is true on Linux.
-The same holds for
-.BR setdomainname (2)
-and the
-.I domainname
-field.
 .PP
 The length of the fields in the struct varies.
 Some operating systems
@@ -114,7 +88,8 @@ or
 .BR _UTSNAME_LENGTH .
 Clearly, it is a bad
 idea to use any of these constants; just use sizeof(...).
-Often 257 is chosen in order to have room for an internet hostname.
+SVr4 uses 257, "to support Internet hostnames"
+\(em this is the largest value likely to be encountered in the wild.
 .PP
 Part of the utsname information is also accessible via
 .IR /proc/sys/kernel/ { ostype ,
-- 
2.30.2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 2/2] uname.2: deweirdify

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 4652 bytes --]

On 6/15/22 18:39, наб wrote:
> The NOTES were not only weirdly reductionist, but also highly
> opinionated in the wrong direction.
> 
> Yes, it's a syscall in SysIII; not in 4.4BSD.
> Well, in general, it exists in 4.4BSD for obvious conformace reasons.
> No, it doesn't "know" (and if it does, that's not relevant),
> historically and practically this is the broad CPU/machine type
> (compare uname -p on SysVr4 (=> SunOS 5 => NetBSD),
>   which is the actual CPU model (usually)).
> Everywhere, ex. def., the nodename is what the BSD calls the hostname.
> "No standard" also speaks of sethostname(), so.
> Historical precedent (i.e. all implementations, save *maybe* for weirdo
> XENIX, who cares about weirdo XENIX) defines the hostname to be uname -n
> (indeed, SVr3 uname -S sets /both/ nodename /and/ sysname!
>   that's not relevant here;
>   SunOS gets it from the network (unless configured manually)).
> Someone clearly cited SysVr4's "Internet hostnames" comment w/o credit;
> fix that.
> 8-byte truncation is really quite secondary here (indeed, that's what
>   SysVr4 does for pre-SysVr4 uname() callers that haven't been rebuilt.
>   you will never encounter it).
> The hostname is not meaningless, obviously??
> Also fix machine to say "hardware type", like the standard;
> "hardware identifier" would be hostid. I wrote six seething pages about
> hostid, and machine is /not/ hostid.
> 
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>

Both patches applied.

Thanks!

Alex

> ---
>   man2/uname.2 | 49 ++++++++++++-------------------------------------
>   1 file changed, 12 insertions(+), 37 deletions(-)
> 
> diff --git a/man2/uname.2 b/man2/uname.2
> index fa991edfc..b0da6270b 100644
> --- a/man2/uname.2
> +++ b/man2/uname.2
> @@ -34,7 +34,7 @@ struct utsname {
>       char release[];    /* Operating system release
>                             (e.g., "2.6.28") */
>       char version[];    /* Operating system version */
> -    char machine[];    /* Hardware identifier */
> +    char machine[];    /* Hardware type identifier */
>   #ifdef _GNU_SOURCE
>       char domainname[]; /* NIS or YP domain name */
>   #endif
> @@ -57,49 +57,23 @@ is set to indicate the error.
>   .I buf
>   is not valid.
>   .SH CONFORMING TO
> -POSIX.1-2001, POSIX.1-2008, SVr4.
> -There is no
> -.BR uname ()
> -call in 4.3BSD.
> +POSIX.1-2001, POSIX.1-2008, SVr4, 4.4BSD.
>   .PP
>   The
>   .I domainname
>   member (the NIS or YP domain name) is a GNU extension.
>   .SH NOTES
> -This is a system call, and the operating system presumably knows
> -its name, release, and version.
> -It also knows what hardware it runs on.
> -So, four of the fields of the struct are meaningful.
> -On the other hand, the field
> +The kernel has the name, release, version, and supported machine type built in.
> +Conversely, the
>   .I nodename
> -is meaningless:
> -it gives the name of the present machine in some network
> -to which it's attached,
> -but typically machines are in more than one network
> -and have several names by which they're reachable.
> -Moreover, the kernel has no way of knowing
> -about such things, so it has to be told what to answer here.
> -The same holds for the additional
> +field is configured by the administrator to match the network
> +(this is what the BSD historically calls the "hostname",
> +and is set via
> +.BR sethostname (2)).
> +Similarly, the
>   .I domainname
> -field.
> -.PP
> -To this end, Linux uses the system calls
> -.BR sethostname (2)
> -and
> +field is set via
>   .BR setdomainname (2).
> -Note that there is no standard that says that the hostname set by
> -.BR sethostname (2)
> -is the same string as the
> -.I nodename
> -field of the struct returned by
> -.BR uname ()
> -(indeed, some systems allow a 256-byte hostname and an 8-byte nodename),
> -but this is true on Linux.
> -The same holds for
> -.BR setdomainname (2)
> -and the
> -.I domainname
> -field.
>   .PP
>   The length of the fields in the struct varies.
>   Some operating systems
> @@ -114,7 +88,8 @@ or
>   .BR _UTSNAME_LENGTH .
>   Clearly, it is a bad
>   idea to use any of these constants; just use sizeof(...).
> -Often 257 is chosen in order to have room for an internet hostname.
> +SVr4 uses 257, "to support Internet hostnames"
> +\(em this is the largest value likely to be encountered in the wild.
>   .PP
>   Part of the utsname information is also accessible via
>   .IR /proc/sys/kernel/ { ostype ,

-- 
Alejandro Colomar
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]