What is a reason to constrain likely/unlikely as an unsafe code?
These intrinsics are very powerful in performance-critical safe code, but unsafe marker makes it uncomfortable to use them in production.
Can you explain why they are unsafe and what problems these intrinsics can bring? How may they be misused?
The documentation tells that misuse will have no effect.
Intrinsics are always unsafe. There might be a stabilized interface, but intrinsics exist to aid the compiler in generating good code. In this specific case, it’s impossible to stabilize a function wrapper around the intrinsics, because that would destroy the entire likely/unlikely logic. We could probably stabilize it as an attribute though.
I understand that intrinsics are unsafe by their nature, but I’m rather interested in “what can go terribly wrong” using these particular intrinsics 
It’s not that intrinsics are unsafe by nature or that these in particular are unsafe. It’s that intrinsics are unsafe by definition and the compiler simply doesn’t understand the concept of a “safe intrinsic.”
You have to write unsafe code from time to time, but you can audit it. In this case, the audit would result in “checked safe” because marking a branch “likely” is not going to cause memory errors. You can always keep a document with your unsafe audits, so someone who wants to check can quickly go through.
Also, check out the underhanded winner, because they managed to get memory errors from safe rust (I believe), using known bugs.
Thank you!
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.