Fwd: How to best deal with nullPtr from alloca and friends?

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

Attached is a patch to amend the documentation. The diff is a bit hard to
read because I used vim to reflow the text after changing it. The final
result looks good, but the diff looks bad. Sorry about that!
Jason
On Tue, Mar 29, 2011 at 10:45 AM, Jason Dagit
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
Date: Mon, Mar 28, 2011 at 9:43 PM Subject: How to best deal with nullPtr from alloca and friends? To: Haskell Cafe I was reading up on the documentation for alloca and friends[1], which says, "If any of the allocation functions fails, a value of nullPtrhttp://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.
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
[1] http://www.haskell.org/ghc/docs/7.0.2/html/libraries/base-4.3.1.0/Foreign-Ma... [2] http://en.wikibooks.org/wiki/Haskell/FFI [3] http://www.haskell.org/haskellwiki/HSFFIG/Examples [4] http://book.realworldhaskell.org/read/interfacing-with-c-the-ffi.html
participants (1)
-
Jason Dagit