If they'd spent all their time needlessly fixing what ain't broke, gcc would've gone the way of GNU/Hurd.
I don't trust anyone - myself included - writing code 1/10th as convoluted, age-of-product be damned. Code is not wine, old doesn't mean good. Neither do the maintainers, methinks: Looking at blame shows some refactoring.
> If they'd spent all their time needlessly refactoring, gcc would've gone the way of GNU/Hurd.
And the lack of needful refactoring may very well send it the way of COBOL - with everyone merely wishing it had gone the way of GNU/Hurd. I've seen clang and LLVM replace gcc in both of my vendor toolchains that used gcc - suggesting they've already wished and then done something about that wish.
(Either that or licensing, but code like this stomps on the scales a bit...)
It's also got prototypes that made it into production, ball of mud designs that encourage usage bugs, and C++ thrown together by that short lived intern who took a few Java classes, wrote everything assuming there was a garbage collector around, and took great care to avoid class trees with less than 3 layers of inheritance lest he be shamed for lack of 1337ness... then topped it off with a few __try/__catch blocks to deal with that one rare crash that nobody could find a repro case for.
Re-implementing bug fixes is a toll... sometimes a very worthwhile one, though.
Edit: also reading the wiki, they are fully aware how bad this code is.
If that corner case manifests as a bug in OpenSSL, it is by definition at least as bad as a bug in OpenSSL.
I'm not convinced that's true.
LRA is by all appearances infinitely more maintainable.