3 ms·
Really? Are we really going to turn this into a Rust vs. C flamewar when the code in question is most likely Assembly generated by Perl? https://github.com/open
by jart 4y ago
Really? Are we really going to turn this into a Rust vs. C flamewar when the code in question is most likely Assembly generated by Perl? https://github.com/openssl/openssl/blob/2e3e9b4887b5077b949cdee490ecc1526b2c5509/crypto/aes/asm/aesni-x86.pl#L1 https://github.com/openssl/openssl/blob/2e3e9b4887b5077b949c... In the recent release they changed a `jb` to `jbe` in that file which could be related. It's hard to tell what code is actually the culprit. They had a similar file in Perl which appeared to be for fused-multiply add avx512 that got removed at some point, possibly with a C rewrite, so you could be somewhat right. Either way there really should be more transparency about how what's written in release notes matches up with the code that actually changes between tags.
- dc-programmer 4y agoThis is horrifying information. I was only aware of the C code that is 99% macros
- staticassertion 4y agoIt's not extremely uncommon to find "assembly pushed together by perl" tbh
- dc-programmer 4y agoI believe it. But it makes source coding auditing and static analysis incredibly difficult.
- mattwilsonn888 4y agoIronically this is the most inflammatory response I've seen thus far - not like being emotional makes something more likely to be incorrect anyways...
- yjftsjthsd-h 4y ago... if that summary is materially accurate, then it would make the first occasion on which I would genuinely believe that rewriting a code base purely in C was a security improvement.