This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Clean up glibc manual references to "GNU system" (bug 6911)
On Wed, 7 Mar 2012, Roland McGrath wrote:
> > -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{}, ..."
That's probably better here, but for "non-GNU systems" I wonder if an
@nongnusystems{} macro makes sense.
> > @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.
The reasoning I followed was that the standard error messages are in
sysdeps/gnu/errlist.c, and one might suppose that a port to a non-GNU
system would not use sysdeps/gnu but some other system for getting error
messages instead (although I don't see any real reason for the error
messages to vary between ports of glibc).
> This cases suggests we should have a @gnulinuxsystems{} too.
Yes, that would make sense.
> > -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).
No, it's (nil) for %p, (null) if you pass a null pointer to %s. This text
is discussing %p.
--
Joseph S. Myers
joseph@codesourcery.com