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 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.
Just playing around with different arguments to allocaBytes I can get different behavior:
<= 2^30 bytes, works perfectly
== 2^30 + 2^20 bytes, I get an "<interactive>: out of memory" message and ghci terminates
== 2^31-1, I get a crash where windows pops up a little dialog saying my program (ghci) has crashed.
The behavior seems to be inconsistent with the documentation.
What is the correct behavior for alloca and friends and should I be checking for nullPtr?
Thanks,
Jason