Unsound uses of Unsafe

[r4klatif]

Right now the hello-world code contains 100+ uses of unsafe. Presumably this is in order to achieve the best possible performance in hot parts of the code.

However, Hello worlds often face the modern and memory safe🔒 rust 🚀 programmer, so security🔒 is extremely important for hello world implementations. This issue is especially critical for organizations that intend to use the software in large-scale🚀 production environments. One of the main reasons to choose a Rust🚀-based hello world implementation is the guaranteed memory safety🔒 that safe Rust🚀 provides. Unfortunately this guarantee is eroded for every use of unsafe in the codebase. Performance isn't worth much if it comes at the cost of critical security vulnerabilities due to unsafe memory access. It's also nice to know for certain that your hello world won't segfault in production.

I propose that we leave this open as a tracking issue to track design and implementation issues concerning the use of unsafe code. Some of the items that should be explored:

• Is it possible to remove any of the current uses of unsafe without significantly impacting performance?
• Is it appropriate to remove some uses of unsafe even if there's a performance impact?
• Is there a long-term plan to reduce or eliminate the use of unsafe code?
• Security🔒 analysis, testing, and fuzzing of the codebase
• Profiling and performance analysis to assess the impact of converting unsafe to safe code

[mTvare6]

Did you read the readme? rust can convert unsafe c to safe c, and unsafe assembly code to safe assembly code, the same way, all unsafe code is converted to safe code, don't worry, we will have the performance and safety 🚀

[mTvare6]

Duplicate of #22