
On Fri, Apr 22, 2011 at 12:05 PM, Daniel Peebles
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
wrote: On Fri, Apr 22, 2011 at 8:59 AM, Ian Lynagh
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@haskell.org http://www.haskell.org/mailman/listinfo/libraries