Anybody know of any good resources on when it's ok to mark @rustlang functions that use unsafe code as safe? I feel like while there's been some good highly technical analysis, there's not a ton of resources of how to think about `unsafe`.
-
-
-
Replying to @degausser42 @ryan_levick and
I know I've adopted a hard line on this question, and would agree with upstream. If a caller calling the function can cause UB, then the function must be "unsafe." When wrapping COM API's, that's a lot of things. I'd guess most wrapped COM will need to have lots of unsafe.
1 reply 0 retweets 2 likes -
Replying to @raphlinus @degausser42 and
You might ask, "why don't existing COM wrapper libraries like direct2d-rs and dwrote expose unsafe?" I'd argue it's because they're riddled with safety bugs. There are other people who might argue "it's only technical UB," but I'd say they're wrong.
2 replies 0 retweets 0 likes -
Replying to @raphlinus @degausser42 and
I agree with you completely. We tried to generate safe wrappers for COM. I don’t believe it’s possible unless you’re methods take only Copy arguments and you assume that IUnknown is implemented properly
1 reply 0 retweets 1 like -
Replying to @ryan_levick @raphlinus and
The question for COM becomes, can you assume proper IUnknown implementations if you don’t know ahead of time what CoClass is actually backing those implementations
1 reply 0 retweets 0 likes
This is the right question. I do think it makes sense to have a newtype that expresses eg "the wrapped COM object has a proper IUnk impl", make the constructor for the newtype unsafe, then uses don't need to be. But this is but one of many such issues (races, buf lifetime, etc).
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.