Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why does calloc exist?

vorpus.org

Post reply on HN
Print view View original

111–120 of 141 posts

Re: Why does calloc exist?

#111

Post by dagw »

greglindahl wrote: post #16
viraptor wrote: post #13

Earlier quoted context omitted.

I think there's a big difference between "why does ... exist" and "why does ... still exist". calloc() may be useful today for reasons completely different from why it existed in the first place. And the difference #2 is just an implementation-specific optimisation. There's nothing in the standard that forces calloc to use lazy allocation / virtual memory. Actually, it may be implemented on platforms which can't prov…

Thank you for bringing up the implementation-specific nature of #2! If the author is running Linux, then perhaps they've never checked out overcommit vs. not overcommit.

For what it's worth, the numpy 'trick' he used to demonstrate that feature also works on windows.

Re: Why does calloc exist?

#112

Post by chei0iaV »

Manishearth wrote: post #54

I've always been surprised that memset is usually just a nonmagical for loop. I used to expect that the OS does things to magically make it faster (running lazily, etc).

Which implementations use a nonmagical for loop?

glibc's is all in assembly full of SIMD instructions, which seem very much magical...

https://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/x86...

http://stackoverflow.com/questions/8858778/why-are-complicat...

Re: Why does calloc exist?

#114

Post by BugsBunnySan »

kamouth wrote: post #110

"(I mean, let's be honest: if we really cared about security we wouldn't be writing in C.) " Why so ?

Should be the other way around, shouldn't it: "Only if you really care about security should you be allowed to write in C" :)

(i.e., don't use a professional-grade band-saw, if you're not a professional)

Re: Why does calloc exist?

#115

Post by kgabis »

takeda wrote: post #90
jblow wrote: post #88

Earlier quoted context omitted.

Spoken like someone who does not ship fast software!

There's a saying that is often misused, but applies here: "premature optimization is a root of all evil" You first write your code using standard system functions, using the right calls for what you're doing. If after that performance of the code is bad because of calloc() only then you roll out your own implementation (most likely in assembly), and accept that in the future your code might not work well, because som…

It's not always the best way to write software. If you're writing a program that's supposed to work in real(ish) time then it's good to take performance into consideration early on, otherwise you'll end up rearchitecting your program later. It's not necessarily about a number of cycles each operation takes, but rather about memory layout of your data. I guess it's a matter of experience: if you expect something to be a bottle neck (because it was a bottleneck in a similar application you've written in the past) then maybe you should just write it properly the first time round?

Re: Why does calloc exist?

#117

Post by mannykannot »

imtringued wrote: post #103
mannykannot wrote: post #56

Earlier quoted context omitted.

>Anything else is amateur hour. Such as writing the optimizing compilers that make it feasible for you to use C at all?

Is C now so bloated that it needs optimizing compilers just to get executed at all? Is a C interpreter is unfeasable? Apparently even an unoptimizing compiler is not enough.

I am not aware of any change to the C language that has introduced bloat - perhaps you could explain?

FYI optimizing compilers are also used to produce efficient instruction streams.

Re: Why does calloc exist?

#118

Post by ericfrederich »

avar wrote: post #55
_RPM wrote: post #32

buf = calloc(huge, huge); if (errno) perror("calloc failed"); printf("calloc(huge, huge) returned: %p\n", buf); free(buf); This has a flaw. errno doesn't magically get reset to zero. You should check the return value of calloc, then use errno. Checking if(errno) is not the right way to determine if there was an error.

Its [errno's] value is significant only when the return value of the call indicated an error (i.e., -1 from most calls; -1 or NULL from most library functions); a function that succeeds is allowed to change errno.

Yeah... that caught my attention too and I looked up errno and found the same thing.

Re: Why does calloc exist?

#120

Post by AndyKelley »

jblow wrote: post #30

Sorry, but this is just goofy and bad. If you depend on copy-on-write functionality, then you need to use an API that is specced to guarantee copy-on-write functionality. If that means you use an #ifdef per platform and do OS-specific stuff, then that is what you do. Anything else is amateur hour. If copy-on-write is a desirable feature, then as the API creator, your job is to expose this functionality in the cleares…

Ignoring the multiplication issue, I think once again it all comes down to communicating intent. If you want to allocate zeroed memory, use calloc. If you don't need your memory to necessarily be zeroed, use malloc.

I'm agreeing with you here - if your intent is to have copy-on-write functionality, that's not what you're communicating when you use calloc.

It's okay for an implementation to try to optimize given the constraints of intent, but I agree that if an implementation is doing something non-straightforward (copy-on-write in this case), that is a smell that perhaps the API needs to expose an additional layer.

Post reply on HN