[PATCH] string_copying.7: tfix

[PATCH] string_copying.7: tfix

[Lennart Jablonka]

Signed-off-by: Lennart Jablonka <humm@ljabl.com>
---
On some of the commas:  There are a few of instances of

	Subject verb object partclause, advphrase.

For example:

	This function catenates the input character sequence contained in a null-padded wixed-width buffer, into a destination string.
	| subject     | verb    | object                     | participial clause                           | adverbial phrase       |

Dropping the relative clause, there shouldn't be a comma preceding the
restrictive adverbial phrase: The input character sequence is really,
always catenated into a destination string; that is essential.

The participial clause, being non-restrictive---there is but one input
character sequence that could be meant---, should be enclosed by commas.
That is the existing comma's purpose and doesn't work without the added,
first comma.

 man7/string_copying.7 | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/man7/string_copying.7 b/man7/string_copying.7
index da1fc6752..04426ef77 100644
--- a/man7/string_copying.7
+++ b/man7/string_copying.7
@@ -49,7 +49,7 @@ const char *restrict " src ,
 .PP
 // Zero a fixed-width buffer, and
 // copy a string into a character sequence with truncation.
-.BI "char *strncpy(char " dest "[restrict ." sz "], \
+.BI "char *strncpy(char " dst "[restrict ." sz "], \
 const char *restrict " src ,
 .BI "               size_t " sz );
 .PP
@@ -280,9 +280,9 @@ instead of
 In programs that make considerable use of strings or character sequences,
 and need the best performance,
 using overlapping character sequences can make a big difference.
-It allows holding subsequences of a larger character sequence.
+It allows holding sub-sequences of a larger character sequence,
 while not duplicating memory
-nor using time to do a copy.
+or using time to do a copy.
 .PP
 However, this is delicate,
 since it requires using character sequences.
@@ -397,7 +397,7 @@ It returns a pointer suitable for chaining.
 Truncation needs to be detected only once after the last chained call.
 .IP
 This function is not provided by any library;
-See EXAMPLES for a reference implementation.
+see EXAMPLES for a reference implementation.
 .\" ----- DESCRIPTION :: Functions :: strlcpy(3bsd), strlcat(3bsd) ----/
 .TP
 .BR strlcpy (3bsd)
@@ -427,7 +427,7 @@ isn't large enough to hold the copy,
 the resulting character sequence is truncated.
 Since it creates a character sequence,
 it doesn't need to write a terminating null byte.
-It's impossible to distinguish truncation by the result of the call,
+It's impossible to distinguish truncation by the result of the call
 from a character sequence that just fits the destination buffer;
 truncation should be detected by
 comparing the length of the input string
@@ -444,8 +444,8 @@ is a more useful alternative to this function.
 .\" ----- DESCRIPTION :: Functions :: zustr2ustp(3) --------------------/
 .TP
 .BR zustr2ustp (3)
-This function copies the input character sequence
-contained in a null-padded wixed-width buffer,
+This function copies the input character sequence,
+contained in a null-padded fixed-width buffer,
 into a destination character sequence.
 The programmer is responsible for allocating a buffer large enough.
 It returns a pointer suitable for chaining.
@@ -455,12 +455,12 @@ since the size of the original character sequence is always known,
 so it wouldn't be very useful.
 .IP
 This function is not provided by any library;
-See EXAMPLES for a reference implementation.
+see EXAMPLES for a reference implementation.
 .\" ----- DESCRIPTION :: Functions :: zustr2stp(3) --------------------/
 .TP
 .BR zustr2stp (3)
-This function copies the input character sequence
-contained in a null-padded wixed-width buffer,
+This function copies the input character sequence,
+contained in a null-padded fixed-width buffer,
 into a destination string.
 The programmer is responsible for allocating a buffer large enough.
 It returns a pointer suitable for chaining.
@@ -470,7 +470,7 @@ since the size of the original character sequence is always known,
 so it wouldn't be very useful.
 .IP
 This function is not provided by any library;
-See EXAMPLES for a reference implementation.
+see EXAMPLES for a reference implementation.
 .\" ----- DESCRIPTION :: Functions :: strncat(3) ----------------------/
 .TP
 .BR strncat (3)
