Proposal: Add 'fillBytes' to Foreign.Marshal.Utils

[Ben Millwood]

>From what I can see on phabricator, this proposal has been implemented 
and closed. If that's true it would have been useful to mention that on 
this thread, I think.

Anyway, I wonder if fillBytes is ever likely to be used with a non-zero 
byte. Wouldn't zeroBytes have been just as good?

On Wed, Nov 12, 2014 at 03:21:17PM +0100, Alex Petrov wrote:
>Hi everyone,
>
>Currently the memory allocated with (Foreign.Marshal.Alloc) malloc may potentially be dirty. In C this problem is usually solved by using memset.
>
>This would be extremely useful for FFI / C interop, when a data structure is allocated within Haskell code. With memset, you can do something like
>
>customMem <- malloc
>_         <- memset (castPtr customMem) 0 #{size custom_t}
>This will fill a block of allocated memory with zeroes.
>
>For example, I've been working on FFI bindings for collectd, and when I was allocating memory, previously used within the process, it was dirty, so my CString contained a value of
>
>"custom name7e0700490, test_plugin_LTX_module_register): symbol nd"
>Instead of just
>
>"custom name"
>After using memset and filling everything with zeroes, problem never appeared again.
>
>This can be implemented in user applications, too, although it would be really nice to have it by default.
>This is a common practice in C world, and this function is not only useful for cases when the memory was just allocated from Haskell process, but also when one receives a dirty memory buffer from C code. 
>
>The patch for proposal was implemented and is available on Phabricator: https://phabricator.haskell.org/D465
>
>
>Please share your thoughts.
>
>
>Alex
>https://twitter.com/ifesdjeen
>http://clojurewerkz.org/

>_______________________________________________
>Libraries mailing list
>Libraries at haskell.org
>http://www.haskell.org/mailman/listinfo/libraries