> From: Marcin Jaczewski <marcinjaczewsk...@gmail.com> > Date: Wed, 10 May 2023 14:41:40 +0200 > > Did you even check if the compiler outpost is still correct?
Yes. > You mention "validations and verifications", do you do the same > with the new compiler? Yes. But that is a fraction of the effort needed when the source changes. > If you can't touch code then you SHOULD not upgrade the compiler. As I tried to explain, this is not really possible, unless the entire system is also kept without any changes, which is also impossible, because hardware gets old and needs to be replaced, and newer hardware doesn't support old systems. > Any big project (like Linux) shows these two rules are critical, > there were multiple cases of security bugs caused by subtle change > in behavior of the compiler. > Compiling very old code is lability if nobody knows how it should work and > nobody maintains it. Who can give you guarantee that the result is correct? > Very old programs should even by default reject new compilers by default until > someone does not check if it correctly compiles on new compilers. This is all true, but the same problems exist even if the programs don't use outdated C dialect. So these issues are independent, almost orthogonal to the issue at hand.