@@ -478,8 +478,8 @@ Do not confuse this function with
 .BR strncpy (3);
 they are not related at all.
 .IP
-This function catenates the input character sequence
-contained in a null-padded wixed-width buffer,
+This function catenates the input character sequence,
+contained in a null-padded fixed-width buffer,
 into a destination string.
 The programmer is responsible for allocating a buffer large enough.
 The return value is useless.
-- 
2.41.0

Re: [PATCH] string_copying.7: tfix

[Alejandro Colomar]

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

Hi Lennart,

(CC += Branden)

On 2023-07-28 20:41, Lennart Jablonka wrote:
> Signed-off-by: Lennart Jablonka <humm@ljabl.com>
> ---
> On some of the commas:  There are a few of instances of
> 
> 	Subject verb object partclause, advphrase.
> 
> For example:
> 
> 	This function catenates the input character sequence contained in a null-padded wixed-width buffer, into a destination string.
> 	| subject     | verb    | object                     | participial clause                           | adverbial phrase       |
> 
> Dropping the relative clause, there shouldn't be a comma preceding the
> restrictive adverbial phrase: The input character sequence is really,
> always catenated into a destination string; that is essential.
> 
> The participial clause, being non-restrictive---there is but one input
> character sequence that could be meant---, should be enclosed by commas.
> That is the existing comma's purpose and doesn't work without the added,
> first comma.
> 
>  man7/string_copying.7 | 26 +++++++++++++-------------
>  1 file changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/man7/string_copying.7 b/man7/string_copying.7
> index da1fc6752..04426ef77 100644
> --- a/man7/string_copying.7
> +++ b/man7/string_copying.7
> @@ -49,7 +49,7 @@ const char *restrict " src ,
>  .PP
>  // Zero a fixed-width buffer, and
>  // copy a string into a character sequence with truncation.
> -.BI "char *strncpy(char " dest "[restrict ." sz "], \
> +.BI "char *strncpy(char " dst "[restrict ." sz "], \

Ok

>  const char *restrict " src ,
>  .BI "               size_t " sz );
>  .PP
> @@ -280,9 +280,9 @@ instead of
>  In programs that make considerable use of strings or character sequences,
>  and need the best performance,
>  using overlapping character sequences can make a big difference.
> -It allows holding subsequences of a larger character sequence.
> +It allows holding sub-sequences of a larger character sequence,

In this case, man-pages(7) advises to not hyphenate:

   Hyphenation with multi, non, pre, re, sub, and so on
       The general tendency in modern English is not to hyphenate  af‐
       ter prefixes such as "multi", "non", "pre", "re", "sub", and so
       on.   Manual pages should generally follow this rule when these
       prefixes are used in natural English constructions with  simple
       suffixes.   The  following list gives some examples of the pre‐
       ferred forms:

              [...]
              subcomponent
              subdirectory
              subsystem

>  while not duplicating memory
> -nor using time to do a copy.
> +or using time to do a copy.

Is nor incorrect here?  I'm not a native English speaker and would like
to understand why it is incorrect.

>  .PP
>  However, this is delicate,
>  since it requires using character sequences.
> @@ -397,7 +397,7 @@ It returns a pointer suitable for chaining.
>  Truncation needs to be detected only once after the last chained call.
>  .IP
>  This function is not provided by any library;
> -See EXAMPLES for a reference implementation.
> +see EXAMPLES for a reference implementation.

Ok

>  .\" ----- DESCRIPTION :: Functions :: strlcpy(3bsd), strlcat(3bsd) ----/
>  .TP
>  .BR strlcpy (3bsd)
> @@ -427,7 +427,7 @@ isn't large enough to hold the copy,
>  the resulting character sequence is truncated.
>  Since it creates a character sequence,
>  it doesn't need to write a terminating null byte.
> -It's impossible to distinguish truncation by the result of the call,
> +It's impossible to distinguish truncation by the result of the call
>  from a character sequence that just fits the destination buffer;

I guess it's ok (to me they both sound good)

