[PATCH 1/2] add calloc and callocBytes to Foreign.Marshal.Alloc

Edward Kmett ekmett at gmail.com
Fri Apr 22 23:11:05 CEST 2011


NB: libc can usually lean on the knowledge that virtual memory retrieved
from sbrk is already initialized to 0 when you calloc for memory initialized
to 0, so it can be vastly more efficient than malloc + memset and it can
decrease the number of useless 0 pages floating around.

http://stackoverflow.com/questions/2688466/why-mallocmemset-slower-than-calloc

<http://stackoverflow.com/questions/2688466/why-mallocmemset-slower-than-calloc>
-Edward

On Fri, Apr 22, 2011 at 3:05 PM, Daniel Peebles <pumpkingod at gmail.com>wrote:

> calloc is just a multiplication followed by malloc followed by memset. Is
> it really worth creating a new binding for that? It always seemed like a bit
> of a silly API to me to begin with.
>
> On Fri, Apr 22, 2011 at 12:08 PM, Jason Dagit <dagitj at gmail.com> wrote:
>
>>
>>
>> On Fri, Apr 22, 2011 at 8:59 AM, Ian Lynagh <igloo at earth.li> wrote:
>>
>>> On Fri, Apr 22, 2011 at 07:20:55AM -0700, Jason Dagit wrote:
>>> >
>>> > That wiki page doesn't say how long the discussion period should be or
>>> give
>>> > advice on how to determine the size.  What would you recommend for this
>>> > patch?
>>>
>>> I just updated the page to recommend 2 weeks, which I think is the
>>> status quo.
>>>
>>> > So it sounds like the things I missed were:
>>> >   * putting "Proposal:" in the subject line
>>> >   * setting a discussion period
>>> >   * attaching my patch to the trac instance (can I send a pull request
>>> on
>>> > github instead?)
>>>
>>> You don't need to make a trac ticket for it until the proposal has been
>>> accepted.
>>>
>>
>> Right, I did understand that.
>>
>>
>>>
>>> Anything that means we see that the patch needs to be applied is OK.
>>> Currently pull requests don't get sent to the mailing list though, and
>>> there doesn't seem to be an easy way to set that up.
>>>
>>
>> Good to know.
>>
>>
>>>
>>>
>>> I also didn't notice a rationale for the change. The type signatures
>>> looked the same as for the malloc functions, so I don't know what the
>>> difference is.
>>>
>>
>> The difference is that calloc will initialize the allocated memory to
>> zeros.  Some C libraries assume this, at least freetype2 does, and since I
>> want to use that library from Haskell I needed a binding to calloc.  I
>> assume others will run into this need eventually as well.  When I send a
>> "proposal:..." email, hopefully this weekend, I'll definitely make the
>> rationale clear.
>>
>> Thanks,
>> Jason
>>
>> _______________________________________________
>> 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/20110422/98605f20/attachment.htm>


More information about the Libraries mailing list