Pourquoi memset est-il appelé après calloc?

J'ai recherché le code d'une bibliothèque et j'ai remarqué que les appels à calloc sont suivis de memset pour le bloc alloué par calloc . J'ai trouvé cette question avec une réponse assez complète sur les différences entre calloc et malloc + memset et en appelant memset pour juste avant le stockage alloué:

Pourquoi malloc + memset est plus lent que calloc? a >

Ce que je ne comprends toujours pas, c'est pourquoi on voudrait le faire. Quels sont les avantages de ces opérations?

L'exemple de code de la bibliothèque mentionnée ci-dessus:

if (p != NULL && && __builtin_expect(perturb_byte, 0))
   alloc_perturb (p, bytes);
return p;

Le code de la structure allouée (chaque tableau contient 32 éléments):

  /* 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;
    }

En plus de la réponse acceptée, j'aimerais fournir des informations vers lesquelles mon collègue m'a indiqué. Il y avait un bogue dans la glibc qui, parfois, empêchait calloc de remettre à zéro la mémoire. Voici le lien: https://bugzilla.redhat.com/show_bug.cgi?id=1293976

Texte réel du rapport de bogue au cas où le lien serait déplacé:

glibc: calloc () renvoie une mémoire non nulle

Description du problème:

Chez Facebook, nous avions une application qui commençait à se bloquer et à planter bizarrement en passant de glibc-2.12-1.149.el6.x86_64 à glibc-2.12-1.163.el6.x86_64. Il s'avère que ce patch

glibc-rh1066724.patch

A introduit le problème.

Vous avez ajouté le bit suivant à _int_malloc ()

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;

Mais ce n'est pas correct, alloc_perturb memset inconditionnellement l'octet avant à 0xf, contrairement à l'amont où il vérifie si perturb_byte est défini. Cela doit être changé en

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->major_version = 1;
    return default_file_info;
}

Le correctif que j'ai joint résout le problème pour moi.

Ce problème est exacerbé par le fait que toute sorte de la contention de verrouillage sur l'arène nous fait retomber sur mmap () 'ing un nouveau morceau. C'est parce que nous vérifions si l'arène incontrôlée que nous vérifions est corrompue, et si c'est le cas, nous bouclons, et si nous bouclons jusqu'au début, nous savons que nous n'avons rien trouvé. Sauf si notre arène initiale n'est pas réellement corrompue, nous retournerons toujours NULL, donc nous retombons plus souvent sur cette chose mmap (), ce qui rend vraiment les choses instables.

Veuillez corriger cela dès que possible possible, j'irais même jusqu'à appeler cela un problème de sécurité possible.