calloc() ou malloc() ?

Bonjour,

Alors voilà je suis débutant en C et je conçoit en ce moment un programme qui, sans rentrer dans les détails, a besoin d'être très très optimisé au niveau de la gestion mémoire.

De ce que j'ai appris sur internet, la différence entre calloc() et malloc() vient du fait que calloc() initialise la zone reservé à 0 alors que malloc() se contente juste de réserver la zone.

Cependant j'ai aussi entendu dire que avec calloc() il y avait un truc sur l'allocation des blocs de la zone reservé, comme quoi c'était moins économe en mémoire dans certaines implémentations que malloc().

J'ai cherché plus d'infos sur internet mais je sais pas trop a quoi m'en tenir.

Je suis preneur de toute explication :)

Merci d'avance de vos réponses.

A part le fait que calloc initialise tout à 0 et donc qu'il est moins rapide que malloc, je ne pense pas qu'il y ai réellement de différences.

malloc est très utile lorsqu'on est sûr de remplir la zone avant de la lire.
calloc est plutôt utilisé pour tout initialisé à 0 lorsqu'on est pas sûr de remplir cette zone avant de la lire, cela évite donc des segfault avec les pointeurs.

Code:

---

cela évite donc des segfault

---

Cela n'évite pas plutôt de lire n'importe quoi ? La zone nous étant allouée, on peut y lire sans risque.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#include <stdlib.h> #include <stdio.h>   int main(void) {   char *pt_test = malloc(sizeof(char)*100); int i=0;   for(i=0;i<100;i++) { printf("(%d)%c", i, *(pt_test+i)); }   return 0; }

---

EDIT : j'ai trouvé ce lien intéressant. Celui-ci l'est également.

Si tu fait un malloc pour une structure contenant des pointeurs, et que tu utilises directement ces pointeurs, tu vas avoir un segfault sans savoir d'où il vient car tu vas écrire sur un espace qui ne t'appartient pas.

Alors que si tu fais un calloc, les pointeurs seront tous NULL.

Citation:

---

Envoyé par Neckara

Si tu fait un malloc pour une structure contenant des pointeurs, et que tu utilises directement ces pointeurs

---

Si tu fais des conneries, c'est normal d'avoir n'importe quoi comme resultat....

Si tu as besoin d'une zone memoire, et que immediatement apres tu remplis celle-ci entierement avec des valeurs (correctes s'entend), alors le fait d'initialiser a 0 entre les deux ne sert a rien.

En revanche, si tu alloues un espace memoire, puis qu'un programme externe doit l'utiliser, tu dois te proteger de toutes les conneries que pourrait faire ce programme, et donc tu dois initialiser la zone memoire a 0, afin que le programme appelant puisse faire toutes les betises qu'il souhaite.

Citation:

---

Envoyé par Neckara

Si tu fait un malloc pour une structure contenant des pointeurs, et que tu utilises directement ces pointeurs, tu vas avoir un segfault

---

Normal. Tu n'accèdes dans ce cas pas à la zone que tu viens d'allouer, mais à une autre zone. Je ne pensais pas à ce genre d'utilisation dans mon exemple, qui se bornait à lire la zone allouée.

Citation:

---

Envoyé par Neckara

Alors que si tu fais un calloc, les pointeurs seront tous NULL.

---

Visiblement, ce n'est pas certain d'après mon premier lien. dont voici un extrait :

Citation:

---

calloc's zero fill is all-bits-zero, and is therefore guaranteed to yield the value 0 for all integral types (including '\0' for character types). But it does not guarantee useful null pointer values (see section 5 of this list) or floating-point zero values.

---

Je ne savais pas que NULL n'était pas toujours égal à 0.

Calloc permettra tout de même de vite retrouver l'erreur.
On verra que le pointeur vaut 0 donc on fera vite le lien.

Pour un programme externe, il faudra qu'il vérifie si le pointeur ne vaux pas '0' (et/ou NULL dans certains cas).

Pourquoi dans ce cas ne pas initialiser un pointeur explicitement à NULL, à défaut de pouvoir l'initialiser avec une adresse valide?

Thierry

Et si tu alloue un espace mémoire mais que tu ne sais pas à quelle structure tu veux l'associé tu fait comment?

Ex :

Code:

---

1 2 3 4 5 6 7 8 9 10

structure 1 { int a; int *b; }   structure 2 { int *b; int a; }

---

Citation:

---

Envoyé par Neckara

Et si tu alloue un espace mémoire mais que tu ne sais pas à quelle structure tu veux l'associé tu fait comment?

Ex :

Code:

---

1 2 3 4 5 6 7 8 9 10

structure 1 { int a; int *b; }   structure 2 { int *b; int a; }

---

---

Salut
Tu peux aussi passer par memset() :mouarf1:

