Should GC.realloc(null, N) be the equivalent of GC.calloc or GC.malloc?

[Ali Çehreli via Digitalmars-d]

On 07/17/2014 03:35 PM, Rainer Schuetze wrote:

 > On 17.07.2014 23:52, Ali Çehreli wrote:
 >> When called with an existing buffer, GC.realloc conditionally clears the
 >> newly extended part of the memory. An excerpt from druntime/src/gc/gc.d:
 >>
 >> void *realloc(void *p, size_t size, uint bits = 0, size_t *alloc_size =
 >> null, const TypeInfo ti = null) nothrow
 >> {
 >>      // ...
 >>
 >>      if (p !is oldp && !(bits & BlkAttr.NO_SCAN))
 >>      {
 >>          memset(p + size, 0, *alloc_size - size);
 >>      }
 >>
 >>      return p;
 >> }
 >  >
 >  > (Disclaimer: Although undocumented, I assume that clearing the memory
 >  > is an intended feature of GC.realloc.)
 >  >
 >
 > It clears the memory beyond the requested size. This is usually not
 > accessible to the user (at least if he didn't provide the alloc_size
 > parameter).

Ah! You're right. My brain is not working properly lately.

However, this side question that need not be answered remains: If I 
started with GC.calloc, shouldn't GC.realloc give me memory that is 
cleared? Or at least don't I deserve a GC.recalloc()?

But wait: Do I want to complicate realloc even further? NO! :p

Ali