#2889 Change: Porting Fedora to Modern C
Closed: Accepted 13 days ago by zbyszek. Opened a month ago by bcotton.

Back in 1999, a new revision of the C standard removed several backwards compatibility features. However, GCC still accepts these obsolete constructs by default. Support for these constructs is confusing to programmers and potentially affect GCC's ability to implement features from future C standards. It is expected that a future GCC version (likely GCC 14) will disable support for these legacy language constructs by default. The goal of this change is to prepare Fedora for this transition.

Owners, do not implement this work until the FESCo vote has explicitly ended.
The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed.
See the FESCo ticket policy and the Changes policy for more information.


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.

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

Metadata Update from @churchyard:
- Issue tagged with: pending announcement

18 days ago

Metadata Update from @zbyszek:
- Issue untagged with: pending announcement
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

13 days ago

Login to comment on this ticket.

Metadata