Bon sans rire, c'est juste pour dire qu'il n'y a jamais qu'une seule solution à un pb. Mais pour revenir au point principal, la réponse est aussi simple qu'évidente => on utilise calloc() si et seulement si on a spécialement besoin d'avoir 0 dans octets alloués :lahola:

Quand à dire "pourquoi on peut avoir besoin" ben chacun a ses raisons... :ccool:

Citation:

---

Envoyé par Sve@r

Salut
Tu peux aussi passer par memset() :mouarf1:

---

ça ne marchera pas si la même zone est prévue soit pour un pointeur où NULL = 0 soit pour un pointeur où NULL != 0

Et même dans ce cas, si on a un pointeur où NULL != 0
Et que finalement, on prend l'autre structure, on a donc un int != 0

Plus tard, comment fais-tu pour savoir si ton int vaut x parce que tu n'as pas encore écrit dessus ou parce que tu as dit que l'int vaut x? Sachant que tu n'es pas censé connaitre x.

Dans le cas où tu aurais des pointeurs et des flottants, il ne faut pas initialiser avec la zone avec des 0 et donc calloc n'est pas approprié. Il faut faire une initialisation de la zone avec des valeurs correctes, notamment en mettant explicitement les pointeurs à la valeur NULL, les flottants 0,00, le reste à 0. Une initialisation, ce n'est pas forcément mettre des zéros, cela peut-être d'autres valeurs ; si tel est le cas, ce n'est pas calloc qu'il faut utiliser.

Certains ont-ils lu le 2e lien que j'ai donné ? La réponse donnée est assez imbuvable mais le mec dit des trucs intéressants (si c'est vrai :lol: ) comme :

Citation:

---

The "calloc" implementation just changes a few page tables, consumes very little actual memory, writes to very little memory, and returns. On most systems you can even allocate more memory than your system can support (more than RAM + swap) without problems, as long as you don't write to all of it. (This feature is slightly controversial on the operating systems that allow this.)

---

- On peut se demander comment dans ce cas, la fonction d'allocation répond correctement à la contrainte de renvoyer NULL en cas d'échec d'allocation. La réponse ne peut pas être différée jusqu'au moment où on s'aperçoit que la mémoire qu'on veut utiliser n'existe pas. Ou alors de telles implémentations des fonctions d'allocation ne respectent pas la norme du C.

- A propos de NULL, la norme dit :

Citation:

---

6.3.2.3 Pointers
....
3 An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.55) If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.

55) The macro NULL is defined in <stddef.h> (and other headers) as a null pointer constant; see 7.17.

---

La norme parle de la conversion de NULL en un type pointeur mais ne précise pas la représentaion binaire résultant de cette conversion : un cast (implicite ou explicite) peut très bien modifier la représentation binaire d'une grandeur, ce n'est pas une simple réinterprétation d'une configuration binaire.

Citation:

---

Envoyé par Neckara

Pour un programme externe, il faudra qu'il vérifie si le pointeur ne vaux pas '0' (et/ou NULL dans certains cas).

---

Tester par rapport à 0 (et non '0' qui est le caractère) ou par rapport à NULL revient au même. NULL étant un define sur 0, (void*)0, ou quelque chose de similaire.

