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

[Edward Kmett]

David, traditionally malloc doesn't clear and calloc does. (We don't currently provide a "calloc" -like API), but we don't have a member equivalent to fill the gap.

Of course, we just pretend these things are the c analogues, the work differently.


> On Nov 12, 2014, at 10:34 AM, David Feuer <david.feuer at gmail.com> wrote:
> 
>  I don't know which systems do and don't guarantee what is already cleared; are you careful not to repeat someone else's work?
> 
>> On Wed, Nov 12, 2014 at 9:21 AM, Alex Petrov <oleksandr.petrov at gmail.com> 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
>> 
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141112/9a0e3d62/attachment.html>