>  truncation should be detected by
>  comparing the length of the input string
> @@ -444,8 +444,8 @@ is a more useful alternative to this function.
>  .\" ----- DESCRIPTION :: Functions :: zustr2ustp(3) --------------------/
>  .TP
>  .BR zustr2ustp (3)
> -This function copies the input character sequence
> -contained in a null-padded wixed-width buffer,
> +This function copies the input character sequence,

I believe the below is like a parenthetical, which is why I put it
between commas; isn't it?  Although your version also looks good.

> +contained in a null-padded fixed-width buffer,

Ok

>  into a destination character sequence.
>  The programmer is responsible for allocating a buffer large enough.
>  It returns a pointer suitable for chaining.
> @@ -455,12 +455,12 @@ since the size of the original character sequence is always known,
>  so it wouldn't be very useful.
>  .IP
>  This function is not provided by any library;
> -See EXAMPLES for a reference implementation.
> +see EXAMPLES for a reference implementation.

Ok

>  .\" ----- DESCRIPTION :: Functions :: zustr2stp(3) --------------------/
>  .TP
>  .BR zustr2stp (3)
> -This function copies the input character sequence
> -contained in a null-padded wixed-width buffer,
> +This function copies the input character sequence,

Same.

> +contained in a null-padded fixed-width buffer,

Heh, my text is wixed!

>  into a destination string.
>  The programmer is responsible for allocating a buffer large enough.
>  It returns a pointer suitable for chaining.
> @@ -470,7 +470,7 @@ since the size of the original character sequence is always known,
>  so it wouldn't be very useful.
>  .IP
>  This function is not provided by any library;
> -See EXAMPLES for a reference implementation.
> +see EXAMPLES for a reference implementation.

Ok

>  .\" ----- DESCRIPTION :: Functions :: strncat(3) ----------------------/
>  .TP
>  .BR strncat (3)
> @@ -478,8 +478,8 @@ Do not confuse this function with
>  .BR strncpy (3);
>  they are not related at all.
>  .IP
> -This function catenates the input character sequence
> -contained in a null-padded wixed-width buffer,
> +This function catenates the input character sequence,
> +contained in a null-padded fixed-width buffer,

And same.

Thanks,
Alex

>  into a destination string.
>  The programmer is responsible for allocating a buffer large enough.
>  The return value is useless.

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


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

Re: [PATCH] string_copying.7: tfix

[Lennart Jablonka]

>> diff --git a/man7/string_copying.7 b/man7/string_copying.7
>> index da1fc6752..04426ef77 100644
>> --- a/man7/string_copying.7
>> +++ b/man7/string_copying.7
>> @@ -280,9 +280,9 @@ instead of
>>  In programs that make considerable use of strings or character sequences,
>>  and need the best performance,
>>  using overlapping character sequences can make a big difference.
>> -It allows holding subsequences of a larger character sequence.
>> +It allows holding sub-sequences of a larger character sequence,
>
>In this case, man-pages(7) advises to not hyphenate:

I see.  I stumbled a little, “subsequences” being similar to 
“subsequent.”  I don’t have a strong opinion.

>>  while not duplicating memory
>> -nor using time to do a copy.
>> +or using time to do a copy.
>
>Is nor incorrect here?

It’s not exactly incorrect here.  Such a usage is common; who 
am I to say that it’s wrong?  It’s not useful to use it here, 
either.  The most common use of nor is a neither-nor construction:  
The weather is neither good nor bad.  Not good and not bad.  Not 
either good or bad.  Admire the construction’s elegance:  two 
little conjunctions, forming a pair (though a pair it need not be) 
to give you the anticipated meaning, clear in every word along the 
way.  Though that construction isn’t what’s used here.

Here, compare

	while (not ((duplicating memory) or (using time to do a copy)))

to

	while not duplicating memory nor using time to do a copy

which you might imagine as expanding to

	while not duplicating memory and not using time to do a copy

with imagined precedence as

	while ((not (duplicating memory)) and (not (using time to do a copy)))

where, thus, the word “nor” seems to be split in half.  It works.  
It’s correct.  And yet it instills in me a strange feeling of 
unorderedness.

