> From: David Brown <david.br...@hesbynett.no> > Date: Thu, 11 May 2023 08:52:03 +0200 > > > But we are not talking about some random code that just happened to > > slip through cracks as a side effect of the particular implementation. > > We are talking about code that was perfectly valid, had well-defined > > semantics, and produced a working program. I don't care about the > > former; I do care about the latter. > > How would you know that the code had perfectly valid, well-defined > semantics?
The programmer who wants to keep that code will know (or at least he/she should). > I've had the dubious pleasure of trying to maintain and update code > where the previous developer had a total disregard for things like > function declaration - he really did dismiss compiler complaints about > implicit function declarations as "only a warning". The program worked > as he expected, for the most part. But that was despite many functions > being defined in one part of the code with one set of parameters (number > and type), and called elsewhere with a different set - sometimes more > than one selection of parameter types in the same C file. In this situation, where you take responsibility of a program someone else wrote, and consider its code to be badly or unsafely written, TRT is to modify the program to use more modern techniques that you understand and support. Compiler warnings and your own knowledge of valid C will guide you in this. My problem is not with the situation you described, it's with a case that the "previous" maintainer remains the current maintainer, and/or for some reason rewriting the code is either impractical or not the best alternative for other reasons. > If a compiler is required to continue to compile every program that a > previous version compiled, where the developer was satisfied that the > program worked as expected, then the only way to guarantee that is to > stop changing and improving gcc. There should be no such requirement. If addition of new features or support for the evolving standards mean GCC must break old UB-style code, that is fully justified and understandable. What is _not_ justified, IMO, is breaking old programs without any such technical reasons, just because we think they are better off broken. IOW, as long as being able to compile those old programs in the same old way doesn't get in the way of being able to compile valid programs, the old code should remain unbroken. > I agree that accepting fully correct programs written in K&R C would not > limit the future development of gcc. But how many programs written in > K&R C, big enough and important enough to be relevant today, are fully > correct? I'd be surprised if you needed more than one hand to count > them. For the purpose of this discussion, the "how many" question is not interesting. If there is an incorrect K&R program, the results and consequences of this incorrectness are on the maintainers of those programs, not on the GCC team. If some of those incorrect programs break because of some valid development in GCC, so be it. But the decision to make a warning to be an error is not dictated by GCC development and its needs to compile valid programs, it is dictated by other, largely non-technical considerations. I'm saying that these considerations are not reasons good enough for breaking those old programs. > Continuing to give developers what they expect, rather than what the > standards (and gcc extensions) guarantee, is always an issue for > backwards compatibility. Each new version of gcc can, and sometimes > does, "break" old code - code that people relied on before, but was > actually incorrect. This is unavoidable if gcc is to progress. It is indeed unavoidable, and a fact of life. All I'm saying is that we as developers should try to minimize these breakages as much as possible, without hampering new developments too much. > That is why I suggested that a flag such as "-fold-code" that enables > long outdated syntaxes should also disable the kind of optimisations > that are most likely to cause issues with old code, and should enable > semantics chances to match likely assumptions in such code. I don't > believe in the existence of correct K&R C code - but I /do/ believe in > the importance of some K&R C code despite its errors. The problem, as you well know, is that when a large software package fails to build, it is not immediately clear what is the reason for that. We here discuss a single such reason, but in reality no one tells you that the build fails because the new version of GCC now rejects code it accepted in the previous version. The upgrade that installed the new GCC will typically update dozens of other system components, many of which could be the culprit. Just understanding that the reason is GCC and its rejection of certain constructs is a job that can take hours full of frustration and hair-pulling. This is what I think we as developers need to avoid as much as possible. Once you understand the reason, fixing it with a compiler switch might be relatively simple, at least in many cases, but the problem is the effort it takes to realize that the option is all you need. There are no good ways of making that option discoverable enough to make this process significantly easier. > "Knowing what you are talking about" is not the same thing as being > correct. But I think our key disagreements here are a matter of > opinion, not fact - "correct" is not an appropriate term for an opinion. > We are looking at things from a different viewpoint, which will > naturally be coloured by our experiences. So to be clear, I fully > understand your opinion and viewpoint here - I just don't think it > should be the philosophy for gcc going forward. > > It is a good thing that we can express and exchange these opinions. > Ultimately, I suppose it is the gcc steering committee that will decide > (the length of this thread suggests it is too important for developers > alone). I don't know about you, but I know that /I/ have absolutely no > say or vote in the process - I am not involved in gcc development. Neither am I. I'm investing my scarce time in this discussion in the hope to convince the GCC development team and the steering committee to see the downside of the proposal to reject those old programs where GCC can still compile them without affecting modern valid C programs. I think a warning is good enough in those case. > However, I think it is good that a wide variety of people are able to > give their thoughts, ideas and opinions, and I hope it helps the people > who will make the decisions in the end. Agreed.
