title: Why memset called after calloc?
body: <p>I've researched code of some library and noticed that calls to <code>calloc</code> there are followed by <code>memset</code> for block allocated by <code>calloc</code>.
  I've found this question with quite comprehensive answer on differences between <code>calloc</code> and <code>malloc</code> + <code>memset</code> and calling <code>memset</code> for just before allocated storage:</p>
  
  <p><a href="https://stackoverflow.com/questions/2688466/why-mallocmemset-is-slower-than-calloc">Why malloc+memset is slower than calloc?</a></p>
  
  <p>What i still can't understand is why one would want to do so.
  What are benefits of this operations?</p>
  
  <p>The code example from mentioned above library:</p>
  
  <pre><code>light_pcapng_file_info *light_create_default_file_info()
  {
      light_pcapng_file_info *default_file_info = calloc(1, sizeof(light_pcapng_file_info));
      memset(default_file_info, 0, sizeof(light_pcapng_file_info));
      default_file_info-&gt;major_version = 1;
      return default_file_info;
  }
  </code></pre>
  
  <p>The code of allocated structure(each array contains 32 elements):</p>
  
  <pre><code>typedef struct _light_pcapng_file_info {
      uint16_t major_version;
      uint16_t minor_version;
      char *file_comment;
      size_t file_comment_size;
      char *hardware_desc;
      size_t hardware_desc_size;
      char *os_desc;
      size_t os_desc_size;
      char *user_app_desc;
      size_t user_app_desc_size;
      size_t interface_block_count;
      uint16_t link_types[MAX_SUPPORTED_INTERFACE_BLOCKS];
      double timestamp_resolution[MAX_SUPPORTED_INTERFACE_BLOCKS];
  
  } light_pcapng_file_info;
  </code></pre>
  
  <p><strong>EDIT:</strong></p>
  
  <p>In addition to accepted answer i'd like to provide some info my colleague pointed me to. There was a bug in glibc which, sometimes, prevented calloc from zeroing out memory. Here's the link:
  <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1293976" rel="nofollow noreferrer">https://bugzilla.redhat.com/show_bug.cgi?id=1293976</a></p>
  
  <p>Actual bug report text in case link gets moved:</p>
  
  <p><strong>glibc: calloc() returns non-zero'ed memory</strong></p>
  
  <p>Description of problem:</p>
  
  <p>At Facebook we had an app that started hanging and crashing weirdly when going from glibc-2.12-1.149.el6.x86_64 to glibc-2.12-1.163.el6.x86_64.  Turns out this patch</p>
  
  <p>glibc-rh1066724.patch</p>
  
  <p>Introduced the problem.</p>
  
  <p>You added the following bit to _int_malloc()</p>
  
  <pre><code>  /* There are no usable arenas.  Fall back to sysmalloc to get a chunk from
       mmap.  */
    if (__glibc_unlikely (av == NULL))
      {
        void *p = sYSMALLOc (nb, av);
        if (p != NULL)
         alloc_perturb (p, bytes);
        return p;
      }
  </code></pre>
  
  <p>But this isn't ok, alloc_perturb unconditionally memset's the front byte to 0xf, unlike upstream where it checks to see if perturb_byte is set.  This needs to be changed to</p>
  
  <pre><code>if (p != NULL &amp;&amp; &amp;&amp; __builtin_expect(perturb_byte, 0))
     alloc_perturb (p, bytes);
  return p;
  </code></pre>
  
  <p>The patch I've attached fixes the problem for me.</p>
  
  <p>This problem is exacerbated by the fact that any sort of lock contention on the arena's results in us falling back on mmap()'ing a new chunk.  This is because we check to see if the uncontended arena we check is corrupt, and if it is we loop through, and if we loop to the beginning we know we didn't find anything.  Except if our initial arena isn't actually corrupt we'll still return NULL, so we fall back on this mmap() thing more often, which really makes things unstable.</p>
  
  <p>Please get this fixed as soon as possible, I'd even go so far as to call it a possible security issue.</p>