-----Original Message----- From: Donald Bruce Stewart [mailto:dons@cse.unsw.edu.au] Sent: Monday, September 03, 2007 12:03 AM To: Seth Kurtzberg Cc: libraries@haskell.org Subject: Re: ByteString I/O Performance seth:
-----Original Message----- From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org]
On Behalf Of Bryan O'Sullivan
Sent: Sunday, September 02, 2007 11:23 PM To: Peter Simons Cc: libraries@haskell.org Subject: Re: ByteString I/O Performance
Peter Simons wrote:
One way to get malloc() out of the picture would be to provide a variant of hGet that takes an existing, pre-allocated buffer as an argument, so that the user can allocate a ByteString once and re-use it for every single hGet and hPut.
This is already quite easy to do. See unsafeUseAsCStringLen in Data.ByteString.Base, and hGetBuf in System.IO.
Is it possible without resorting to an unsafeXXX function?
They're all 'unsafe' for different reasons :) The question should be: why is this unsafe? (It's unsafe because it doesn't copy the C string, so you need to have a side condition that the string isn't modified by C). OK. Assume that I'm not doing any C coding, so that the only C code that is invoked is called from within the implementation (in this case the implementation of System.IO). Can I assume that no implementation code modifies the string? In other words, is it valid to assume that the side condition is never violated so long as I don't violate the side condition in my own C code (if any)? -- Don