Re: Clean up glibc manual references to "GNU system" (bug 6911)

[Roland McGrath <roland at hack dot frob dot com>]

> -On non-GNU systems, almost any system call can return @code{EFAULT} if
> +On non-@gnuhurdsystems{}, almost any system call can return @code{EFAULT} if

I don't think we should use these macros in constructions like this,
where the grammatical structure depends closely on the exact expansion.
Instead, say, "Except on @gnuhurdsystems{}, ..."

> -codes can't occur on the GNU system, but they can occur using @theglibc{}
> +codes can't occur on @gnuhurdsystems{}, but they can occur using @theglibc{}
>  on other systems.

This is a general and vague statement and probably doesn't apply only to
the Hurd.  I think @gnusystems{} is a better fit here.

>  @code{strerror} and @code{perror} produce the exact same message for any
> -given error code; the precise text varies from system to system.  On the
> -GNU system, the messages are fairly short; there are no multi-line
> +given error code; the precise text varies from system to system.  On
> +@gnusystems{}, the messages are fairly short; there are no multi-line
>  messages or embedded newlines.  Each error message begins with a capital
>  letter and does not include any terminating punctuation.

perror text is entirely under the control of libc, and I think we'd stick
to these guidelines for ports to non-GNU systems.  So I think @theglibc{}
is the better fit here.

>  @noindent
>  However, it is better to use @code{getumask} if you just want to read
> -the mask value, because it is reentrant (at least if you use the GNU
> -operating system).
> +the mask value, because it is reentrant (at least on @gnuhurdsystems{}).
>  @end deftypefun

In fact, getumask is only available at all on the Hurd.
So I think this should just be reworded entirely.

>  where you want @theglibc{} installed.  This defaults to @file{/usr/local},
>  but the normal setting to install as the standard system library is
>  @samp{--prefix=/usr} for GNU/Linux systems and @samp{--prefix=} (an
> -empty prefix) for GNU/Hurd systems.
> +empty prefix) for @gnuhurdsystems{}.

This cases suggests we should have a @gnulinuxsystems{} too.
(So we can redefine it to "Lignux", I guess. ;-)
But really just for parity and in case we decide to use
some different typographical convention like @sc{GNU} or something.)

>  @Theglibc{}, described in this document, defines all of the
>  library functions that are specified by the @w{ISO C} standard, as well as
>  additional features specific to POSIX and other derivatives of the Unix
> -operating system, and extensions specific to the GNU system.
> +operating system, and extensions specific to @gnuhurdsystems{}.

There are also extensions specific to only Linux-based systems
and extensions specific to all GNU systems.  It doesn't need to
be very exact here, I think, so @gnusystems{} seems best.

> -support streams, but non-GNU systems may not support file descriptors at
> +support streams, but non-@gnusystems{} may not support file descriptors at

Reword to avoid a prefix on the macro.

>  There are two reasons why it can be important for you to be aware of
> @@ -389,7 +389,7 @@ some operating systems and not by others.
>  The POSIX.1 standard allows implementations to put additional
>  restrictions on file name syntax, concerning what characters are
>  permitted in file names and on the length of file name and file name
> -component strings.  However, in the GNU system, you do not need to worry
> +component strings.  However, on @gnuhurdsystems{}, you do not need to worry
>  about these restrictions; any character except the null character is
>  permitted in a file name string, and there are no limits on the length
>  of file name strings.

This needs rewording.  The character set issue applies to all GNU systems,
though the length issue only to the Hurd.

> @@ -687,7 +687,7 @@ file offset is not valid.  A file offset is invalid.
>  @item ESPIPE
>  The @var{filedes} corresponds to an object that cannot be positioned,
>  such as a pipe, FIFO or terminal device.  (POSIX.1 specifies this error
> -only for pipes and FIFOs, but in the GNU system, you always get
> +only for pipes and FIFOs, but on @gnulinuxhurdsystems{}, you always get
>  @code{ESPIPE} if the object is not seekable.)
>  @end table

I think this is a @gnusystems{} case.

> -In the GNU system and 4.4 BSD, opening a file never makes it the
> +On @gnuhurdsystems{} and 4.4 BSD, opening a file never makes it the
>  controlling terminal and @code{O_NOCTTY} is zero.  However, other
>  systems may use a nonzero value for @code{O_NOCTTY} and set the
>  controlling terminal when you open a file that is a terminal device; so

You can say this is outside the scope of this change.  But since we know
Linux does have O_NOCTTY it seems appropriate to say so explicitly here
rather than just include in the underspecified "other systems may".

> -Some non-GNU systems fail to support @code{alloca}, so it is less
> +Some non-@gnusystems{} fail to support @code{alloca}, so it is less

Reword to avoid a prefix on the macro.

> -In the GNU system, you can also inquire about a particular child process
> +On @gnuhurdsystems{}, you can also inquire about a particular child process
>  by specifying its process ID.

This statement is false, so just remove the paragraph.

> -In the GNU system, non-null pointers are printed as unsigned integers,
> +In @theglibc{}, non-null pointers are printed as unsigned integers,
>  as if a @samp{%#x} conversion were used.  Null pointers print as
>  @samp{(nil)}.  (Pointers might print differently in other systems.)

While you're here, it's (null) not (nil).

> @@ -4578,7 +4578,7 @@ This function is declared in the @file{stdio_ext.h} header.
>  been known to be so thoroughly fixated on line-oriented input and output
>  that flushing a line buffered stream causes a newline to be written!
>  Fortunately, this ``feature'' seems to be becoming less common.  You do
> -not need to worry about this in the GNU system.
> +not need to worry about this in @gnusystems{}.

This is a @theglibc{} case.

> -The following three bits are BSD features, and they exist only BSD
> -systems and the GNU system.  They are effective only if @code{OPOST} is
> +The following three bits are BSD features, and they exist only on BSD
> +systems and @gnuhurdsystems{}.  They are effective only if @code{OPOST} is
>  set.

This is not really accurate.  ONLCR is in latter-day POSIX.
Linux has OXTABS but spells it XTABS.  We should probably
add OXTABS as an alias for consistency.

> @@ -1461,7 +1463,7 @@ regardless of what you specify.
>  @node Other Special
>  @subsubsection Other Special Characters
>  
> -These special characters exist only in BSD systems and the GNU system.
> +These special characters exist only on BSD systems and @gnuhurdsystems{}.

Linux has (V)LNEXT and (V)DISCARD too.

>  The operating system does not support getting time zone information, and
> -@var{tzp} is not a null pointer.  The GNU operating system does not
> +@var{tzp} is not a null pointer.  @gnulinuxhurdsystems{} do not
>  support using @w{@code{struct timezone}} to represent time zone
>  information; that is an obsolete feature of 4.3 BSD.

This is a @gnusystems{} case, or perhaps even @theglibc{}.

>  @deftp {Data Type} {struct utmp}
>  The @code{utmp} data structure is used to hold information about entries
> -in the user accounting database.  On the GNU system it has the following
> +in the user accounting database.  In @theglibc{} it has the following
>  members:

This should probably be @gnusystems{}.


Thanks,
Roland