Le lien de Bktero indique qu'un pointeur NULL n'a pas forcément tout ces bits à 0 (ce ue fait calloc) et donc qu'un memset à 0, calloc ou autre initialisation d'une zone mémoire à "tous les bits à 0" ne fonctionne pas forcément sur les pointeurs (ni sur les réels d'ailleurs), uniquement sur les types entiers.
Mais char* ptr = NULL et char* ptr = 0 sont malgré tout équivalent

Content de constater que ma question déchaine encore les passions :D

Je vous remercie à tous de vos réponses, un merci particulier à Bktero dont le second lien m'a bien renseigné (si le gars sais de quoi il parle ^^).

Citation:

---

Envoyé par gl

Tester par rapport à 0 (et non '0' qui est le caractère)

---

Mea culpa, j'ai posté un peu trop vite^^, je voulais bien sur dire 0x00 (comme ça on évite toute confusion)

Citation:

---

Envoyé par gl

Le lien de Bktero indique qu'un pointeur NULL n'a pas forcément tout ces bits à 0 (ce ue fait calloc) et donc qu'un memset à 0, calloc ou autre initialisation d'une zone mémoire à "tous les bits à 0" ne fonctionne pas forcément sur les pointeurs (ni sur les réels d'ailleurs), uniquement sur les types entiers.
Mais char* ptr = NULL et char* ptr = 0 sont malgré tout équivalent

---

C'est pour cela qu'on va tout initialiser à 0 si on ne sait pas quels types de pointeur on va utiliser, ainsi si tout la zone mémoire vaut 0x00, on sera sûr que le pointeur n'a pas été initialisé

Code:

---

1 2 3 4 5 6

void *pointeur; if(0 == *(int *)&ton_pointeur) //dans le cas où sizeof(ton_pointeur) = sizeof(int) { //ton_pointeur n'est pas initialisé }

---

Citation:

---

Envoyé par Neckara

C'est pour cela qu'on va tout initialiser à 0 si on ne sait pas quels types de pointeur on va utiliser, ainsi si tout la zone mémoire vaut 0x00, on sera sûr que le pointeur n'a pas été initialisé

---

La zone de mémoire sera initialisée à "tous les bits à 0". Il faut juste être bien conscient que s'il y a des pointeurs dedans, ils ne vaudront pas forcément NULL (ou 0).

Citation:

---

Envoyé par Neckara

Code:

---

1 2 3 4 5

void *pointeur; if(0 == *(int *)&ton_pointeur) //dans le cas où sizeof(ton_pointeur) = sizeof(int) { //ton_pointeur n'est pas initialisé }

---

---

Outre le problème de la taille (sizeof(T*)==sizeof(int)), c'est horriblement compliqué (alors qu'il est tellement simple d'initialiser correctement sa structure, son tableau, etc. avec des valeurs correctes plutôt que de simplement faire un calloc ou un memset à 0), je ne suis pas certain du tout que ce code est un comportement défini.

Tu alloues un espace mémoire.

Mais cet espace mémoire n'est pas typé, tu peux mettre tout ce que tu veux dedans.

Comme je le répète, si tu ne sais pas ce que contiendra cet espace (plusieurs structures possibles, union, ...) et que tu n'es pas sûr de bien écrire avant de lire.

Comment vous faites?
Tu l'initialises correctement, oui mais comment? Tu ne connais pas le contenu.

Alors que si tu met tout les octets à 0, quand tu verras que tous les octets, sont à 0 tu seras sûr que les pointeurs ne sont pas initialisé.
/!\ je n'ai pas dit qu'ils sont NULL

Citation:

---

Envoyé par Neckara

Comme je le répète, si tu ne sais pas ce que contiendra cet espace (plusieurs structures possibles, union, ...) et que tu n'es pas sûr de bien écrire avant de lire.

Comment vous faites?
Tu l'initialises correctement, oui mais comment? Tu ne connais pas le contenu.

---

J'ai vraiment du mal à voir un cas de figure où tu alloues de la mémoire sans savoir ce qu'elle va contenir (et terme de type pas de valeur) et où il est possible d'avoir des pointeurs dedans (ce qui en gros exclue tout ce qui est buffer de lecture, de réception, etc.).
En général quand j'alloue de la mémoire c'est pour y mettre quelque chose.

Et même dans les cas où je ne sais pas précisément ce que ça va contenir lorsque j'alloue je le sais avant d'aller relire et exploiter le contenu (par exemple au moment où je la remplie).

Citation:

---

Envoyé par Neckara

Alors que si tu met tout les octets à 0, quand tu verras que tous les octets, sont à 0 tu seras sûr que les pointeurs ne sont pas initialisé.
/!\ je n'ai pas dit qu'ils sont NULL

---

Il faudrait vérifier dans la norme pour être certain, mais sur une archi où NULL ne vaut pas "tous les bits à 0", je ne suis pas sur que "tous les bits à 0" ne puisse pas être une valeur valide pour un pointeur.

Il y a quelque chose que j'ai du mal à suivre dans ton discours, gl. Tu viens de dire :

Code:

---

Il faudrait vérifier dans la norme pour être certain, mais sur une archi où NULL ne vaut pas "tous les bits à 0", je ne suis pas sur que "tous les bits à 0" ne puisse pas être une valeur valide pour un pointeur.

---

Ce qui veut dire que : "tout les bits à zéro" peut être différent de "null".

Or, plus tôt tu as dit :

Code:

---

Mais char* ptr = NULL et char* ptr = 0 sont malgré tout équivalent

---

Est ce que cela signifie que l'écriture est équivalent dans le code mais que le compilateur va traduire les deux expressions de la même façon ?

En extrapolant, les tests ptr==NULL et ptr==0 ne sont pas contre pas équivalents ?

Citation:

---

Envoyé par Bktero

Est ce que cela signifie que l'écriture est équivalent dans le code mais que le compilateur va traduire les deux expressions de la même façon ?

En extrapolant, les tests ptr==NULL et ptr==0 ne sont pas contre pas équivalents ?

---

NULL un define sur 0, (void*)0 ou quelquechose d'équivalent. Dans un contexte de pointeur, l'utilisation de 0 ou de NULL est équivalente (aussi bien lors d'un test que sur l'initialisation).

Par contre, toujours dans un contexte de pointeur, ni NULL ni 0 ne signifie forcément "tous les bits sont à 0".

OK c'est simplement une distinction entre les valeurs dans le code et les représentations binaires en mémoire. Pour un pointeur, NULL = 0 mais != (des fois, souvent) "tous les bits à zéro". Merci pour les éclaircissements !