Is Safe Haskell intended to allow segfaults?

[Edward Kmett]

I've always treated Safe Haskell as "Safe until you allow IO" -- in that
all 'evil' things get tainted by an IO type that you can't get rid of by
the usual means. So if you go to run pure Safe Haskell code in say,
lambdabot, which doesn't give the user a means to execute IO, it can't
segfault if all of the Trustworthy modules you depend upon actually are
trustworthy.

Trying to shore up segfault safety under Safe in IO seems like a losing
proposition.

-Edward

On Mon, Aug 8, 2016 at 1:27 PM, Ryan Newton <rrnewton at gmail.com> wrote:

> We're trying to spend some cycles pushing on Safe Haskell within the
> stackage packages.  (It's looking like a slog.)
>
> But we're running up against some basic questions regarding the core
> packages and Safe Haskell guarantees.  The manual currently says:
> <https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/safe_haskell.html#safe-language>
>
>
> *Functions in the IO monad are still allowed and behave as usual. *
> As usual?  So it is ok to segfault GHC?  Elsewhere it says "in the safe
> language you can trust the types", and I'd always assumed that meant Safe
> Haskell is a type safe language, even in the IO fragment.
>
> Was there an explicit decision to allow segfaults and memory corruption?
> This can happen not just with FFI calls but with uses of Ptrs within
> Haskell, for example the following:
>
>
> ```
>
> {-# LANGUAGE Safe #-}
>
> module Main where
>
> import Foreign.Marshal.Alloc
>
> import Foreign.Storable
>
> import Foreign.Ptr
>
> import System.Random
>
>
> fn :: Ptr Int -> IO ()
>
> fn p = do
>
>   -- This is kosher:
>
>   poke p 3
>
>   print =<< peek p
>
>   -- This should crash the system:
>
>   ix <- randomIO
>
>   pokeElemOff p ix 0xcc
>
>
>
> main = alloca fn
>
> ```
>
>
>   -Ryan
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160809/19779439/attachment.html>