All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: linux-man@vger.kernel.org
Subject: Re: QChar and QVoid for strchr(3), memchr(3), et al.
Date: Wed, 25 Feb 2026 00:34:58 +0100	[thread overview]
Message-ID: <aZ40B_03Qigx680z@devuan> (raw)
In-Reply-To: <ba68e79b-c86c-4cd1-b826-fd67f0cd0878@cs.ucla.edu>

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

Hi Paul,

On 2026-02-24T15:19:14-0800, Paul Eggert wrote:
> On 2026-02-24 15:05, Alejandro Colomar wrote:
> > > > How would you document strchr(3)?
> > > I'd do what the standard does rather than reinvent this particular wheel.
> > So, you'd use QChar?
> 
> Yes. As confusing as QChar/QVoid is, it'd likely be more confusing overall
> for us to invent our own notation.

Hmmmm, okay.  I see conflicting opinions (others prefer C++-like
overload notation).  I think I prefer QChar/QVoid, but am not convinced
of which to use.

Whichever we use, we need to distinguish cases like strnul(3) from cases
like strchr(3).  I think I'd do it like this:

	strchr(3)
	SYNOPSIS
		#include <string.h>

		QChar *strchr(QChar *s, int c);

		#undef strchr
		char *strchr(const char *s, int c);

The above documents that you can #undef the macro, which provides the
function with the different prototype.  And then strnul(3) would only
have the QChar prototype, as there's no function.

	strnul(3)
	SYNOPSIS
		#include <string.h>

		QChar *strnul(QChar *s);

What do you think?

> Whichever notation we use, we need to
> explain the business with void * arguments anyway.

Hmmm, yeah, this and other corner cases lead me to think QChar/QVoid
would be better.  It would allow me to write a manual page describing
those.  And I expect people will eventually get used to that syntax;
it's a matter of time.


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>

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

  reply	other threads:[~2026-02-24 23:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-24 14:28 QChar and QVoid for strchr(3), memchr(3), et al Alejandro Colomar
2026-02-24 16:56 ` Mark Harris
2026-02-24 17:14 ` Paul Eggert
2026-02-24 21:31   ` Alejandro Colomar
2026-02-24 23:04     ` Paul Eggert
2026-02-24 23:05       ` Alejandro Colomar
2026-02-24 23:19         ` Paul Eggert
2026-02-24 23:34           ` Alejandro Colomar [this message]
2026-02-25  1:03             ` Mark Harris
2026-02-25  1:15               ` Alejandro Colomar
2026-02-24 18:52 ` Rene Kita
2026-02-24 21:41   ` Alejandro Colomar
2026-02-25 15:48     ` Rene Kita

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=aZ40B_03Qigx680z@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.