Hi Segher, Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxx> 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:
signature.asc
Description: PGP signature
