From: Alejandro Colomar <alx@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: devicetree@vger.kernel.org, linux-gpio@vger.kernel.org,
robh@kernel.org, conor+dt@kernel.org,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH v3 4/5] string: Add [C]QChar_of() and QVoid_of()
Date: Wed, 11 Nov 2026 01:03:46 +0100 [thread overview]
Message-ID: <avOuLrmqKK5Vb2vH@devuan> (raw)
In-Reply-To: <sashiko-outbox-207285@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3680 bytes --]
> Date: 2026-11-10 15:45:13+0000
> From: sashiko-bot@kernel.org
>
> Thank you for your contribution! Sashiko AI review found 2 potential
> issues to consider:
> - [High] string: void pointer subscript in QVoid_of() breaks Clang
> builds
It seems I can't build with LLVM in the way that sashiko suggested in
the other mail, so I can't reproduce this:
$ make LLVM=1
SYNC include/config/auto.conf
HOSTCC scripts/basic/fixdep
clang: error: invalid linker name in argument '-fuse-ld=lld'
make[3]: *** [scripts/Makefile.host:114: scripts/basic/fixdep] Error 1
make[2]: *** [Makefile:682: scripts_basic] Error 2
make[1]: *** [/srv/alx/src/linux/linux/llvm/Makefile:912: include/config/auto.conf] Error 2
make[1]: *** [include/config/auto.conf] Deleting file 'include/generated/rustc_cfg'
make[1]: *** [include/config/auto.conf] Deleting file 'include/generated/autoconf.h'
make: *** [Makefile:248: __sub-make] Error 2
But I see no reason why Clang shouldn't build this. I've written
a small test program just to see, and Clang seems to just work well:
alx@devuan:~/tmp$ cat const.c
#include <stddef.h>
#define QVoid_of(p) typeof((__QVoidptr_of(p)){0}[0])
#define __QVoidptr_of(p) typeof(1?(p):(void*){0})
int
main(void)
{
const void *p;
QVoid_of(p) *q; // const void *
}
alx@devuan:~/tmp$ gcc -Wall -Wextra -Wno-unused const.c
alx@devuan:~/tmp$ clang -Wall -Wextra -Wno-unused const.c
alx@devuan:~/tmp$
Unless anyone can actually reproduce the build issue, I'll assume this
report is nonsense.
> - [Medium] string: QChar_of() fails to compile when pointee has
> qualifiers other than Q
That's actually desirable. You don't want to call strchr(3) with
a pointer to volatile.
> --
>
> commit cea37634307d89ede7b6ca6128f006d50a90391c
> Author: Alejandro Colomar <alx@kernel.org>
>
> string: Add [C]QChar_of() and QVoid_of()
>
> This commit introduces the QVoid_of(), QChar_of(), and CQChar_of() helper
> macros in include/linux/string.h to support qualifier-generic string macros.
>
> > diff --git a/include/linux/string.h b/include/linux/string.h
[...]
>
> [Severity: High]
> Does applying the array subscript [0] to a void pointer in QVoid_of()
> break Clang builds?
I don't see why it would. I can't use LLVM myself, so can't reproduce,
but a small test program shows that Clang works just fine with it.
> __QVoidptr_of(p) produces a pointer to (qualified) void. Because array
> subscripting requires a pointer to a complete object type, Clang rejects
> (__QVoidptr_of(p)){0}[0] even inside typeof() with an incomplete type
> error, and GCC emits a -Wpointer-arith warning when pointer arithmetic
> warnings are enabled. Using unary * instead of [0], such as
> typeof(*(__QVoidptr_of(p)){0}), avoids both issues.
This is a lie, unless anyone can confirm.
[...]
> [Severity: Medium]
> Can QChar_of() fail to compile when the pointed-to type of p carries a
> qualifier other than Q?
Indeed, a desirable property.
> QVoid_of(p) preserves all qualifiers on the target of p, but the _Generic
> selection only matches exact Q void * and unqualified void *. Passing a
> volatile char * or const volatile char * to CQChar_of(p) produces a
> volatile void * or const volatile void * controlling expression, which
> matches neither association and fails at compile time. Matching against
> Q QVoid_of(p) *: (Q char){0} and default: (char){0} would test specifically
> for Q regardless of other qualifiers.
You certainly don't want to pass a volatile char* to strchr(3).
Alex
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-11-11 0:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 15:33 [PATCH v3 0/5] Add strprefix() and fix a bug with it Alejandro Colomar
2026-11-10 15:33 ` [PATCH v3 1/5] string: Add strprefix(), and deprecate str_has_prefix() Alejandro Colomar
2026-11-10 15:47 ` Joe Perches
2026-11-10 16:14 ` Alejandro Colomar
2026-11-11 8:43 ` Steven Rostedt
2026-11-10 15:33 ` [PATCH v3 2/5] device property: Fix fwnode_name_eq() for empty node names Alejandro Colomar
2026-11-10 15:33 ` [PATCH v3 3/5] stddef: Add const_cast() Alejandro Colomar
2026-11-11 10:25 ` David Laight
2026-11-11 10:51 ` Alejandro Colomar
2026-11-10 15:33 ` [PATCH v3 4/5] string: Add [C]QChar_of() and QVoid_of() Alejandro Colomar
2026-11-10 15:45 ` sashiko-bot
2026-11-11 0:03 ` Alejandro Colomar [this message]
2026-11-10 15:33 ` [PATCH v3 5/5] string: Make strprefix() const-qualifier-generic Alejandro Colomar
2026-11-10 15:44 ` sashiko-bot
2026-11-11 0:27 ` Alejandro Colomar
2026-11-10 16:32 ` Joe Perches
2026-11-10 23:27 ` Alejandro Colomar
2026-11-11 10:28 ` David Laight
2026-11-11 10:59 ` Alejandro Colomar
2026-11-11 10:34 ` David Laight
2026-11-11 11:28 ` 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=avOuLrmqKK5Vb2vH@devuan \
--to=alx@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.