3 ms·
What you should learn about that leak is that: - Bad code lives in the dark. Code that is visible by many others never looks like this. - Shame is good to som
by 29athrowaway 5y ago
What you should learn about that leak is that:
- Bad code lives in the dark. Code that is visible by many others never looks like this.
- Shame is good to some extent. It keeps people accountable.
- When closing tickets is more important than actually making real improvements, code looks like this.
- shadowgovt 5y ago> Bad code lives in the dark. Code that is visible by many others never looks like this. As someone who has attempted to make a modification to OpenSSL, I feel like this claim needs a big old "[citation needed]" banner.
- 29athrowaway 5y agoOpenSSL code does not look like the code cited in the article. OpenSSL is known to be complex, hard to audit, etc. But they do have standards. You may want to take a look at LibreSSL or BoringSSL instead if you are looking for something more modern and maintainable.
- shadowgovt 5y agoI mean, it hasn't grown to a thousand entries, but https://github.com/openssl/openssl/blob/master/crypto/http/http_lib.c#L96 https://github.com/openssl/openssl/blob/master/crypto/http/h... There's also the parameter parser builder at https://github.com/openssl/openssl/blob/master/crypto/param_build.c#L160 https://github.com/openssl/openssl/blob/master/crypto/param_... This kind of pattern of repeated application instead of iterating over a data structure ends up fairly common in any code base I've ever seen, public or private. The machinery to build a list loader and iterator always just seems like more code than one wants to write when one is tasked with adding one more element to the existing sequence of homogeneous operations varying the data.