October 2002 - Glasgow-haskell-users

IO security
by Ch. A. Herrmann 04 Oct '02

04 Oct '02

Hi GHC users, I'm looking for secure compile and run-time methods to ensure automatically that Haskell modules cannot perform particular IO operations. Therefore, I've got some questions that might be interesting for other people using GHC as well. o There are functions like "unsafePerformIO". How many of these unsafe functions exist and what are their names? Is there a possibility to tell GHC to reject programs in which such functions occur? Concerning, e.g., the rewrite-rule system, how can we prevent that these functions are applied by some trick, invisible by an automatic inspection of the source code? o Is the function "print" secure in the sense that all stuff it produces is restricted to go to stdout, even if strange sequences of control characters appear? o Is there a way to tell the GHC run-time system to block file operations or system calls coming from the application program, while permitting input/output via stdin/stdout? Thanks in advance -- Christoph Herrmann

3 2

Question about the notation of (# ... #)
by David Sabel 04 Oct '02

04 Oct '02

Hi, can somebody explain what the notation (# ... #) means? For example it is used in the definition of unsafePerformIO: unsafePerformIO :: IO a -> a unsafePerformIO (IO m) = case m realWorld# of (# _, r #) -> r Thanks, David

2 1

deriving weirdness on newtypes
by Hal Daume III 03 Oct '02

03 Oct '02

So I love the fact that I can derive anything I want on newtypes. However, there seem to be problems with it. If I write: newtype Foo = Foo Int deriving (Show) x = show (Foo 5) Then x is "Foo 5" However, if I do newtype Foo = Foo Int deriving (Num) x = show (Foo 5) Then the definition of 'x' claims that there is no Show instance of Foo. However (this is where it gets weird). If I do: newtype Foo = Foo Int deriving (Num) x = show ((Foo 5) + 4) then x is *valid* and has value "9", not "Foo 9". Moreoever, I can even do: x = show ((5::Foo) + 4) and this x has value "9". Futhermore, if I do: newtype Foo = Foo Int deriving (Show,Num) then "show (Foo 5)" has value "5", not "Foo 5". IMO, the correct value of "show (Foo 5)" no matter which of the above we have is "Foo 5". I think the deriving mechanism should be changed in two ways. (1) If you derive X on a newtype and X is a subclass of Y, you must have an instance of Y on that newtype. This is how it works on data types, and I think makes sense. For instance, newtype Foo = Foo Int deriving (Ord) should be just as illegal as data Foo = Foo Int deriving (Ord) (2) The derived Show instances for newtypes in the presense of derived Num instances should be fixed so that the constructor is also printed. Rational: adding something to the list of derived classes should *not* change previously derived instances. There is yet another thing. If we have: newtype Foo = Foo Int deriving (Num) instance Show Foo where { show = undefined } then, the value of 'show (Foo 5)' is undefined, but the value of 'show (5::Foo)' is "5". definately *WRONG*. - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 1

No GHC support for a week
by Simon Marlow 03 Oct '02

03 Oct '02

Folks, GHC support will be intermittent at best for the next week or so, as Simon & I are both heading out to Pittsburgh for ICFP and the Haskell workshop. Catch you all later... Cheers, Simon

3 5

RE: IO-System
by Simon Marlow 01 Oct '02

01 Oct '02

> In the GHC users guide Chapter 7.2.12 is the single primitve value > realWorld# of the state of the world provided. > This value is also used in the implementation of unsafePerformIO > (GHC.IOBase), where it is applied as the argument > to the IO action, and so on (after performing the action it's > discarded). > > My question is now: Is the same value (realWorld#) applied while using > normal monadic - not unsafe - IO, more precisely > is a programm main::IO () executing the expression (main realWorld#)? In effect, yes. However, the implementation optimises away the actual values of type State#, so that no actual argument passing goes on most of the time. Cheers, Simon

1 0

RE: IO-System
by Simon Marlow 01 Oct '02

01 Oct '02

> I'm, analysing the IO-system of the GHC and need more > information about > it. > More precisely: How switches the run-time-system between (normal) > evaluation and performing of IO-actions? > > I read the rts-paper, but didn't find any information about this. > > Can somebody give a short review, or are ther any other > papers available? The runtime system mostly has no concept of IO vs. non-IO evaluation. The IO monad is implemented as the following type: newtype IO a = IO (State# RealWorld -> (# State# RealWorld, a #) which means that an IO action is simply a function from the world state to a pair of a new world state and a value. In other words, it's a straightfoward state monad, except that we use some optimised representations to eliminate some of the overhead of passing the state around. Cheers, Simon

6 8