I see three major stories here:
1.) If you remove IO from being able to be compiled inside Safe code _at
all_ most packages I have that bother to expose Safe information will have
to stop bothering. I'd have to cut up too many APIs into too many
fine-grained pieces. This would considerably reduce
Turns out the accumulated error is even worse:
Prelude> let old x y z = let eftt i j = i : eftt j (j+j-i) in let d =
y - x in maximum $ takeWhile (<= z + d) $ eftt x y
Prelude> old 0.0 0.1 86400.0
86400.005062
Prelude> let new x y z = let d = y - x in let go i = i : go (i + d) in
maximum $ tak
Noticed this today:
ghci> let xs = [0.0,0.1 .. 86400.0] in maximum xs
86400.005062
enumFromThenTo is implemented by numericEnumFromThenTo:
https://github.com/ghc/ghc/blob/a90085bd45239fffd65c01c24752a9bbcef346f1/libraries/base/GHC/Real.hs#L227
Which probably accumulates error in numericEnum
Heh, ok, segfaults themselves are a red herring. More precisely:
The operational semantics for a SafeIO language should always accurately
model its memory state. The application should not compute (take a step in
the semantics) in a way that exposes corrupt memory or arbitrary undefined
behavior
On Tue, Aug 9, 2016 at 4:19 PM, Edward Z. Yang wrote:
> If you can execute subprocesses, you could always spawn gdb to
> attach via ptrace() to the parent process and then poke around
> memory.
>
Don't even need that if you're just talking segfaults, you can always spawn
a subprocess "kill -SEGV
I'm hearing that Safe Haskell is great for pure use cases (lambda bot).
But that doesn't depend on being able to write arbitrary IO code inside the
Safe bubble, does it? In fact *all* of IO could be outside the safe
boundary for this use case, could it not? Are there any existing cases
where it i
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 al
If you can execute subprocesses, you could always spawn gdb to
attach via ptrace() to the parent process and then poke around
memory.
Yes this is a "dumb" example but I think it goes to show how
important it is to correctly characterize what the threat model
is. A "no-segfault" fragment of Haskel
-- Forwarded message --
From: Richard Fung
Date: Tue, Aug 9, 2016 at 8:33 AM
Subject: Re: Help on first ticket
To: Simon Peyton Jones
It's been a while but I've been able to spend more time on it recently made
some progress.
I believe I have an idea of what I need to fix in ter
On Mon, Aug 8, 2016 at 8:46 PM, Mikhail Glushenkov 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/la
10 matches
Mail list logo
