3 ms·

On the other hand, my company still has 25 year old C code that still compiles and works under the latest GCC, so...

by umvi 6y ago

jjnoakes 6y ago
And on the third hand companies I've worked with had 25-year-old C code bases that seemed to compile and mostly work, but mostly only with -O1 or lower, because they've had UB since the beginning of time but only more recent compiler optimizations reveal the underlying issues. And this old code is also written in a style (usually global variables and mixed concerns and years of sub-ideal bug fixes and patches) which makes it very hard to change or modernize (forget adding threads with all of this global mutable state). The only point being that old code may superficially work, but in many cases (in my experience) and regardless of language, it all has technical debt and needs work to keep it relevant.
- Drdrdrq 6y ago
  Does that matter? The code performs its duty and has for 25 years. If there are bugs in it they clearly haven't been important enough to be fixed. Technical debt? Maybe, but if noone is collecting the fees, who cares? If the situation changes and the original code suddenly becomes a basis for further development then that's a different thing. But cleaning up the code without clear benefit is a waste of resources. Hats off to original developers. Making code that serves its purpose for 25 years is quite an achievement.
  - hanselot 6y ago
    As we force people over a certain age into retirement, perhaps this should happen for code bases as well.
  - jjnoakes 6y ago
    The code gets bug fixes occasionally because things change (scaling past previous limits, changes in the environment, etc) and of course new features are required once in a while. So the debt usually can't be swept under any carpets. All code rots. If you are lucky to never need to fix it or change it, that's great, but that is (in my experience) extremely rare over time spans measured in decades. Sometimes a code base runs for decades not because it was particularly robust or well-written, but because it is too painful to replace it due to its complexity or the long ago loss of the knowledge needed to work on it.
geofft 6y ago
Most of our C code actually doesn't compile and work, unmodified, under the latest GCC. There are many new warnings, and like any professional C shop, we build with -Werror (or at least don't ignore the warnings). Since I help with maintaining the build infrastructure at work but I don't own any of the C code, I've proposed setting the new warnings to -Wno-error, but I've gotten pushback from the code owners, saying that they expect the new warnings to catch actual bugs and they want to deal with the fixes. Sure, there is some amount of C code from 25 years ago that works unchanged, but there's also a good bit of Python code from 25 years ago that works unchanged. (I just tried a few of the examples in the Python 1.3 tarball, released in 1995, and it seems like most of them will work with very minor changes.)
- zajio1am 6y ago
  If you compile with -Werror, then you are intentionally running it in no-backwards-compatibility mode. That is not really comparable with Python situation.
  - adrianN 6y ago
    Actually GCC is very careful about adding new warnings to Wall because of backwards compatibility. That's a reason why Wall doesn't actually contain all warnings.
  - geofft 6y ago
    Kind of, yes, but it's usually warning us about things that were actual bugs and reliance on unspecified/underspecified behavior that might be changing with newer optimizations.
    - simias 6y ago
      Not really in my experience. I maintain some relatively old codebases and the most common warnings for old code with newer GCC generally are: - Warnings recommending the use of parens in code like `if (a || b && c)`. The original code is (probably) not broken, it's just that GCC thinks that it's error-prone to write conditionals that way (I agree). There's also a similar warning for code like `while (a = foo())` where it asks you to add parens to make sure that you didn't use = instead of == by mistake. - Warnings for unmarked fall-throughs in `switch`. Again, not broken if the fall-through was intentional. That's a fairly new warning, so a lot of all code will trigger it. - Warnings for some const to non-const pointer conversions (in particular for literal strings in C++). There you could argue that the original code is bogus but as long as the pointer is not written to it's fine. Const-correctness wasn't really a thing in C and C++ for a long time, a lot of legacy code plays fast and loose with const qualifiers, but that doesn't necessarily mean that the code is broken. - Warnings about unused variables, in particular variables being written to but not read. As compiler get smarter they tend to catch more of those.
