On Tue, Mar 29, 2011 at 2:37 AM, Edward Z. Yang
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-Pt...
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.
I just want to be clear: You can get alloca and friends to fail well BEFORE you are OOM. Just allocate something larger than the remaining contiguous space. If you're allocating a few KB and you run out of memory that can be bad situation, but I don't think we should treat all allocation failures as if the sky is falling :) Jason