Why not break it up into variables or functions so that the logic can be followed while reducing the likelihood that a bug creeps in? What is the excuse for horrible code like this?
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...)
Edit: also reading the wiki, they are fully aware how bad this code is.
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.
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.
Any time this if statement has been edited, it was clearly faster to simply add to the existing one than to refactor the whole thing. Sometimes it makes sense to take that extra time to refactor code when you happen to be working on it anyway... and sometimes there's something else more pressing to do.