Preventing double-free error with `stablePtr`

[David Feuer]

Guaranteeing either idempotence or an error message seems to require that
the stable pointer (but not what it points to) remain allocated until there
are no more references to it. I don't know enough about these things to say
how hard or expensive that might be. Another possibility might be to avoid
reallocating a pointer too soon after it's freed; that would give a decent
chance at an error and might be less expensive.

On Feb 4, 2018 8:38 PM, "Gershom B" <gershomb at gmail.com> wrote:

> 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
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180206/0e3b5ce7/attachment.html>