区别是什么:
ptr = malloc(MAXELEMS * sizeof(char *));
And:
ptr = calloc(MAXELEMS, sizeof(char*));
什么时候使用calloc优于malloc或反之亦然?
当前回答
calloc的一个经常被忽视的优点是，它将帮助保护您免受整数溢出漏洞的侵害。比较:
size_t count = get_int32(file);
struct foo *bar = malloc(count * sizeof *bar);
vs.
size_t count = get_int32(file);
struct foo *bar = calloc(count, sizeof *bar);
如果count大于SIZE_MAX/sizeof *bar，前者可能导致少量分配和后续缓冲区溢出。在这种情况下，后者将自动失败，因为无法创建如此大的对象。
当然，您可能不得不注意不符合规范的实现，这些实现简单地忽略了溢出的可能性……如果在您的目标平台上存在这个问题，那么无论如何都必须对溢出进行手动测试。
其他回答
分配的内存块大小没有差异。Calloc只是用物理全零位模式填充内存块。在实践中，通常假设位于用calloc分配的内存块中的对象具有初始值，就像它们是用文字0初始化的一样，即整数的值应该是0，浮点变量的值应该是0.0，指针的值应该是适当的空指针值，等等。
然而，从学究的角度来看，calloc(以及memset(…， 0，…))只能保证正确地初始化unsigned char类型的对象(使用0)。其他所有内容都不能保证被正确初始化，并且可能包含所谓的陷阱表示，这会导致未定义的行为。换句话说，对于除unsigned char以外的任何类型，前面提到的全零位模式可能表示非法值，即陷阱表示。
后来，在C99标准的一个技术更正中，为所有整数类型定义了行为(这是有意义的)。也就是说，在当前的C语言中，你只能用calloc(和memset(…， 0，…))。从C语言的角度来看，在一般情况下使用它来初始化其他任何东西都会导致未定义的行为。
在实践中，calloc工作，我们都知道:)，但是否想要使用它(考虑到上面的问题)取决于你。我个人更倾向于完全避免它，而是使用malloc并执行自己的初始化。
最后，另一个重要的细节是，calloc需要在内部计算最终的块大小，通过将元素大小乘以元素数量。在执行此操作时，calloc必须监视可能的算术溢出。如果无法正确计算请求的块大小，将导致分配不成功(空指针)。同时，您的malloc版本不会尝试监视溢出。它将分配一些“不可预测”的内存数量，以防发生溢出。
一个不太为人所知的区别是，在具有乐观内存分配的操作系统(如Linux)中，由malloc返回的指针直到程序实际接触它时才得到实际内存的支持。
calloc确实会接触内存(它会在内存上写0)，因此您可以确定操作系统正在用实际的RAM(或swap)支持分配。这也是为什么它比malloc慢的原因(它不仅必须将它归零，操作系统还必须通过交换其他进程来找到合适的内存区域)
例如，请参阅这个SO问题以进一步讨论malloc的行为
malloc和calloc都分配内存，但calloc将所有位初始化为0，而malloc则不这样做。
可以说，Calloc相当于malloc + memset + 0(其中memset将指定的内存位设置为0)。
因此，如果不需要初始化为0，那么使用malloc可能会更快。
calloc的一个经常被忽视的优点是，它将帮助保护您免受整数溢出漏洞的侵害。比较:
size_t count = get_int32(file);
struct foo *bar = malloc(count * sizeof *bar);
vs.
size_t count = get_int32(file);
struct foo *bar = calloc(count, sizeof *bar);
如果count大于SIZE_MAX/sizeof *bar，前者可能导致少量分配和后续缓冲区溢出。在这种情况下，后者将自动失败，因为无法创建如此大的对象。
当然，您可能不得不注意不符合规范的实现，这些实现简单地忽略了溢出的可能性……如果在您的目标平台上存在这个问题，那么无论如何都必须对溢出进行手动测试。
摘自Georg Hager的博客上的一篇文章，用calloc()进行有趣的基准测试
When allocating memory using calloc(), the amount of memory requested is not allocated right away. Instead, all pages that belong to the memory block are connected to a single page containing all zeroes by some MMU magic (links below). If such pages are only read (which was true for arrays b, c and d in the original version of the benchmark), the data is provided from the single zero page, which – of course – fits into cache. So much for memory-bound loop kernels. If a page gets written to (no matter how), a fault occurs, the “real” page is mapped and the zero page is copied to memory. This is called copy-on-write, a well-known optimization approach (that I even have taught multiple times in my C++ lectures). After that, the zero-read trick does not work any more for that page and this is why performance was so much lower after inserting the – supposedly redundant – init loop.