ramshanker 6y ago
Unfortunately, 30 year old Fortran code did not have such good luck in my company. VB6 compiler is hard to come by these days, and I have been tasked with rewriting it for "modern computers" ! The newest executable we have is from ~2008. Kudos to Microsoft to keep it running at least.
- leephillips 6y ago
  But 30 year old Fortran code should compile and run with no problems, unless it used something non-standard, shouldn’t it? In which case, the problem is not the evolving Fortran standard, but the use of non-standard compiler features. “The Fortran standards committee generally refuses to break backward compatibility when Fortran is updated. This is a good thing (take that, Python), and code written decades ago can still be compiled fine today.” -- http://degenerateconic.com/backward-compatibility/ http://degenerateconic.com/backward-compatibility/
hannob 6y ago
I don't buy that. Glibc and GCC introduce incompatible changes all the time.
- microcolonel 6y ago
  Not source-incompatible. Yes, if you have a binary linked against an old dynamic libc then you may have to give an alternative LD_LIBRARY_PATH or link it statically after the fact.
TheOtherHobbes 6y ago
Python users are not C users. C users typically understand compiler flags and build tooling. Some Python users understand compiler flags, but there's also a big community of scientific developers who just want a working language. Python 2 -> 3 created a lot of problems for them without making their lives easier or more productive. Perhaps Python 3 should have been called something entirely different, and P2 could have been handed over to a new set of maintainers who weren't going to EOL it.
microcolonel 6y ago
I've run 20 year old Linux binaries.
- abiogenesis 6y ago
  Err, that's because x86 architecture is backwards compatible; not because the language those binaries were originally written in is.
takeda 6y ago
Well, if you compile python 2 code using Cython you also can run it in Python 3. But seriously: - C never did such change, it doesn't make as much sense for it to do it since it is low level - C has a type static typing, so if they did, they could make compiler refuse to compile until types are right. Python has dynamic typing so these kinds of things show up when running, you can use something like mypy, but unlike C it is optional. BTW: I saw people using Go as an example that there was no need to add unicode support like in python, and simply store everything as UTF-8. Those people are forgetting that Go already has clear distinction between text and bytes (via string, bytes, runes types), how the language stores text is just an implementation detail, since normally there shouldn't there be access to the internal representation of the text anyway.

On the other hand, my company still has 25 year old C code that still compiles and works under the latest GCC, so...

by umvi 6y ago

On the other hand, my company still has 25 year old C code that still compiles and works under the latest GCC, so...

And on the third hand companies I've worked with had 25-year-old C code bases that seemed to compile and mostly work, but mostly only with -O1 or lower, because they've had UB since the beginning of time but only more recent compiler optimizations reveal the underlying issues. And this old code is also written in a style (usually global variables and mixed concerns and years of sub-ideal bug fixes and patches) which makes it very hard to change or modernize (forget adding threads with all of this global mutable state). The only point being that old code may superficially work, but in many cases (in my experience) and regardless of language, it all has technical debt and needs work to keep it relevant.

Drdrdrq 6y ago
Does that matter? The code performs its duty and has for 25 years. If there are bugs in it they clearly haven't been important enough to be fixed. Technical debt? Maybe, but if noone is collecting the fees, who cares? If the situation changes and the original code suddenly becomes a basis for further development then that's a different thing. But cleaning up the code without clear benefit is a waste of resources. Hats off to original developers. Making code that serves its purpose for 25 years is quite an achievement.
- hanselot 6y ago
  As we force people over a certain age into retirement, perhaps this should happen for code bases as well.
- jjnoakes 6y ago
  The code gets bug fixes occasionally because things change (scaling past previous limits, changes in the environment, etc) and of course new features are required once in a while. So the debt usually can't be swept under any carpets. All code rots. If you are lucky to never need to fix it or change it, that's great, but that is (in my experience) extremely rare over time spans measured in decades. Sometimes a code base runs for decades not because it was particularly robust or well-written, but because it is too painful to replace it due to its complexity or the long ago loss of the knowledge needed to work on it.

geofft 6y ago