Your mileage may vary.

>I'm not a native English speaker

Neither am I.

>and would like to understand why it is incorrect.

>> @@ -444,8 +444,8 @@ is a more useful alternative to this function.
>>  .\" ----- DESCRIPTION :: Functions :: zustr2ustp(3) --------------------/
>>  .TP
>>  .BR zustr2ustp (3)
>> -This function copies the input character sequence
>> -contained in a null-padded wixed-width buffer,
>> +This function copies the input character sequence,
>
>I believe the below is like a parenthetical, which is why I put it
>between commas; isn't it?  Although your version also looks good.
>
>> +contained in a null-padded fixed-width buffer,
>
>Ok
>
>>  into a destination character sequence.

The “contained in a null-padded fixed-width buffer” indeed looks 
like a parenthetical (or rather, a non-restrictive participial 
clause—the “contained” is the participle), which is why it should 
be between commas.  You didn’t do quite that:  You put a comma 
after it, but not before.

This case is what I tried to explain:  You set off the “into 
a destination character sequence” prepositional phrase (the “into” 
being the preposition) by a comma.  You did not surround the 
participial clause by commas.  That’s what I did.

Re: [PATCH] string_copying.7: tfix

[G. Branden Robinson]

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

Hi Alex,

At 2023-07-28T23:31:10+0200, Alejandro Colomar wrote:
> (CC += Branden)

I think I just received my grammar prescriptivist's draft notice... ;-)

> On 2023-07-28 20:41, Lennart Jablonka wrote:
> >  while not duplicating memory
> > -nor using time to do a copy.
> > +or using time to do a copy.
> 
> Is nor incorrect here?  I'm not a native English speaker and would
> like to understand why it is incorrect.

With the humbling caveat that you find me more persuasive than some
online grammar authorities, the foregoing suggestion is in my view a
hypercorrection.  The (coordinating) conjunction "nor" is not restricted
to sentences using "neither".

https://newsroom.unl.edu/announce/snr/3511/19686
https://study.com/learn/lesson/neither-nor-usage-examples-sentences.html
https://www.grammarbook.com/blog/effective-writing/using-nor-properly/

In the last, attend particularly to section "Using Nor Properly:
Interchanging with Or".

I'm a +0 on this hunk of the patch.  It's correct either way.

> > -See EXAMPLES for a reference implementation.
> > +see EXAMPLES for a reference implementation.
> 
> Ok

Strong +1 here.  It is volcanically nonstandard to apply sentence
capitalization to an independent clause after a semicolon.

> >  .\" ----- DESCRIPTION :: Functions :: strlcpy(3bsd), strlcat(3bsd) ----/
> >  .TP
> >  .BR strlcpy (3bsd)
> > @@ -427,7 +427,7 @@ isn't large enough to hold the copy,
> >  the resulting character sequence is truncated.
> >  Since it creates a character sequence,
> >  it doesn't need to write a terminating null byte.
> > -It's impossible to distinguish truncation by the result of the call,
> > +It's impossible to distinguish truncation by the result of the call
> >  from a character sequence that just fits the destination buffer;
> 
> I guess it's ok (to me they both sound good)

I think the comma arose there due to good instincts: you have a long
chain of prepositional (and participial) phrases that do _not_ grow
strictly narrower in scope as they proceed.

Consider:

"Due to the dense foliage, it's impossible to distinguish the man in the
tree growing from the loamy soil laid down in the Cenozoic Era that I
remember learning about in geology class."

This (admittedly goofy) sentence is not difficult to interpret: each
phrase (after the first, "Due to", which serves as a topicalizer)
modifies only the preceding one.

By contrast, the sentence in this man page is structurally complex and
therefore challenging to parse.

