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

51–60 of 141 posts

Re: Why does calloc exist?

#51

Post by kllrnohj »

jblow wrote: post #49
kccqzy wrote: post #34

Earlier quoted context omitted.

I think the author's point is opportunistic optimization. He didn't ask us to rely on this behavior.

If you don't know whether or not you are really getting an optimization, then how much do you really care? If you really care, then you actually profile your system and see what takes how much time, under which circumstances. The results of such a profile are almost always surprising. I guess this is a basic cultural difference -- almost nobody in the HN crowd really cares whether their software runs quickly; there i…

At the same time why would you ever opt to malloc & memset instead of calloc? calloc might have clever optimizations, whereas malloc + memset won't. Intentionally choosing something slower, buggier, and that requires more work on your part is moronic.

Re: Why does calloc exist?

#52

Post by astrobe_ »

kllrnohj wrote: post #51
jblow wrote: post #49

Earlier quoted context omitted.

If you don't know whether or not you are really getting an optimization, then how much do you really care? If you really care, then you actually profile your system and see what takes how much time, under which circumstances. The results of such a profile are almost always surprising. I guess this is a basic cultural difference -- almost nobody in the HN crowd really cares whether their software runs quickly; there i…

At the same time why would you ever opt to malloc & memset instead of calloc? calloc might have clever optimizations, whereas malloc + memset won't. Intentionally choosing something slower, buggier, and that requires more work on your part is moronic.

Predictability sometimes trumps optimizations. For a striking illustration of this, see timing attacks.

Re: Why does calloc exist?

#55

Post by avar »

_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.

Re: Why does calloc exist?

#56

Post by mannykannot »

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…

>Anything else is amateur hour.

Such as writing the optimizing compilers that make it feasible for you to use C at all?

Re: Why does calloc exist?

#58

Post by jblow »

astrobe_ wrote: post #52
kllrnohj wrote: post #51

Earlier quoted context omitted.

At the same time why would you ever opt to malloc & memset instead of calloc? calloc might have clever optimizations, whereas malloc + memset won't. Intentionally choosing something slower, buggier, and that requires more work on your part is moronic.

Predictability sometimes trumps optimizations. For a striking illustration of this, see timing attacks.

Exactly. I would avoid using calloc simply because I don't know what it actually does.

Re: Why does calloc exist?

#59

Post by jblow »

mannykannot wrote: post #56
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…

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

I don't understand your reply. How is this not a non sequitur?
Post reply on HN