Most of our C code actually doesn't compile and work, unmodified, under the latest GCC. There are many new warnings, and like any professional C shop, we build with -Werror (or at least don't ignore the warnings). Since I help with maintaining the build infrastructure at work but I don't own any of the C code, I've proposed setting the new warnings to -Wno-error, but I've gotten pushback from the code owners, saying that they expect the new warnings to catch actual bugs and they want to deal with the fixes. Sure, there is some amount of C code from 25 years ago that works unchanged, but there's also a good bit of Python code from 25 years ago that works unchanged. (I just tried a few of the examples in the Python 1.3 tarball, released in 1995, and it seems like most of them will work with very minor changes.)

zajio1am 6y ago
If you compile with -Werror, then you are intentionally running it in no-backwards-compatibility mode. That is not really comparable with Python situation.
- adrianN 6y ago
  Actually GCC is very careful about adding new warnings to Wall because of backwards compatibility. That's a reason why Wall doesn't actually contain all warnings.
- geofft 6y ago
  Kind of, yes, but it's usually warning us about things that were actual bugs and reliance on unspecified/underspecified behavior that might be changing with newer optimizations.
  - simias 6y ago
    Not really in my experience. I maintain some relatively old codebases and the most common warnings for old code with newer GCC generally are: - Warnings recommending the use of parens in code like `if (a || b && c)`. The original code is (probably) not broken, it's just that GCC thinks that it's error-prone to write conditionals that way (I agree). There's also a similar warning for code like `while (a = foo())` where it asks you to add parens to make sure that you didn't use = instead of == by mistake. - Warnings for unmarked fall-throughs in `switch`. Again, not broken if the fall-through was intentional. That's a fairly new warning, so a lot of all code will trigger it. - Warnings for some const to non-const pointer conversions (in particular for literal strings in C++). There you could argue that the original code is bogus but as long as the pointer is not written to it's fine. Const-correctness wasn't really a thing in C and C++ for a long time, a lot of legacy code plays fast and loose with const qualifiers, but that doesn't necessarily mean that the code is broken. - Warnings about unused variables, in particular variables being written to but not read. As compiler get smarter they tend to catch more of those.

ramshanker 6y ago

Unfortunately, 30 year old Fortran code did not have such good luck in my company. VB6 compiler is hard to come by these days, and I have been tasked with rewriting it for "modern computers" ! The newest executable we have is from ~2008. Kudos to Microsoft to keep it running at least.

leephillips 6y ago
But 30 year old Fortran code should compile and run with no problems, unless it used something non-standard, shouldn’t it? In which case, the problem is not the evolving Fortran standard, but the use of non-standard compiler features. “The Fortran standards committee generally refuses to break backward compatibility when Fortran is updated. This is a good thing (take that, Python), and code written decades ago can still be compiled fine today.” -- http://degenerateconic.com/backward-compatibility/ http://degenerateconic.com/backward-compatibility/

hannob 6y ago

I don't buy that. Glibc and GCC introduce incompatible changes all the time.

microcolonel 6y ago
Not source-incompatible. Yes, if you have a binary linked against an old dynamic libc then you may have to give an alternative LD_LIBRARY_PATH or link it statically after the fact.

TheOtherHobbes 6y ago

Python users are not C users. C users typically understand compiler flags and build tooling. Some Python users understand compiler flags, but there's also a big community of scientific developers who just want a working language. Python 2 -> 3 created a lot of problems for them without making their lives easier or more productive. Perhaps Python 3 should have been called something entirely different, and P2 could have been handed over to a new set of maintainers who weren't going to EOL it.

microcolonel 6y ago

I've run 20 year old Linux binaries.

abiogenesis 6y ago
Err, that's because x86 architecture is backwards compatible; not because the language those binaries were originally written in is.

takeda 6y ago

Well, if you compile python 2 code using Cython you also can run it in Python 3. But seriously: - C never did such change, it doesn't make as much sense for it to do it since it is low level - C has a type static typing, so if they did, they could make compiler refuse to compile until types are right. Python has dynamic typing so these kinds of things show up when running, you can use something like mypy, but unlike C it is optional. BTW: I saw people using Go as an example that there was no need to add unicode support like in python, and simply store everything as UTF-8. Those people are forgetting that Go already has clear distinction between text and bytes (via string, bytes, runes types), how the language stores text is just an implementation detail, since normally there shouldn't there be access to the internal representation of the text anyway.