From: Alejandro Colomar <alx@kernel.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: linux-man@vger.kernel.org
Subject: Re: [PATCH 4/4] stpncpy(3) fixes
Date: Tue, 21 Nov 2023 19:33:18 +0100 [thread overview]
Message-ID: <ZVz37_06mbiMBMVc@devuan> (raw)
In-Reply-To: <ZVF8B-guyK2Zby4P@debian>
[-- Attachment #1: Type: text/plain, Size: 1831 bytes --]
On Mon, Nov 13, 2023 at 02:29:38AM +0100, Alejandro Colomar wrote:
> Hi Paul,
>
> On Sun, Nov 12, 2023 at 03:52:08PM -0800, Paul Eggert wrote:
> > Don't say "width" when "size" was meant.
> Ok
>
> > Prefer "byte" to the confusing word "character".
> Ok
>
> > Don't say that the source is a string; it need not be a string.
> As said in string.3, I'm not convinced by the new wording either.
>
> > Don't imply the result always has some null padding.
> Ok
>
> > Prefer standalone terminology.
> Ok
>
> > Fix indenting of prototype.
> Ok
>
> > Improve sample implementation by using memset rather than
> > the less-standard bzero,
>
> While bzero(3) is non-standard, it is simpler, so I prefer it.
>
> > and by not overwriting part of
> > the destination more than once which is confusing.
> Ok
>
> > Simplify example without losing its lessons.
> See some comments inline.
>
> > Use fwrite instead of printf to avoid assuming buffer length fits in int;
> Thanks! And even without the int issue, it's more consistent with
> handling non-terminated bytes.
>
> > although obviously this buffer length does fit, it's better if the sample
> > code is general.
> Yep.
>
I've applied some of the changes in separate commits:
6b050ad54 (HEAD -> contrib, alx/contrib) stpncpy.3: Reword, saying 'byte' instead of 'character'
be301345f stpncpy.3: EXAMPLES: errx(3) instead of warnx(3) if truncation occurs
d6499e777 stpncpy.3: EXAMPLES: Use fwrite(3) instead of printf(3)
2560770b2 stpncpy.3: NAME: Clarify that these functions only padd if necessary
7f19af378 stpncpy.3: Optimize possible implementation of stpncpy()
2f5a64243 stpncpy.3: SYNOPSIS: ffix
a845da18f stpncpy.3: Don't say 'width' when 'size' is meant
Cheers,
Alex
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-11-21 18:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-12 23:52 [PATCH 0/4] improvements for strncpy.3 etc Paul Eggert
2023-11-12 23:52 ` [PATCH 1/4] * Remove man3/stpecpyx.3; no longer present Paul Eggert
2023-11-13 0:18 ` Alejandro Colomar
2023-11-12 23:52 ` [PATCH 2/4] string.3 fixes Paul Eggert
2023-11-13 0:53 ` Alejandro Colomar
2023-11-13 22:27 ` Paul Eggert
2023-11-13 23:25 ` Alejandro Colomar
2023-11-12 23:52 ` [PATCH 3/4] strncat.3 fixes Paul Eggert
2023-11-13 1:15 ` Alejandro Colomar
2023-11-13 16:23 ` Alejandro Colomar
2023-11-21 16:03 ` Alejandro Colomar
2023-11-12 23:52 ` [PATCH 4/4] stpncpy(3) fixes Paul Eggert
2023-11-13 1:29 ` Alejandro Colomar
2023-11-21 18:33 ` Alejandro Colomar [this message]
2023-11-21 21:18 ` Paul Eggert
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=ZVz37_06mbiMBMVc@devuan \
--to=alx@kernel.org \
--cc=eggert@cs.ucla.edu \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.