From: Alejandro Colomar <alx@kernel.org>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: linux-man@vger.kernel.org, bug-gnulib@gnu.org
Subject: Re: [PATCH v1 1/1] man/man3/strnul.3: New page
Date: Sat, 21 Feb 2026 20:56:05 +0100 [thread overview]
Message-ID: <aZoMp9gUNpU6rGo4@devuan> (raw)
In-Reply-To: <20260221174142.5e6xufffrawahxsp@illithid>
[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]
Hi Branden,
On 2026-02-21T11:41:42-0600, G. Branden Robinson wrote:
> Hi Alex,
>
> At 2026-02-21T16:02:52+0100, Alejandro Colomar wrote:
> > +.SH RETURN VALUE
> > +.IR s+strlen(s) .
>
> Too cute, in my opinion. Use English. :)
The thing is, at first I thought, am I going to repeat the same exact
words as in the DESCRIPTION?
DESCRIPTION
strnul() returns a pointer to the terminating null byte in the
string s.
RETURN VALUE
strnul() returns a pointer to the terminating null byte in the
string s.
I could remove the DESCRIPTION altogether... What would you do?
>
> C novices struggle with pointer arithmetic as it is. (Even non-novices
> can, when working with exotic architectures with multiple memory models
> like the x86's historical--and thankfully near-forgotten--`near` and
> `far`. Pointer arithmetic in the former can, if my vague recollection
> is correct, do surprising stuff like wrap around a 64 KiB memory segment
> without causing a fault.)
I might as well write it as &s[strlen(s)] if pointer arithmetic is the
confusing part. :)
>
> I assume that the string library reforms you're pursuing are intended in
> part to be adopted by newcomers to C.
I intend old programmers to use it too. I guess you're expecting
a patch to groff once this is in a branch of gnulib you're using. ;)
> Avoiding cleverness when
> presenting new interfaces can make them less scary.
Agree.
Have a lovely night!
Alex
>
> Regards,
> Branden
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-02-21 19:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-21 15:02 [PATCH v1 0/1] Document strnul(3) Alejandro Colomar
2026-02-21 15:02 ` [PATCH v1 1/1] man/man3/strnul.3: New page Alejandro Colomar
2026-02-21 17:41 ` G. Branden Robinson
2026-02-21 19:56 ` Alejandro Colomar [this message]
2026-02-21 20:02 ` Simon Josefsson
2026-02-21 20:45 ` Alejandro Colomar
2026-02-21 20:05 ` G. Branden Robinson
2026-02-21 20:55 ` Alejandro Colomar
2026-02-22 1:48 ` Paul Eggert
2026-02-22 11:21 ` Alejandro Colomar
2026-02-22 13:46 ` Alejandro Colomar
2026-02-22 14:10 ` Bruno Haible
2026-02-22 14:19 ` Alejandro Colomar
2026-02-22 14:21 ` Alejandro Colomar
2026-02-21 15:04 ` [PATCH v1 0/1] Document strnul(3) Alejandro Colomar
2026-02-21 15:09 ` Alejandro Colomar
2026-02-21 20:53 ` [PATCH v2 " Alejandro Colomar
2026-02-21 20:53 ` [PATCH v2 1/1] man/man3/strnul.3: New page 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=aZoMp9gUNpU6rGo4@devuan \
--to=alx@kernel.org \
--cc=bug-gnulib@gnu.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