On Mon, Aug 8, 2016 at 8:46 PM, Mikhail Glushenkov <mikhail.glushenkov@gmail.com> wrote:

Yes, this can be done with JNI, see e.g. [1]. Additionally, by using
sun.misc.Unsafe [2], one can cause segfaults even from pure Java.
[1] https://www.cs.princeton.edu/~appel/papers/safejni.pdf
[2] 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@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
Ptr's.

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 programs in.

Best,

-Ryan