I think we should be more aggressive here if we're going to spend this effort and move toward C18 instead, but I'll take what we can get here...

+1

I think we should be more aggressive here if we're going to spend this effort and move toward C18 instead, but I'll take what we can get here...

I'm not aware of significant language features that have been removed from C11 and C18 that GCC currently enables by default. Variable length arrays were made optional again in the standard (they were mandatory in C99). However, we build with -fstack-clash-protection, so there is considerably less pressure to remove them these days—and removal would go well beyond a mere porting effort anyway.

Some of it is a marketing thing and some of it is more of staying on top of things: it's weird (to me) that we spend the effort to go to C99 when GCC supports C11, C14, and C18. At the same time, GCC has been much more aggressive about updating C++ defaults. As you say, the updated C standards aren't too different from C99, so it should be easier to be more aggressive here.

+1

+1

+1

Some of it is a marketing thing and some of it is more of staying on top of things: it's weird (to me) that we spend the effort to go to C99 when GCC supports C11, C14, and C18. At the same time, GCC has been much more aggressive about updating C++ defaults. As you say, the updated C standards aren't too different from C99, so it should be easier to be more aggressive here.

I would be OK with being more aggressive in advancing the default C standard, but I am also OK with focusing on getting through the C99 removals first. Dealing with pre-ANSI declarations and bad or obsolete assumptions in build system checks will be a much more significant effort than anything needed to move to a later standard.

Either way, I’m happy to see this work happening while there is still plenty of time to do it with care.

+1

APPROVED (+5,0,-0)

Announced.