"It's impossible to distinguish
     (truncation (by the result (of the call))
from (a character sequence (that just fits
                                           ([inside] the destination
                                            buffer))).

That's pretty tough sledding.  Only semantic knowledge permits the
experienced programmer to make sense of it.

The use of the comma prompts the reader that an ambiguous parse is
possible, and that they should pause, as they would in speaking, to
permit the modifying phrases just uttered to bind to the preceding
language.  Or, alternatively, the comma (or pause) is a warning that the
phrase stack is being popped, cueing the reader or listener to attempt
multiple parses in search of one that seems suitable.

That this exhibit took so much meta-analysis to explain is what
motivates my advice: it would be better to recast the sentence until
clarity is achieved.

> > -This function copies the input character sequence
> > -contained in a null-padded wixed-width buffer,
> > +This function copies the input character sequence,
> 
> I believe the below is like a parenthetical, which is why I put it
> between commas; isn't it?  Although your version also looks good.
> 
> > +contained in a null-padded fixed-width buffer,
> 
> Ok
> 
> >  into a destination character sequence.

I'm a +0 on this one, too.  To me, it reads equivalently either way.

[duplicates of the foregoing cases snipped]

Regards,
Branden

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

Re: [PATCH] string_copying.7: tfix

[Alejandro Colomar]

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

On 2023-07-29 01:26, Lennart Jablonka wrote:

[...]

>>> @@ -444,8 +444,8 @@ is a more useful alternative to this function.
>>>  .\" ----- DESCRIPTION :: Functions :: zustr2ustp(3) --------------------/
>>>  .TP
>>>  .BR zustr2ustp (3)
>>> -This function copies the input character sequence
>>> -contained in a null-padded wixed-width buffer,
>>> +This function copies the input character sequence,
>>
>> I believe the below is like a parenthetical, which is why I put it
>> between commas; isn't it?  Although your version also looks good.
>>
>>> +contained in a null-padded fixed-width buffer,
>>
>> Ok
>>
>>>  into a destination character sequence.
> 
> The “contained in a null-padded fixed-width buffer” indeed looks 
> like a parenthetical (or rather, a non-restrictive participial 
> clause—the “contained” is the participle), which is why it should 
> be between commas.  You didn’t do quite that:  You put a comma 
> after it, but not before.
> 
> This case is what I tried to explain:  You set off the “into 
> a destination character sequence” prepositional phrase (the “into” 
> being the preposition) by a comma.  You did not surround the 
> participial clause by commas.  That’s what I did.

D'oh!  I misread the diff; I thought you were removing the comma
instead of adding it.  I certainly like your addition.

Cheers,
Alex

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


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

Re: [PATCH] string_copying.7: tfix

[Alejandro Colomar]

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

Hi Branden,

On 2023-07-29 11:50, G. Branden Robinson wrote:
> Hi Alex,
> 
> At 2023-07-28T23:31:10+0200, Alejandro Colomar wrote:
>> (CC += Branden)
> 
> I think I just received my grammar prescriptivist's draft notice... ;-)
> 
>> On 2023-07-28 20:41, Lennart Jablonka wrote:
>>>  while not duplicating memory
>>> -nor using time to do a copy.
>>> +or using time to do a copy.
>>
>> Is nor incorrect here?  I'm not a native English speaker and would
>> like to understand why it is incorrect.
> 
> With the humbling caveat that you find me more persuasive than some
> online grammar authorities,

;-)

> the foregoing suggestion is in my view a
> hypercorrection.  The (coordinating) conjunction "nor" is not restricted
> to sentences using "neither".
> 
> https://newsroom.unl.edu/announce/snr/3511/19686
> https://study.com/learn/lesson/neither-nor-usage-examples-sentences.html
> https://www.grammarbook.com/blog/effective-writing/using-nor-properly/
> 
> In the last, attend particularly to section "Using Nor Properly:
> Interchanging with Or".
> 
> I'm a +0 on this hunk of the patch.  It's correct either way.

I prefer nor in this case.  It sounds better to me.

> 
>>> -See EXAMPLES for a reference implementation.
>>> +see EXAMPLES for a reference implementation.
>>
>> Ok
> 
> Strong +1 here.  It is volcanically nonstandard to apply sentence
> capitalization to an independent clause after a semicolon.

Yep; I don't know why I wrote it like that.  Maybe I had initially
written a period; I'll never know.

