Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 5 Feb 2020 19:17:17 -0500
From: Rich Felker <>
Subject: Re: [PATCH] add support for pthread_sigqueue

On Wed, Feb 05, 2020 at 05:06:11PM -0600, A. Wilcox wrote:
> On 05/02/2020 13:27, Rich Felker wrote:
> > Is the naming pthread_sigqueue (vs pthread_sigqueue_np) intentional?
> > Normally pthread functions that are not part of the standard are
> > introduced as _np (non-portable) and promoted later if accepted as
> > standards since the pthread_* namespace is reserved for future
> > directions of the standard. Does glibc have this function with the
> > same signature already?
> The signature differs only with the constness of the third argument in
> the header.  (The constness in the function implementation is correct.)

This is not a difference in the signature; the constness in the
declaration is meaningless (explicitly ignored by the language). In
the definition, it causes the local variable corresponding to the
argument to be const, but that's not terribly useful.

> It is implemented not only in glibc, but additionally in Solaris 11:

Without _np -- interesting. I'm not opposed if this seems to be the

> The corresponding system call was added in Linux 2.6.31, if it matters.
> I have no comments (positive or negative) regarding the addition of this
> call nor its implementation other than that the constness should be
> fixed in the header.

That change isn't needed or wanted; it's just confusing since it looks
like it should have some meaning but doesn't. I would remove it from
the definition too; we don't normally make arguments gratuitously
const even if the function definition doesn't modify them during their


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.