On Friday, 23 March 2018 at 14:37:12 UTC, Jack Stouffer wrote:
What are we going to do about C library calls in std.zlib and std.zip? I'm really uncomfortable about adding @trusted to the zlib calls, as it's different than calling C functions from the std library. There's no issue in reality with marking a malloc/free pair as trusted when it's verified to not escape. But there's really no garuntee about the safety of third party libraries. What if there's a Heartbleed level bug in zlib and we marked it as @trusted?
@safe/@trusted doesn't mean "calling this function will not result in heartbleed."
What you're getting is that when you call this function there are no parameter values which you could pass such that you could cause memory corruption. If you are concerned about heartbleed then you don't need to review @safe code, @trusted code should be reviewed so that @safe code can't cause issue with any of the valid parameters (the way it calls @system functions should be safe). And @system code should reviewed for heartbleed. If you use zlib and it has a heartbleed bug then it is your fault for not reviewing the @system code, not the fault of D marking its usage as @system.
You mention mallac being ok to use with @trusted, but it has the same issue, if you didn't review the code behind your mallac call then it could introduce heartbleed, you don't know because you didn't review it.
