Eric Y. Kow wrote: >> Should imageGetData be turned into a 'with-style' function >> >> Image a -> (Ptr () -> IO b) -> IO b >> >> which protects the image? > > Ultimately, this seems like the right thing to do, for all functions > that return pointers to underlying bits of data (I am slightly scared > that there may be loads of these lurking around).
The alternative is to use mallocForeignPtr or one of its friends, and return a ForeignPtr to a copy of the buffer. Clearly both alternatives could be supported. For most purposes the (Ptr () -> IO b) approach is probably neater, though. After all if you do need direct access to a Ptr, it's probably because you're calling another FFI funciton on it (in my case, texImage2d), which will itself "take a copy" of the memory, and then it's safe to destroy. So in my example withImageData (\d -> texImage2d d ...) would seem like a pretty elegant answer. > >> Is there a workaround I can use in my code like touchPtr? A version of >> touchPtr which works on WXObjects? > > Well, I added image `seq` return () to your demonstrator. Not sure if > that really does what we want. I suppose we could augment the > PixelBuffer type to include a pointer to the original image. I think that makes it safe as long as PixelBuffer is considered opaque. But as soon as you provide a way of extracting the Ptr () from the Pixel Buffer, then the same problem comes back to bite you. As it happens, in my particular program, I don't use the Ptr directly because I need to pad to even width anyway, in general. So I was using imageGetPixels and thus would be safe under that scheme. Jules ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
