Fwd: How to best deal with nullPtr from alloca and friends?
dagitj at gmail.com
Tue Mar 29 19:45:20 CEST 2011
Sending this question to Haskell-Cafe may have been a mistake on my part.
Is the library list the right place for this?
Since posting this, I'm now convinced that the documentation in the haddocks
are wrong. It seems that alloca is designed to never return nullPtr whether
that means crashing or throwing an exception.
Do I just update the haddocks and submit a patch some where?
---------- Forwarded message ----------
From: Jason Dagit <dagitj at gmail.com>
Date: Mon, Mar 28, 2011 at 9:43 PM
Subject: How to best deal with nullPtr from alloca and friends?
To: Haskell Cafe <haskell-cafe at haskell.org>
I was reading up on the documentation for alloca and friends, which says,
"If any of the allocation functions fails, a value of
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
It seems that actually, alloca and friends throw exceptions:
dmwit> main = allocaArray (2^30) (\ptr -> print ((nullPtr :: Ptr Double) ==
<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
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
<= 2^30 bytes, works perfectly
== 2^30 + 2^20 bytes, I get an "<interactive>: out of memory" message and
== 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries