* Deprecation of C89? @ 2023-06-01 22:50 Alejandro Colomar 2023-06-02 0:26 ` Ian Lance Taylor 2023-06-02 12:09 ` David Brown 0 siblings, 2 replies; 9+ messages in thread From: Alejandro Colomar @ 2023-06-01 22:50 UTC (permalink / raw) To: gcc-help [-- Attachment #1.1: Type: text/plain, Size: 888 bytes --] Hi! I was just wondering if there are any plans to drop support of C89 (and gnu89) at any point in the future. I didn't find any such discussion in the mailing list. That change would probably break very ancient code (implicit int, implicit function declarations, ...), but such code is very likely to have been updated in the last several decades to be at least compatible with C99, so I don't expect that much breakage. Most big projects have already migrated, with only a few still resisting (curl comes to mind). But again, I think they use a subset that would compile under C99 with little or no modification. I guess supporting C89 keeps a lot of extra complexity in GCC's source code itself, and maybe even hinders some optimizations. Cheers, Alex -- <http://www.alejandro-colomar.es/> GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Deprecation of C89? 2023-06-01 22:50 Deprecation of C89? Alejandro Colomar @ 2023-06-02 0:26 ` Ian Lance Taylor 2023-06-02 3:05 ` Alejandro Colomar 2023-06-02 12:09 ` David Brown 1 sibling, 1 reply; 9+ messages in thread From: Ian Lance Taylor @ 2023-06-02 0:26 UTC (permalink / raw) To: Alejandro Colomar; +Cc: gcc-help On Thu, Jun 1, 2023 at 3:52 PM Alejandro Colomar via Gcc-help <gcc-help@gcc.gnu.org> wrote: > > I was just wondering if there are any plans to drop support of C89 (and > gnu89) at any point in the future. I didn't find any such discussion in > the mailing list. > > That change would probably break very ancient code (implicit int, implicit > function declarations, ...), but such code is very likely to have been > updated in the last several decades to be at least compatible with C99, so > I don't expect that much breakage. > > Most big projects have already migrated, with only a few still resisting > (curl comes to mind). But again, I think they use a subset that would > compile under C99 with little or no modification. > > I guess supporting C89 keeps a lot of extra complexity in GCC's source code > itself, and maybe even hinders some optimizations. We just had a long thread in which several people objected strongly to just making the use of certain old C constructs an error by default (https://gcc.gnu.org/pipermail/gcc/2023-May/241264.html). If there are strong objections to making these constructs into errors, I think there would be even stronger objections to removing support for C89 entirely. Ian ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Deprecation of C89? 2023-06-02 0:26 ` Ian Lance Taylor @ 2023-06-02 3:05 ` Alejandro Colomar 2023-06-02 6:37 ` Arsen Arsenović 0 siblings, 1 reply; 9+ messages in thread From: Alejandro Colomar @ 2023-06-02 3:05 UTC (permalink / raw) To: Ian Lance Taylor, Florian Weimer, Sam James; +Cc: gcc-help [-- Attachment #1.1: Type: text/plain, Size: 4997 bytes --] Hi Ian, Florian, Sam, On 6/2/23 02:26, Ian Lance Taylor wrote: > On Thu, Jun 1, 2023 at 3:52 PM Alejandro Colomar via Gcc-help > <gcc-help@gcc.gnu.org> wrote: >> >> I was just wondering if there are any plans to drop support of C89 (and >> gnu89) at any point in the future. I didn't find any such discussion in >> the mailing list. >> >> That change would probably break very ancient code (implicit int, implicit >> function declarations, ...), but such code is very likely to have been >> updated in the last several decades to be at least compatible with C99, so >> I don't expect that much breakage. >> >> Most big projects have already migrated, with only a few still resisting >> (curl comes to mind). But again, I think they use a subset that would >> compile under C99 with little or no modification. >> >> I guess supporting C89 keeps a lot of extra complexity in GCC's source code >> itself, and maybe even hinders some optimizations. > > We just had a long thread in which several people objected strongly to > just making the use of certain old C constructs an error by default > (https://gcc.gnu.org/pipermail/gcc/2023-May/241264.html). If there > are strong objections to making these constructs into errors, I think > there would be even stronger objections to removing support for C89 > entirely. Thanks for pointing to that. I'll +1 to Florian's proposal, and add something. C89 is basically C99 with added broken stuff such as implicit int, implicit functions, and no stdint. Not much more than that. gnu89 also includes the "other" inline. I would be happy with adding an optable-out error for those as a first step, and one or two releases later completely kill C89. About doing something in the distros if upstream GCC doesn't do it: I believe breaking a package in Fedora, Debian, and Gentoo will be enough that most upstream projects will fix their bugs. I don't think packagers will have to do it themselves. I believe that patching distro's GCC to enable -Werror=... would already be a great step. I've have to deal with programmers that lived in a cave for the last 30 years, and believe that there's no issue with having a pointer 2 past the end of an array, as long as you "restore" it by subtracting 2 afterwards, and worse stuff, because it just works. As was said in that other thread, if GCC generates "working" code, they'll defend that code. Having an error by default for the most broken stuff would probably help them see the light. The only issue which can't be solved is compiling unmaintained software that was written 30 years ago. But if one is doing that, they probably also have a system with a compiler written 30 years ago. I don't see why anyone would want to compile K&R code in bleeding edge systems. A VM is always available. They can even get an old GCC version. Another point is that since this year, companies are already stopping using C because of being unsafe. I don't believe C being unsafe, but C89 definitely *is*. I don't think keeping it around is doing anyone a favor. In my job, they're requiring Rust for newly written programs. I hope we help prevent continuing down that road. Florian, Sam, may I suggest that you patch/configure your GCC to have those few -Werror=... enabled by default? After one release with that in Fedora and Gentoo, I guess it will be easier to merge it into upstream GCC. And a similar thing but a year later could be done with C89. I already ported shadow[1] from pre-C89 code to require C11 and POSIX.1-2008, and it was relatively easy. I am now porting zlib[2] from pre-C89 code to require C89 (I wish I could raise that at least to C99, but I'm not sure how much receptive the maintainer will be without the compiler setting on fire). [1]: <https://github.com/shadow-maint/shadow/issues/600> <https://github.com/shadow-maint/shadow/pull/477> <https://github.com/shadow-maint/shadow/pull/479> <https://github.com/shadow-maint/shadow/pull/480> <https://github.com/shadow-maint/shadow/pull/481> <https://github.com/shadow-maint/shadow/pull/489> <https://github.com/shadow-maint/shadow/pull/574> <https://github.com/shadow-maint/shadow/pull/601> <https://github.com/shadow-maint/shadow/pull/602> <https://github.com/shadow-maint/shadow/pull/615> <https://github.com/shadow-maint/shadow/pull/616> <https://github.com/shadow-maint/shadow/pull/617> POSIX.1-2008 was a bit more complex, but C99 should be trivial. The result was a much cleaner code base, with a lot less cpp(1), and a net removal of thousands of lines of code. While cleaning up the code, several hidden bugs were made shallow, and thus fixed. [2]: <https://github.com/madler/zlib/pull/817> Thanks! Alex > > Ian -- <http://www.alejandro-colomar.es/> GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Deprecation of C89? 2023-06-02 3:05 ` Alejandro Colomar @ 2023-06-02 6:37 ` Arsen Arsenović 2023-06-02 12:50 ` Segher Boessenkool 0 siblings, 1 reply; 9+ messages in thread From: Arsen Arsenović @ 2023-06-02 6:37 UTC (permalink / raw) To: Alejandro Colomar; +Cc: Ian Lance Taylor, Florian Weimer, Sam James, gcc-help [-- Attachment #1: Type: text/plain, Size: 5297 bytes --] Hi Alex, Alejandro Colomar via Gcc-help <gcc-help@gcc.gnu.org> writes: > Thanks for pointing to that. I'll +1 to Florian's proposal, and add > something. > > C89 is basically C99 with added broken stuff such as implicit int, > implicit functions, and no stdint. Not much more than that. gnu89 > also includes the "other" inline. I would be happy with adding an > optable-out error for those as a first step, and one or two releases > later completely kill C89. I don't think killing C89 is very useful. As you said, it's not too different to C99; however, we shouldn't be promoting its deficiencies into newer language standards (but you've seen the thread on that :-) ). > About doing something in the distros if upstream GCC doesn't do it: > I believe breaking a package in Fedora, Debian, and Gentoo will be > enough that most upstream projects will fix their bugs. I don't > think packagers will have to do it themselves. I believe that > patching distro's GCC to enable -Werror=... would already be a great > step. I'm not sure it's a good idea to change behavior away from upstream decisions in our downstream. Keep in mind, though, that we (Gentoo) have CI infrastructure and developers already testing with stricter flags. > I've have to deal with programmers that lived in a cave for the last > 30 years, and believe that there's no issue with having a pointer 2 > past the end of an array, as long as you "restore" it by subtracting > 2 afterwards, and worse stuff, because it just works. As was said in > that other thread, if GCC generates "working" code, they'll defend > that code. Having an error by default for the most broken stuff > would probably help them see the light. C89 (similar to GNU C 89) doesn't prevent writing correct code, though, even if it lacks some facilities. > The only issue which can't be solved is compiling unmaintained > software that was written 30 years ago. But if one is doing that, > they probably also have a system with a compiler written 30 years > ago. I don't see why anyone would want to compile K&R code in > bleeding edge systems. A VM is always available. They can even > get an old GCC version. Sadly, some modern codebases are C89 (libvp8 comes to mind.. don't ask, because I don't know why either ;) ). But, old codebases can be written in a way which is correct, so I don't see why removing C89 would help there. > Another point is that since this year, companies are already > stopping using C because of being unsafe. I don't believe C being > unsafe, but C89 definitely *is*. I don't think keeping it around is > doing anyone a favor. In my job, they're requiring Rust for newly > written programs. I hope we help prevent continuing down that road. I'm afraid this won't convince folks. People treat C++ the same as pre-standard C, even though it's quite easy to write code that prevents errors in C++ in a way similar to Rust. I also don't see a significant difference between C89 (and some -Werror flags) and C99 in this regard. > Florian, Sam, may I suggest that you patch/configure your GCC to have > those few -Werror=... enabled by default? After one release with > that in Fedora and Gentoo, I guess it will be easier to merge it into > upstream GCC. And a similar thing but a year later could be done > with C89. We'd like to do this in GCC 14 anyway (in 99+). > I already ported shadow[1] from pre-C89 code to require C11 and > POSIX.1-2008, and it was relatively easy. I am now porting zlib[2] > from pre-C89 code to require C89 (I wish I could raise that at least > to C99, but I'm not sure how much receptive the maintainer will be > without the compiler setting on fire). > > [1]: <https://github.com/shadow-maint/shadow/issues/600> > <https://github.com/shadow-maint/shadow/pull/477> > <https://github.com/shadow-maint/shadow/pull/479> > <https://github.com/shadow-maint/shadow/pull/480> > <https://github.com/shadow-maint/shadow/pull/481> > <https://github.com/shadow-maint/shadow/pull/489> > <https://github.com/shadow-maint/shadow/pull/574> > <https://github.com/shadow-maint/shadow/pull/601> > <https://github.com/shadow-maint/shadow/pull/602> > <https://github.com/shadow-maint/shadow/pull/615> > <https://github.com/shadow-maint/shadow/pull/616> > <https://github.com/shadow-maint/shadow/pull/617> Thank you! This work is quite valuable. I do suspect a more conservative response from zlib, though. > POSIX.1-2008 was a bit more complex, but C99 should be trivial. > > The result was a much cleaner code base, with a lot less cpp(1), > and a net removal of thousands of lines of code. While cleaning > up the code, several hidden bugs were made shallow, and thus > fixed. > > [2]: <https://github.com/madler/zlib/pull/817> > > Thanks! > Alex I'd like to note that I'm not advocating for the prolonged use of C89, just for keeping compatibility where the cost is low (and I strongly oppose forward-porting the messy parts of C89 into C99+ as GCC has done so far). (PS: this topic is likely more appropriate for gcc@gcc.gnu.org) Have a lovely day :) -- Arsen Arsenović [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 381 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Deprecation of C89? 2023-06-02 6:37 ` Arsen Arsenović @ 2023-06-02 12:50 ` Segher Boessenkool 2023-06-02 18:52 ` Arsen Arsenović 0 siblings, 1 reply; 9+ messages in thread From: Segher Boessenkool @ 2023-06-02 12:50 UTC (permalink / raw) To: Arsen Arsenović Cc: Alejandro Colomar, Ian Lance Taylor, Florian Weimer, Sam James, gcc-help Hi! On Fri, Jun 02, 2023 at 08:37:30AM +0200, Arsen Arsenović via Gcc-help wrote: > Alejandro Colomar via Gcc-help <gcc-help@gcc.gnu.org> writes: > > C89 is basically C99 with added broken stuff such as implicit int, > > implicit functions, and no stdint. Not "added" of course. This kind of misrepresentation hurts your arguments. > I don't think killing C89 is very useful. As you said, it's not too > different to C99; however, we shouldn't be promoting its deficiencies > into newer language standards (but you've seen the thread on that :-) ). We would first have to kill off support for K&R C. Which isn't going to happen any time soon either: it is there, maintenance cost is minimal, removing it would not buy us much at all (because we need to keep most of what you hope we might remove for supporting other languages). > > About doing something in the distros if upstream GCC doesn't do it: > > I believe breaking a package in Fedora, Debian, and Gentoo will be > > enough that most upstream projects will fix their bugs. I don't > > think packagers will have to do it themselves. I believe that > > patching distro's GCC to enable -Werror=... would already be a great > > step. > > I'm not sure it's a good idea to change behavior away from upstream > decisions in our downstream. Keep in mind, though, that we (Gentoo) > have CI infrastructure and developers already testing with stricter > flags. It already is painful that some distros ship severely patched GCC and their users complain to us. Changing defaults is WRONG: if people do not just ignore you after that lunacy everyone else can not rely on the default anymore, and has to specify the choice every time. > > Another point is that since this year, companies are already > > stopping using C because of being unsafe. That is just a fad. All computer languages are "unsafe", some are easier to make mistakes in than others, but experience and habit and yes, *good taste* of the programmer matter hundreds of times more. >> I don't believe C being > > unsafe, but C89 definitely *is*. I don't think keeping it around is > > doing anyone a favor. In my job, they're requiring Rust for newly > > written programs. I hope we help prevent continuing down that road. > > I'm afraid this won't convince folks. People treat C++ the same as > pre-standard C, It has as many sharp edges, yes! > I also don't see a significant difference between C89 (and some -Werror > flags) and C99 in this regard. -Werror is always *WRONG*. The compiler should not refuse to compile perfectly valid code. It only makes people annoyed and use "-w" more. People not reading the compiler warnings is a people problem. Solve that the usual way you do that in your organisation: gentle nudging, public shaming, whatever you do -- but do not punish innocent bystanders. (It is fine to change GCC to do an error instead of a warning when it has detected an actual problem, but not when it isn't sure, and never using -Werror.) > I'd like to note that I'm not advocating for the prolonged use of C89, > just for keeping compatibility where the cost is low (and I strongly > oppose forward-porting the messy parts of C89 into C99+ as GCC has done > so far). Yup. The cost (to users, including ourselves) from removing C90 far outweighs its benefits (mostly to GCC developers, and those benefits are extremely minor anyway). It is *normal* to deal with code twenty or thirty or more years old. Useful code has a long lifetime. </rant> :-) Segher ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Deprecation of C89? 2023-06-02 12:50 ` Segher Boessenkool @ 2023-06-02 18:52 ` Arsen Arsenović 2023-06-02 19:22 ` Xi Ruoyao 0 siblings, 1 reply; 9+ messages in thread From: Arsen Arsenović @ 2023-06-02 18:52 UTC (permalink / raw) To: Segher Boessenkool Cc: Alejandro Colomar, Ian Lance Taylor, Florian Weimer, Sam James, gcc-help [-- Attachment #1: Type: text/plain, Size: 4781 bytes --] Hi Segher, Segher Boessenkool <segher@kernel.crashing.org> writes: > Hi! > > On Fri, Jun 02, 2023 at 08:37:30AM +0200, Arsen Arsenović via Gcc-help wrote: >> Alejandro Colomar via Gcc-help <gcc-help@gcc.gnu.org> writes: >> > C89 is basically C99 with added broken stuff such as implicit int, >> > implicit functions, and no stdint. > > Not "added" of course. This kind of misrepresentation hurts your > arguments. > >> I don't think killing C89 is very useful. As you said, it's not too >> different to C99; however, we shouldn't be promoting its deficiencies >> into newer language standards (but you've seen the thread on that :-) ). > > We would first have to kill off support for K&R C. Which isn't going to > happen any time soon either: it is there, maintenance cost is minimal, > removing it would not buy us much at all (because we need to keep most > of what you hope we might remove for supporting other languages). I agree. Defaults can hurt, explicitly requested legacy support doesn't (notwithstanding maintenance overhead and such). >> > About doing something in the distros if upstream GCC doesn't do it: >> > I believe breaking a package in Fedora, Debian, and Gentoo will be >> > enough that most upstream projects will fix their bugs. I don't >> > think packagers will have to do it themselves. I believe that >> > patching distro's GCC to enable -Werror=... would already be a great >> > step. >> >> I'm not sure it's a good idea to change behavior away from upstream >> decisions in our downstream. Keep in mind, though, that we (Gentoo) >> have CI infrastructure and developers already testing with stricter >> flags. > > It already is painful that some distros ship severely patched GCC and > their users complain to us. Changing defaults is WRONG: if people do > not just ignore you after that lunacy everyone else can not rely on the > default anymore, and has to specify the choice every time. > >> > Another point is that since this year, companies are already >> > stopping using C because of being unsafe. > > That is just a fad. All computer languages are "unsafe", some are > easier to make mistakes in than others, but experience and habit and > yes, *good taste* of the programmer matter hundreds of times more. > >>> I don't believe C being >> > unsafe, but C89 definitely *is*. I don't think keeping it around is >> > doing anyone a favor. In my job, they're requiring Rust for newly >> > written programs. I hope we help prevent continuing down that road. >> >> I'm afraid this won't convince folks. People treat C++ the same as >> pre-standard C, > > It has as many sharp edges, yes! ... but some extra rubber feet in the box ;) (and a better type system) >> I also don't see a significant difference between C89 (and some -Werror >> flags) and C99 in this regard. > > -Werror is always *WRONG*. The compiler should not refuse to compile > perfectly valid code. It only makes people annoyed and use "-w" more. I was referring to -Werror=implicit-function-declaration, -Werror=implicit-int, -Werror=incompatible-function-pointer-types, and -Werror=strict-prototypes, which don't share the usual problems of -Werror (by being explicit, not something that's likely to change, and reasonable practice IMO :-) ). But, at any rate, the thing I was getting at here is that C89 is not very fundamentally different to C99 (in the ways in which C++ *can* be). > People not reading the compiler warnings is a people problem. Solve > that the usual way you do that in your organisation: gentle nudging, > public shaming, whatever you do -- but do not punish innocent > bystanders. I agree. We have a tree-wide policy of disabling -Werror for that reason. > (It is fine to change GCC to do an error instead of a warning when it > has detected an actual problem, but not when it isn't sure, and never > using -Werror.) I believe that qualifies the above as fine :-), perhaps the only one which might pose an actual problem (rather than diagnosing one) is -Wincompatible-function-pointer-types, when some FP punting is involved. >> I'd like to note that I'm not advocating for the prolonged use of C89, >> just for keeping compatibility where the cost is low (and I strongly >> oppose forward-porting the messy parts of C89 into C99+ as GCC has done >> so far). > > Yup. The cost (to users, including ourselves) from removing C90 far > outweighs its benefits (mostly to GCC developers, and those benefits are > extremely minor anyway). > > It is *normal* to deal with code twenty or thirty or more years old. > Useful code has a long lifetime. > > </rant> > > :-) :-) Have a lovely day! -- Arsen Arsenović [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 381 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Deprecation of C89? 2023-06-02 18:52 ` Arsen Arsenović @ 2023-06-02 19:22 ` Xi Ruoyao 2023-06-02 19:45 ` Arsen Arsenović 0 siblings, 1 reply; 9+ messages in thread From: Xi Ruoyao @ 2023-06-02 19:22 UTC (permalink / raw) To: Arsen Arsenovi�0�4, Segher Boessenkool Cc: Alejandro Colomar, Ian Lance Taylor, Florian Weimer, Sam James, gcc-help On Fri, 2023-06-02 at 20:52 +0200, Arsen Arsenović via Gcc-help wrote: > I was referring to -Werror=implicit-function-declaration, > -Werror=implicit-int, -Werror=incompatible-function-pointer-types, and > -Werror=strict-prototypes, which don't share the usual problems of > -Werror (by being explicit, not something that's likely to change, and > reasonable practice IMO :-) ). -Werror=strict-prototypes is too strict IMO. It will even break: int test() { return 0; } But the entire point of the C2X change about the prototype w/o a parameter list is to make such thing reasonable, isn't it? I guess we actually want a new warning option, like: extern int f(); // ok int g() { return f(); } // ok int h() { return f(1, 2); } // { dg-warning "the usage of non-strict prototype will be rejected by C2x" } -- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Deprecation of C89? 2023-06-02 19:22 ` Xi Ruoyao @ 2023-06-02 19:45 ` Arsen Arsenović 0 siblings, 0 replies; 9+ messages in thread From: Arsen Arsenović @ 2023-06-02 19:45 UTC (permalink / raw) To: Xi Ruoyao Cc: Segher Boessenkool, Alejandro Colomar, Ian Lance Taylor, Florian Weimer, Sam James, gcc-help [-- Attachment #1: Type: text/plain, Size: 1117 bytes --] Xi Ruoyao <xry111@xry111.site> writes: > On Fri, 2023-06-02 at 20:52 +0200, Arsen Arsenović via Gcc-help wrote: >> I was referring to -Werror=implicit-function-declaration, >> -Werror=implicit-int, -Werror=incompatible-function-pointer-types, and >> -Werror=strict-prototypes, which don't share the usual problems of >> -Werror (by being explicit, not something that's likely to change, and >> reasonable practice IMO :-) ). > > -Werror=strict-prototypes is too strict IMO. It will even break: > > int test() { return 0; } Indeed, but I tend not to mind this in my code (falling into the latter clause in parentheses above). > But the entire point of the C2X change about the prototype w/o a > parameter list is to make such thing reasonable, isn't it? > > I guess we actually want a new warning option, like: > > extern int f(); // ok > int g() { return f(); } // ok > int h() { return f(1, 2); } // { dg-warning "the usage of non-strict prototype will be rejected by C2x" } There might be relevant discussion on https://gcc.gnu.org/PR108694. -- Arsen Arsenović [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 381 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Deprecation of C89? 2023-06-01 22:50 Deprecation of C89? Alejandro Colomar 2023-06-02 0:26 ` Ian Lance Taylor @ 2023-06-02 12:09 ` David Brown 1 sibling, 0 replies; 9+ messages in thread From: David Brown @ 2023-06-02 12:09 UTC (permalink / raw) To: gcc-help On 02/06/2023 00:50, Alejandro Colomar via Gcc-help wrote: > Hi! > > I was just wondering if there are any plans to drop support of C89 (and > gnu89) at any point in the future. I didn't find any such discussion in > the mailing list. > > That change would probably break very ancient code (implicit int, implicit > function declarations, ...), but such code is very likely to have been > updated in the last several decades to be at least compatible with C99, so > I don't expect that much breakage. > > Most big projects have already migrated, with only a few still resisting > (curl comes to mind). But again, I think they use a subset that would > compile under C99 with little or no modification. > > I guess supporting C89 keeps a lot of extra complexity in GCC's source code > itself, and maybe even hinders some optimizations. > > Cheers, > Alex > The majority of the C89/C90 -> C99 changes were additions to the language, so that code which was valid C89/C90 would be equally valid and have the same semantics when viewed as C99. Some things, such as implicit int, were already deprecated (or obsolescent - I forget which) in C89/C90 and removed in C99. But there are other things that changed, such as the type of some constants. And the addition of new identifiers to some of the standard headers could conflict with user code. It is rare that code which compiles with "-std=c90" would not also compile with "-std=c99" and have identical semantics, but it definitely can happen. And backwards compatibility with existing code is a very strong argument for any decision about C tools. And in some fields, C89/C90 (or "ANSI C", as it is often called, somewhat inaccurately) is still the standard. People working with such code want to use "-std=c90 -Wpedantic" to be as sure as they can be that the code will be usable with every C compiler, even old or obscure ones. David ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2023-06-02 19:55 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-06-01 22:50 Deprecation of C89? Alejandro Colomar 2023-06-02 0:26 ` Ian Lance Taylor 2023-06-02 3:05 ` Alejandro Colomar 2023-06-02 6:37 ` Arsen Arsenović 2023-06-02 12:50 ` Segher Boessenkool 2023-06-02 18:52 ` Arsen Arsenović 2023-06-02 19:22 ` Xi Ruoyao 2023-06-02 19:45 ` Arsen Arsenović 2023-06-02 12:09 ` David Brown
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).