Is Safe Haskell intended to allow segfaults?
rrnewton at gmail.com
Tue Aug 9 14:41:44 UTC 2016
On Mon, Aug 8, 2016 at 8:46 PM, Mikhail Glushenkov <mikhail.
glushenkov at gmail.com> wrote:
> Yes, this can be done with JNI, see e.g. . Additionally, by using
> sun.misc.Unsafe , one can cause segfaults even from pure Java.
>  https://www.cs.princeton.edu/~appel/papers/safejni.pdf
>  http://www.inf.usi.ch/faculty/lanza/Downloads/Mast2015a.pdf
Ah, I see. I thought that, ruling out FFI, that you couldn't segfault with
pure Java code. Good to know about the unsafe interface.
On Mon, Aug 8, 2016 at 7:32 PM, David Terei <davidterei at gmail.com> wrote:
> If you have the energy, it'd be great to put some of this thinking
> into a wiki page (https://ghc.haskell.org/trac/ghc/wiki/SafeHaskell)
> and flesh out a first approximation of what IO API's cause issues. Is
> it just Ptr not carrying bounds around with it? Maybe, but then we
> need to secure how Ptr's can be created, which excludes FFI returning
Yes, we can add a Wiki page.
Btw I was thinking more of kicking FFI/peek/poke outside of the Safe
bubble, not changing their operational behavior. First of all, it's nigh
impossible to lock down FFI calls.
When someone, e.g. Bob Harper
points out a problem in Haskell, we sometimes respond "hey, *Safe Haskell*
is the real objet d'art! It's a safe language." Yet it isn't really a
full *language* if people cannot write and run programs in it! (Because
every program must be ultimately be `main::IO()`.) Kicking out segfaulty
features would still leave a safe language that people can write complete
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs