On Mon, Aug 8, 2016 at 8:46 PM, Mikhail Glushenkov
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
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 https://existentialtype.wordpress.com/2012/08/14/haskell-is-exceptionally-un..., 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