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@xxxxxxxxxxx> 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:
OpenPGP_signature
Description: OpenPGP digital signature
