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

Edward Kmett ekmett at gmail.com
Sun Nov 23 19:52:28 UTC 2014


People find all sorts of weird usecases for memset once they have it in my
experience, so nothing is hurt by gaining generality here.

-Edward

On Sun, Nov 23, 2014 at 10:17 AM, Ben Millwood <haskell at benmachine.co.uk>
wrote:

> 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
>>
>
> _______________________________________________
> 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/20141123/f703015b/attachment.html>


More information about the Libraries mailing list