Hi Martin, Jens, Joseph, On Thu, Aug 08, 2024 at 06:30:42PM GMT, Martin Uecker wrote: > Am Donnerstag, dem 08.08.2024 um 18:23 +0200 schrieb Jens Gustedt: > > As said, even if we don't consider this problematic because we are used to > > the mildly complex case distinction that you just exposed over several > > paragraphs, it doesn't mean that we should > > do it, nor does it mean that it would be beneficial for our users or for > > other implementations that would like to follow. > > > > And also as said, all other features in the standard, being types, typeof, > > or expressions, e.g offsetof, unreachable or other gnu extensions, don't > > have nor need this kind of syntax. > > > > We should be designing features for the future, not the past > > > While not problematic for parsing, I see now how the grammar becomes > better if we eliminated this quirk. Thanks! > > But we should then deprecate this for sizeof too.
How about having __lengthof__ behave like sizeof, but deprecate it in sizeof too? ISO C could accept only lengthof() with parens, and we could have it without them as a deprecated-on-arrival GNU extension. And then remove it from both at some point in the future. We could start by adding a -Wall warning for sizeof without parens, and promote it to an error a few versions later. Have a lovely day! Alex P.S.: I'm doing a whole-tree update to use __lengthof__ instead of open-coded sizeof divisons or macros based on it, and I've found several bugs already. I'll use this change to test the new operator in the entire code base, which should result in no regressions at all. That would be an interesting test suite. :) However, I advance that it will be painful to review that patch. -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
