This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug malloc/18092] New: calloc documentation omission
- From: "selinger at mathstat dot dal.ca" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sun, 08 Mar 2015 14:16:48 +0000
- Subject: [Bug malloc/18092] New: calloc documentation omission
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=18092
Bug ID: 18092
Summary: calloc documentation omission
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: malloc
Assignee: unassigned at sourceware dot org
Reporter: selinger at mathstat dot dal.ca
The documentation for calloc():
http://www.gnu.org/software/libc/manual/html_node/Allocating-Cleared-Space.html
states that one could define calloc() as follows:
void *
calloc (size_t count, size_t eltsize)
{
size_t size = count * eltsize;
void *value = malloc (size);
if (value != 0)
memset (value, 0, size);
return value;
}
It then all but encourages developers who provide their own malloc() to define
calloc() that way.
This, however, ignores a very significant functionality of calloc(), namely to
guard against overflow errors. Suppose, for example, that size_t is 64 bits
long. Then, for example, calloc(274177, 67280421310721) will return NULL with
an "out of memory" error, whereas malloc(274177 * 67280421310721) will happily
allocate a single byte. The latter can give rise to serious buffer overflow
type vulnerabilities. So one should never implement calloc(c, e) as malloc(c *
e) without checking for overflows.
I suggest to amend the documentation to at least point this out. I.e., change
to:
Ignoring error checking, you could in principle define calloc as follows:
.....
However, note that this implementation is not quite sufficient in practice,
because calloc must also check for overflows in the multiplication count *
eltsize.
Also note that, in general, it is not guaranteed that calloc calls malloc
internally. Therefore, if an application provides its own malloc/realloc/free
outside the C library, it should always define calloc, too.
--
You are receiving this mail because:
You are on the CC list for the bug.