iavor.diatchki:

Hello,

On 1/28/07, Duncan Coutts wrote:

...

We can put them in the IO monad. The same applies to packCStringLen and packMallocCString.

Adding packCString (and friends) to the IO monad does not make them any safer (the IO monad hides some sins but not all ;-). To see the problem, imagine that packCString was of type "CString -> IO ByteString" (as Don suggested). Then we still get the same weird behavior if we replace: let s = packCString x with s <- packCString x in the example that I posted.

The problem is that 'x' allows us to mutate the memory area occupied by s' but Haskell values are supposed to be immutable. So if we want to have these functions, then it seems that the best we can do is to mark them with the "unsafe" label and be very careful how we use them...

Out of curiosity (I have not looked at the implementation of ByteString) is it true that ByteStrings created in this fashion (i.e., with packCString) will not be garbage collected?

packCString :: CString -> IO ByteString packCString cstr = do fp <- newForeignPtr_ (castPtr cstr) l <- c_strlen cstr return $! PS fp 0 (fromIntegral l) The string is managed on the CString side. So however that CString is managed (maybe its on the Haskell heap, maybe its on the C side, maybe malloc looks after it). As indicated in the my api post, copyCString will be the default after today, which will just produce a normal Haskell value. unsafePackCString can then be left for those who know what they're doing. Does that sound reasonable? -- Don

timd:

dons@cse.unsw.edu.au wrote:

...

The functions should document this behaviour better. Of course, you're paying with poke and C strings so you should be careful anyway. I'll correct the documentation to explain all this.

Forgive a non-experts comment:

This approach ("read the doco and be careful when you use these functions") feels contrary to the haskell ethos of pure code being reliably pure. What's the argument for not prefixing such functions with "unsafe"?

No no. The types should certainly reflect the safety. And by default people should try the safe versions :) Its a tricy area to get exactly right, since we're straddling the C / Haskell interface here. * The current api: Zero-copying, efficient. Unsafe if you mutate the C string, in the case of packMallocCString, if you run the finalisers twice: packCString :: CString -> ByteString packCStringLen :: CStringLen -> ByteString packMallocCString :: CString -> ByteString useAsCStringLen :: ByteString -> (CStringLen -> IO a) -> IO a Safe. Copies the ByteString: copyCString :: CString -> IO ByteString copyCStringLen :: CStringLen -> IO ByteString useAsCString :: ByteString -> (CString -> IO a) -> IO a * The proposed api: The following will be safe, copying across the C/Haskell boundary by default: packCString :: CString -> IO ByteString packCStringLen :: CStringLen -> IO ByteString packMallocCString :: CString -> IO ByteString useAsCString :: ByteString -> (CString -> IO a) -> IO a useAsCStringLen :: ByteString -> (CStringLen -> IO a) -> IO a Those with extra efficiency needs, but also extra safety requirements: unsafePackCString :: CString -> IO ByteString unsafePackCStringLen :: CStringLen -> IO ByteString unsafePackMallocCString :: CString -> IO ByteString unsafeUseAsCString :: ByteString -> (CString -> IO a) -> IO a unsafeUseAsCStringLen :: ByteString -> (CStringLen -> IO a) -> IO a Which will all do zero-copying calls acroos into C (or Haskell), but you'll need to ensure you don't mutate the C string. The safety requirements for the unsafe* versions will be clearly stated. -- Don

Some function in the interface *MUST* be tagged unsafe. The current situation is very anti-Haskell. I don't care how efficient it is. First and foremost it must have pure Haskell semantics, otherwise it doesn't belong as a pure function. -- Lennart On Jan 28, 2007, at 23:58 , Tim Docker wrote:

dons@cse.unsw.edu.au wrote:

...

The functions should document this behaviour better. Of course, you're paying with poke and C strings so you should be careful anyway. I'll correct the documentation to explain all this.

Forgive a non-experts comment:

This approach ("read the doco and be careful when you use these functions") feels contrary to the haskell ethos of pure code being reliably pure. What's the argument for not prefixing such functions with "unsafe"?

Tim _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Hello Donald, Tuesday, January 30, 2007, 6:08:50 AM, you wrote:

The Data.ByteString functions relating to CString have now been modified as follows, in the darcs repository. These changes will be propogated into base in due course.

i.e. only in ghc 6.8. i use this chance to remind about our suggestion to remove ByteString from Base in ghc 6.6.1 and include it as *separate* library. it will make upgrading possible and will conform with the situation in ghc 6.4 and, i hope, ghc 6.8. now one forced to use different .cabal files for 6.4 and 6.6 just to include/exclude this lib -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com