[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87F4003B-5011-49EF-A807-CEA094EA0DAC@zytor.com>
Date: Mon, 08 Dec 2025 19:28:53 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Al Viro <viro@...iv.linux.org.uk>
CC: Linus Torvalds <torvalds@...ux-foundation.org>,
Eugenio Pérez <eperezma@...hat.com>,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
"Michael S. Tsirkin" <mst@...hat.com>,
Alexei Starovoitov <ast@...nel.org>,
Alexey Dobriyan <adobriyan@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Andrii Nakryiko <andrii@...nel.org>, Arnd Bergmann <arnd@...nel.org>,
Borislav Petkov <bp@...en8.de>,
Dan Williams <dan.j.williams@...el.com>,
Daniel Borkmann <daniel@...earbox.net>,
Dave Hansen <dave.hansen@...ux.intel.com>,
David Laight <David.Laight@...lab.com>,
David Lechner <dlechner@...libre.com>,
Dinh Nguyen <dinguyen@...nel.org>,
Eduard Zingerman <eddyz87@...il.com>,
Gatlin Newhouse <gatlin.newhouse@...il.com>,
Hao Luo <haoluo@...gle.com>, Ingo Molnar <mingo@...hat.com>,
Jakub Sitnicki <jakub@...udflare.com>,
Jan Hendrik Farr <kernel@...rr.cc>, Jason Wang <jasowang@...hat.com>,
Jiri Olsa <jolsa@...nel.org>,
John Fastabend <john.fastabend@...il.com>,
Jonathan Cameron <Jonathan.Cameron@...wei.com>,
Josh Poimboeuf <jpoimboe@...nel.org>, KP Singh <kpsingh@...nel.org>,
Kees Cook <kees@...nel.org>,
Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
Marc Herbert <Marc.Herbert@...ux.intel.com>,
Martin KaFai Lau <martin.lau@...ux.dev>,
Mateusz Guzik <mjguzik@...il.com>, Michal Luczaj <mhal@...x.co>,
Miguel Ojeda <ojeda@...nel.org>, Mykola Lysenko <mykolal@...com>,
NeilBrown <neil@...wn.name>, Peter Zijlstra <peterz@...radead.org>,
Przemek Kitszel <przemyslaw.kitszel@...el.com>,
Sami Tolvanen <samitolvanen@...gle.com>, Shuah Khan <shuah@...nel.org>,
Song Liu <song@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>,
Thomas Gleixner <tglx@...utronix.de>,
Thorsten Blum <thorsten.blum@...ux.dev>,
Uros Bizjak <ubizjak@...il.com>,
Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
Yafang Shao <laoar.shao@...il.com>, Ye Bin <yebin10@...wei.com>,
Yonghong Song <yonghong.song@...ux.dev>,
Yufeng Wang <wangyufeng@...inos.cn>, bpf@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org, linux-sparse@...r.kernel.org,
virtualization@...ts.linux.dev, x86@...nel.org
Subject: Re: [GIT PULL] __auto_type conversion for v6.19-rc1
On December 8, 2025 7:22:06 PM PST, Al Viro <viro@...iv.linux.org.uk> wrote:
>On Mon, Dec 08, 2025 at 04:28:11PM -0800, H. Peter Anvin wrote:
>> On December 8, 2025 4:25:19 PM PST, Al Viro <viro@...iv.linux.org.uk> wrote:
>> >On Mon, Dec 08, 2025 at 03:55:26PM -0800, H. Peter Anvin wrote:
>> >> Hi Linus,
>> >>
>> >> The following changes since commit c2f2b01b74be8b40a2173372bcd770723f87e7b2:
>> >>
>> >> Merge tag 'i3c/for-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux (2025-12-08 11:25:14 +0900)
>> >>
>> >> are available in the Git repository at:
>> >>
>> >> git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-auto.git
>> >>
>> >> for you to fetch changes up to branch auto-type-for-6.19
>> >> (4ecc26fa585216f98d71411ce182f9e823d94c8c):
>> >>
>> >> tools/virtio: replace "__auto_type" with "auto" (2025-12-08 15:32:15 -0800)
>> >
>> >Argh... teaching declaration parser in sparse to handle that is
>> >going to be fun, especially since there are corner cases where
>> >gcc and clang do not agree, even with --std=c23 --pedantic...
>>
>> Well, until sparse actually handles C23, this is just a macro. __auto_type is already in use.
>
>Just anticipating the joy of getting declaration parser to deal with that
>properly - there's bunch of fun corner cases where this macro wouldn't
>cut it. Sure, the underlying semantics can be mapped onto __auto_type,
>but the actual syntax is bloody awful, especially when you mix the
>typedefs into it.
>
>Speaking of other fun sparse stuff: __VA_OPT__ support needs to be added;
>I think I have it plotted down to reasonable details, will post in a day
>or two...
Yeah... the C committee even admitted they botched the spec; the intent was for it to work "exactly like gcc __auto_type"...
Powered by blists - more mailing lists