Preventing double-free error with `stablePtr`

Gershom B gershomb at gmail.com
Mon Feb 5 01:38:16 UTC 2018


I was just reading Roman Cheplyaka’s very interesting blog-post here:
https://ro-che.info/articles/2018-02-03-stableptr-undefined-behavior.

As he points out, the docs for `freeStablePtr` say

"if the stable pointer is passed to deRefStablePtr or freeStablePtr, the
behaviour is undefined.”

And indeed we can observe weird behavior as a result of sucn an error.

A deRef of a stable pointer is arguably the sort of sharp-edge we know how
to code to avoid. But a double free is a bit trickier. Would it be worth
adding a bit more overhead to make such an operation idempotent?

Additionally, would it be worthwhile to add `withStablePtr` to the
`Foreign.StablePtr` module? I imagine there are cases that it won’t cover,
but it would at least encourage good discipline in the cases that it does
handle. The evident utility of such a function is witnessed by its
existence in a few different codebases, not least the Win32 library (
https://hackage.haskell.org/package/Win32-2.6.2.0/docs/System-Win32-Types.html#v:withStablePtr
)

Cheers,
Gershom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180204/d109b539/attachment-0001.html>


More information about the Libraries mailing list