On 5/12/25 2:25 PM, Elliott Mitchell wrote: > On Mon, May 12, 2025 at 03:00:18PM +0200, Jan Beulich wrote: >> On 12.05.2025 14:09, Andrew Cooper wrote: >>> >>> Now for the (new) controversial part. Since sending this, Linux has >>> decided to just #define auto __auto_type for C < 23, in order to start >>> writing C23 compatible code from now. It's more succinct, and has >>> better longevity. >>> >>> We might want to consider the same, although it will introduce a new >>> example of defining a keyword, which we'd have to call out in the >>> MISRA/Eclair config. >> >> I'm not outright opposed, as I don't think we use "auto" with its >> original semantics, but it feels somewhat odd. > > Problem is "auto" already has a defined meaning in C.Having this will > subtly break contributions from authors who weren't familiar with > everything in Xen's headers. For anyone who does anything with projects > besides Xen this will encourage bad habits. > > I believe many projects have a rule of *never* #define C keywords. I'm > surprised such made it into the Linux kernel. I expect it will be ripped > out in the near future. > > MISRA *doesn't* absolutely forbid this?
I'm no expert on the C standard, but my understanding is that "auto" was redundant starting in C89, so it is almost entirely unused. C++11 and later *do* heavily use "auto", and they use it for roughly the same purpose as C23 does, so I suspect that contributors are far more likely to be familiar with the C23 "auto" than they are with the pre-C23 version, -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
