From: Alejandro Colomar <alx@kernel.org>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>,
linux-man@vger.kernel.org
Subject: Re: [PATCH 1/2] man*/: ffix (use `\%`)
Date: Thu, 20 Jul 2023 10:18:15 +0200 [thread overview]
Message-ID: <2f35c3df-c14f-cca7-b136-328638988ec0@kernel.org> (raw)
In-Reply-To: <20230720020436.vejzttvkklhmkgpn@illithid>
[-- Attachment #1.1: Type: text/plain, Size: 4451 bytes --]
Hi Branden,
On 2023-07-20 04:04, G. Branden Robinson wrote:
> From 25d379c486d28357a8341b0cfbce1b43b82e177f Mon Sep 17 00:00:00 2001
> From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
> Date: Wed, 19 Jul 2023 17:59:27 -0500
> Subject: [PATCH 1/2] man*/: ffix (use `\%`)
>
> Protect instances of some literals from hyphenation. These are only
> those necessary to improve analyzability of a large-scale (500+ file),
> sed-driven change to improve adjustment and hyphenation enablement
> management around tables.
>
> * man2/getrlimit.2: Protect some instances of `RLIMIT_MSGQUEUE`,
> `RLIMIT_SIGPENDING`, `RLIMIT_FSIZE`, and `getrlimit` from hyphenation.
> * man2/sigaltstack.2: Protect an instance of `setrlimit` from
> hyphenation.
> * man3/gethostbyname.3: Protect an instance of `endhostent` from
> hyphenation.
> * man3/getmntent.3: Protect an instance of `getmntinfo` from
> hyphenation.
> ---
> man2/getrlimit.2 | 10 +++++-----
> man2/sigaltstack.2 | 2 +-
> man3/gethostbyname.3 | 2 +-
> man3/getmntent.3 | 2 +-
> 4 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/man2/getrlimit.2 b/man2/getrlimit.2
> index 21f919fdc..5d4e428d1 100644
> --- a/man2/getrlimit.2
> +++ b/man2/getrlimit.2
> @@ -577,12 +577,12 @@ .SH STANDARDS
> .B RLIMIT_RSS
> derives from BSD and is not specified in POSIX.1;
> it is nevertheless present on most implementations.
> -.BR RLIMIT_MSGQUEUE ,
> +.BR \%RLIMIT_MSGQUEUE ,
> .BR RLIMIT_NICE ,
> .BR RLIMIT_RTPRIO ,
> .BR RLIMIT_RTTIME ,
> and
> -.B RLIMIT_SIGPENDING
> +.B \%RLIMIT_SIGPENDING
> are Linux-specific.
> .SH HISTORY
> .TP
> @@ -747,7 +747,7 @@ .SS Representation of """large""" resource limit values on 32-bit platforms
> .\" https://bugzilla.kernel.org/show_bug.cgi?id=5042
> .\" https://www.sourceware.org/bugzilla/show_bug.cgi?id=12201
> The most pertinent limit here is
> -.BR RLIMIT_FSIZE ,
> +.BR \%RLIMIT_FSIZE ,
> which specifies the maximum size to which a file can grow:
> to be useful, this limit must be represented using a type
> that is as wide as the type used to
> @@ -769,13 +769,13 @@ .SS Representation of """large""" resource limit values on 32-bit platforms
> Since glibc 2.13,
> .\" https://www.sourceware.org/bugzilla/show_bug.cgi?id=12201
> glibc works around the limitations of the
> -.BR getrlimit ()
> +.BR \%getrlimit ()
> and
> .BR setrlimit ()
> system calls by implementing
> .BR setrlimit ()
> and
> -.BR getrlimit ()
> +.BR \%getrlimit ()
So, you don't want MR in these cases, right?
Makes sense.
> as wrapper functions that call
> .BR prlimit ().
> .SH EXAMPLES
> diff --git a/man2/sigaltstack.2 b/man2/sigaltstack.2
> index 6ae8a612c..b42149541 100644
> --- a/man2/sigaltstack.2
> +++ b/man2/sigaltstack.2
> @@ -230,7 +230,7 @@ .SH NOTES
> expects that it may exhaust its standard stack.
> This may occur, for example, because the stack grows so large
> that it encounters the upwardly growing heap, or it reaches a
> -limit established by a call to \fBsetrlimit(RLIMIT_STACK, &rlim)\fP.
> +limit established by a call to \fB\%setrlimit(RLIMIT_STACK, &rlim)\fP.
I think I would fix those \f thingies before messing with them.
Do you prefer it in this order?
Also, it seem this one is wrong: it should be I, as it's code.
Cheers,
Alex
> If the standard stack is exhausted, the kernel sends
> the thread a \fBSIGSEGV\fP signal.
> In these circumstances the only way to catch this signal is
> diff --git a/man3/gethostbyname.3 b/man3/gethostbyname.3
> index 492e22d69..b467e92d9 100644
> --- a/man3/gethostbyname.3
> +++ b/man3/gethostbyname.3
> @@ -377,7 +377,7 @@ .SH ATTRIBUTES
> .BR gethostent (),
> .BR gethostent_r (),
> or
> -.BR endhostent ()
> +.BR \%endhostent ()
> are used in parallel in different threads of a program,
> then data races could occur.
> .SH STANDARDS
> diff --git a/man3/getmntent.3 b/man3/getmntent.3
> index 5c0cfde0a..37e7225bd 100644
> --- a/man3/getmntent.3
> +++ b/man3/getmntent.3
> @@ -249,7 +249,7 @@ .SH HISTORY
> .I /etc/mnttab
> is used.
> 4.4BSD and Digital UNIX have a routine
> -.BR getmntinfo (),
> +.BR \%getmntinfo (),
> a wrapper around the system call
> .BR getfsstat ().
> .SH SEE ALSO
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-07-20 8:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-20 2:04 [PATCH 1/2] man*/: ffix (use `\%`) G. Branden Robinson
2023-07-20 8:18 ` Alejandro Colomar [this message]
2023-07-20 9:10 ` G. Branden Robinson
2023-07-20 13:12 ` Alejandro Colomar
2023-07-20 13:16 ` Alejandro Colomar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2f35c3df-c14f-cca7-b136-328638988ec0@kernel.org \
--to=alx@kernel.org \
--cc=g.branden.robinson@gmail.com \
--cc=linux-man@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox