This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug malloc/18092] New: calloc documentation omission


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]