Ross Paterson <ross@soi.city.ac.uk> wrote,
On Fri, Jan 17, 2003 at 10:23:27AM +1100, Manuel M T Chakravarty wrote:
Ross Paterson <ross@soi.city.ac.uk> wrote,
I'd also like to see the addition of
mallocForeignPtrArray :: Storable a => Int -> IO (ForeignPtr a)
to ForeignPtr, to save people from rolling their own. (Maybe the realloc and 0 versions too?)
The reason I didn't answer to this earlier is that I wanted to see how many people say that they support this addition. To be honest, I never needed a function like this. Did anybody else?
Only me, it seems. But surely if both mallocForeignPtr and mallocArray are useful, this is too.
If you don't want to do explicit deallocation, mallocForeignPtr is attractive (and handled specially by GHC). Sooner or later there are going to be arrays, and then if there's no such function you'll have to write your own.
Yes, I think you are right that an orthogonality argument can be made here. So, let's add the function. I assume from the silence on this topic that nobody has an serious objections to adding this function. `mallocForeignPtrArray0' should then also be added, as you say. I am not so sure about a realloc version. It, at least, requires some care, as realloc may return a pointer different from the original. (In other words, there is no guarantee that realloc works in-place.) I just noticed that the spec doesn't mention this; so, I'll add it. We should also include the special cases that the C library covers: * If `realloc' is passed a `nullPtr', it works like `malloc'. * If the size requested from `reallocBytes' is 0, it works like `free'. Finally, I am not sure whether we really want to allow that `reallocBytes' may be used on `alloca'ed memory, which the spec currently explicitly admits. Proposed changes ~~~~~~~~~~~~~~~~ Add to `ForeignPtr': mallocForeignPtrArray :: Storable a => Int -> IO (ForeignPtr a) mallocForeignPtrArray0 :: Storable a => Int -> IO (ForeignPtr a) Refine spec of `MarshalAlloc' as follows: * realloc may return a pointer other than the one passed in. State special cases for passing `nullPtr' and size of 0, respectively, to `realloc' as stated above. [I will already apply these changes.] Open questions (feedback requested) ~~~~~~~~~~~~~~ * Shall we remove the sentence allowing `reallocBytes' on `alloca'ed memory? * Shall we provide reallocForeignPtrArray and reallocForeignPtrArray0? [I will not apply these changes until after further discussion.] Cheers, Manuel