> 
>>>  .\" ----- DESCRIPTION :: Functions :: strlcpy(3bsd), strlcat(3bsd) ----/
>>>  .TP
>>>  .BR strlcpy (3bsd)
>>> @@ -427,7 +427,7 @@ isn't large enough to hold the copy,
>>>  the resulting character sequence is truncated.
>>>  Since it creates a character sequence,
>>>  it doesn't need to write a terminating null byte.
>>> -It's impossible to distinguish truncation by the result of the call,
>>> +It's impossible to distinguish truncation by the result of the call
>>>  from a character sequence that just fits the destination buffer;
>>
>> I guess it's ok (to me they both sound good)
> 
> I think the comma arose there due to good instincts: you have a long
> chain of prepositional (and participial) phrases that do _not_ grow
> strictly narrower in scope as they proceed.
> 
> Consider:
> 
> "Due to the dense foliage, it's impossible to distinguish the man in the
> tree growing from the loamy soil laid down in the Cenozoic Era that I
> remember learning about in geology class."
> 
> This (admittedly goofy) sentence is not difficult to interpret: each
> phrase (after the first, "Due to", which serves as a topicalizer)
> modifies only the preceding one.
> 
> By contrast, the sentence in this man page is structurally complex and
> therefore challenging to parse.
> 
> "It's impossible to distinguish
>      (truncation (by the result (of the call))
> from (a character sequence (that just fits
>                                            ([inside] the destination
>                                             buffer))).
> 
> That's pretty tough sledding.  Only semantic knowledge permits the
> experienced programmer to make sense of it.
> 
> The use of the comma prompts the reader that an ambiguous parse is
> possible, and that they should pause, as they would in speaking, to
> permit the modifying phrases just uttered to bind to the preceding
> language.  Or, alternatively, the comma (or pause) is a warning that the
> phrase stack is being popped, cueing the reader or listener to attempt
> multiple parses in search of one that seems suitable.
> 
> That this exhibit took so much meta-analysis to explain is what
> motivates my advice: it would be better to recast the sentence until
> clarity is achieved.

Yep, I also like that comma to simplify parsing.

> 
>>> -This function copies the input character sequence
>>> -contained in a null-padded wixed-width buffer,
>>> +This function copies the input character sequence,
>>
>> I believe the below is like a parenthetical, which is why I put it
>> between commas; isn't it?  Although your version also looks good.
>>
>>> +contained in a null-padded fixed-width buffer,
>>
>> Ok
>>
>>>  into a destination character sequence.
> 
> I'm a +0 on this one, too.  To me, it reads equivalently either way.

In this case I prefer the proposed hunk.  In fact, I doubted because
I misread the hunk as doing the inverse of what it really does.

Thanks for your prescriptions!

Cheers,
Alex

> 
> [duplicates of the foregoing cases snipped]
> 
> Regards,
> Branden

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


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

Re: [PATCH] string_copying.7: tfix

[Alejandro Colomar]

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

Hi Lennart,

On 2023-07-28 20:41, Lennart Jablonka wrote:
> Signed-off-by: Lennart Jablonka <humm@ljabl.com>

Please send v2 with

Cc: "G. Branden Robinson" <g.branden.robinson@gmail.com>

I'll comment below on what should be removed from the patch in v2.
Reword the commit message as you find appropriate for the revision.

> ---
> On some of the commas:  There are a few of instances of
> 
> 	Subject verb object partclause, advphrase.
> 
> For example:
> 
> 	This function catenates the input character sequence contained in a null-padded wixed-width buffer, into a destination string.
> 	| subject     | verb    | object                     | participial clause                           | adverbial phrase       |
> 
> Dropping the relative clause, there shouldn't be a comma preceding the
> restrictive adverbial phrase: The input character sequence is really,
> always catenated into a destination string; that is essential.
> 
> The participial clause, being non-restrictive---there is but one input
> character sequence that could be meant---, should be enclosed by commas.
> That is the existing comma's purpose and doesn't work without the added,
> first comma.


Please include these things in the commit message.  The same it can
be useful for me to review now, it can be useful for anyone
revisiting the patch in the future.

> 
>  man7/string_copying.7 | 26 +++++++++++++-------------
>  1 file changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/man7/string_copying.7 b/man7/string_copying.7
> index da1fc6752..04426ef77 100644
> --- a/man7/string_copying.7
> +++ b/man7/string_copying.7
> @@ -49,7 +49,7 @@ const char *restrict " src ,
>  .PP
>  // Zero a fixed-width buffer, and
>  // copy a string into a character sequence with truncation.
> -.BI "char *strncpy(char " dest "[restrict ." sz "], \
> +.BI "char *strncpy(char " dst "[restrict ." sz "], \

ok

>  const char *restrict " src ,
>  .BI "               size_t " sz );
>  .PP
> @@ -280,9 +280,9 @@ instead of
>  In programs that make considerable use of strings or character sequences,
>  and need the best performance,
>  using overlapping character sequences can make a big difference.
> -It allows holding subsequences of a larger character sequence.
> +It allows holding sub-sequences of a larger character sequence,

Use subsequences (but the s/./,/ is good).

>  while not duplicating memory
> -nor using time to do a copy.
> +or using time to do a copy.

revert

>  .PP
>  However, this is delicate,
>  since it requires using character sequences.
> @@ -397,7 +397,7 @@ It returns a pointer suitable for chaining.
>  Truncation needs to be detected only once after the last chained call.
>  .IP
>  This function is not provided by any library;
> -See EXAMPLES for a reference implementation.
> +see EXAMPLES for a reference implementation.

ok

>  .\" ----- DESCRIPTION :: Functions :: strlcpy(3bsd), strlcat(3bsd) ----/
>  .TP
>  .BR strlcpy (3bsd)
> @@ -427,7 +427,7 @@ isn't large enough to hold the copy,
>  the resulting character sequence is truncated.
>  Since it creates a character sequence,
>  it doesn't need to write a terminating null byte.
> -It's impossible to distinguish truncation by the result of the call,
> +It's impossible to distinguish truncation by the result of the call

revert

>  from a character sequence that just fits the destination buffer;
>  truncation should be detected by
>  comparing the length of the input string
> @@ -444,8 +444,8 @@ is a more useful alternative to this function.
>  .\" ----- DESCRIPTION :: Functions :: zustr2ustp(3) --------------------/
>  .TP
>  .BR zustr2ustp (3)
> -This function copies the input character sequence
> -contained in a null-padded wixed-width buffer,
> +This function copies the input character sequence,

ok

> +contained in a null-padded fixed-width buffer,

ok

>  into a destination character sequence.
>  The programmer is responsible for allocating a buffer large enough.
>  It returns a pointer suitable for chaining.
> @@ -455,12 +455,12 @@ since the size of the original character sequence is always known,
>  so it wouldn't be very useful.
>  .IP
>  This function is not provided by any library;
> -See EXAMPLES for a reference implementation.
> +see EXAMPLES for a reference implementation.

ok

>  .\" ----- DESCRIPTION :: Functions :: zustr2stp(3) --------------------/
>  .TP
>  .BR zustr2stp (3)
> -This function copies the input character sequence
> -contained in a null-padded wixed-width buffer,
> +This function copies the input character sequence,

ok

> +contained in a null-padded fixed-width buffer,

ok

>  into a destination string.
>  The programmer is responsible for allocating a buffer large enough.
>  It returns a pointer suitable for chaining.
> @@ -470,7 +470,7 @@ since the size of the original character sequence is always known,
>  so it wouldn't be very useful.
>  .IP
>  This function is not provided by any library;
> -See EXAMPLES for a reference implementation.
> +see EXAMPLES for a reference implementation.

ok

>  .\" ----- DESCRIPTION :: Functions :: strncat(3) ----------------------/
>  .TP
>  .BR strncat (3)
> @@ -478,8 +478,8 @@ Do not confuse this function with
>  .BR strncpy (3);
>  they are not related at all.
>  .IP
> -This function catenates the input character sequence
> -contained in a null-padded wixed-width buffer,
> +This function catenates the input character sequence,

ok

> +contained in a null-padded fixed-width buffer,

ok

>  into a destination string.
>  The programmer is responsible for allocating a buffer large enough.
>  The return value is useless.

Cheers,
Alex

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


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