OrangeC VS sha1collisiondetection

No one here speaks of the Orange C++ toolchain 😿 https://github.com/LADSoft/OrangeC

Have you heard of the OrangeC compiler project? https://github.com/LADSoft/OrangeC/blob/master/doc/occil.md

If you know how a C++ lambda works under the hood, you'd understand that C++ lambdas create classes in order to ingest the capture targets then work on it, the code in the Orange C compiler for example does the following:

There's also orange

Pelles C and OrangeC, I don't know about the former, but the latter does it via CreateThread, source.

If you want a context as a why the original question, here's a big issue on why it's relevant at all to anyone who isn't developing libcxx.

It's far more likely that somebody would try to artificially create a collision. There is code in git to try to detect this https://github.com/cr-marcstevens/sha1collisiondetection

First milestone is to be able to compile this code https://github.com/cr-marcstevens/sha1collisiondetection/ using Cesium.

For sha1, people made a system where you can detect the patterns that lead to a collision, and (for example) replace it with a different hash only for inputs that would be a problem. https://github.com/cr-marcstevens/sha1collisiondetection i think git does this to eek more life out of sha1.

I imagine you could take a similar counter-cryptnalysis approach to md5. (I am out of my depth here, so there could be reasons this doesnt work for md5 im unaware of)

I'm saying that Git is on my side of opinion, that's why Git added collision detection (hardened SHA1) and added support for more stronger hashes and Git's goal is transition out of SHA1. The same is with fossil, that added hardened SHA1 since 2017 and by default uses SHA3 for new repositories.