Hi Alex, Alejandro Colomar via Gcc-help <gcc-help@xxxxxxxxxxx> 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@xxxxxxxxxxx) Have a lovely day :) -- Arsen Arsenović
Attachment:
signature.asc
Description: PGP signature
