Excerpts from Jason Dagit's message of Tue Mar 29 00:43:10 -0400 2011: > I was reading up on the documentation for alloca and friends[1], which says, > "If any of the allocation functions fails, a value of > nullPtr<http://www.haskell.org/ghc/docs/7.0.2/html/libraries/base-4.3.1.0/Foreign-Ptr.html#v:nullPtr> > is > produced." > > It seems like every example of FFI code that I find which uses alloca > ignores the possibility of a nullPtr[2, 3, 4]. > > So then I started trying out examples with the help of dmwit and others from > #haskell. > > It seems that actually, alloca and friends throw exceptions: > dmwit> main = allocaArray (2^30) (\ptr -> print ((nullPtr :: Ptr Double) == > ptr)) > <dmwit> lispy: alloca also throws an exception. > <dmwit> lispy: Or rather, allocaBytes throws an exception, and alloca is > implemented in terms of allocaBytes, so I'm *guessing* that alloca throws an > exception. > > I'm on a 64bit version of windows here with more than 4GB of memory to spare > for the GHC process. Unfortunately, allocaBytes takes an Int so I can't test > it with a request larger than the amount of physical ram I have.
You could try testing by setting different limits on the memory usage of your process with ulimit. I'll give a test, but the prevailing wisdom is that if you OOM, you're really out of luck. Edward _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe