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

[Jason Dagit]

On Fri, Apr 22, 2011 at 12: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.
>

It doesn't have to be a binding.  If you'd prefer to provide a Haskell
implementation in terms of malloc/copyBytes that sounds fine too.  I wasn't
sure how to best do that so a binding seemed the most straightforward.

Note that in my binding, I gave it the same type as malloc, which is to say
it is always in terms of bytes.  The actual calloc api seems more like what
we call mallocArray and I didn't personally need that functionality so I
went for something that matched malloc.  I'm flexible on that point.

Jason



>
> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110422/7e94ea8d/attachment-0001.htm>