Discussion :

[minibus]

Bonjour,
j'ai remarqué dans un code que lorsqu'il utilise la fonction free() (dans le code il s'agit de g_free() mais elle se comporte comme free()), l'auteur réinitialise la variable à "NULL", sur la même ligne. Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

g_free (file_name), file_name = NULL;

Jusqu'ici je me contentait d'utiliser free() seule, et je n'ai jamais eu de problème. Quelle est la différence ? Cela rend le code plus "propre" ou est-ce une simple "manie" de programmeur ?
Merci d'avance pour vos éclaircissement !

[Franck.H]

Salut !


Non ce n'est pas une simple manie de programmeur, c'est une bonne façon de faire surtout si tu es amené à réutiliser ce pointer ou que tu le fasse sans le vouloir. Le truc en fait c'est que lorsque tu libère ton espace mémoire, il n'est plus valide, même s'il possède une valeur quelconque après le free.

L'initialiser à NULL permet déjà d'une, de pouvoir par exemple tester la variable pour un test de validité par exemple mais aussi d'éviter des comportement indéterminés et ensuite trouver l'erreur dans un grand chose n'est jamais chose aisée.

Le faire alors que le programme va quitter n'a que peu d'intérêt mais dans les autres cas c'est une précaution et en C il en faut un maximum

[diogene]

Mettre file_name à NULL après le free() permet d'avoir pour file_name une valeur légale qui permet de savoir qu'il ne pointe sur "rien".
Bien sûr, cela ne sert à rien si file_name n'est pas utilisé ultérieurement (par exemple, file_name est une variable locale et on est à la fin de la fonction).

Personnellement, je suis assez réservé sur une utilisation de cette pratique simplement "par sécurité", parce que cela indique que justement on n'est pas très sûr de ce qu'on fait (par exemple, on cherche à se garantir d'un double free, mais c'est alors parce qu'on ne sait pas trop où et par qui le free est normalement fait). Mieux vaut planter le plus tôt possible que continuer à développer un code mal maîtrisé.
C'est la même chose pour le principe d'initialiser systématiquement les pointeurs à NULL au moment de leur création si cette valeur n'est pas pertinente pour la suite du code.

[souviron34]

C'est la même chose pour le principe d'initialiser systématiquement les pointeurs à NULL au moment de leur création si cette valeur n'est pas pertinente pour la suite du code.

Autant je suis d'accord avec toi pour le reste, autant sur ce point-là, non..

Une variable non-initialisée est prise sur la pile.

Si il y a nombre de niveaux de profondeurs, avec allocations, et paramètres, qui font que la taille de la pile est dépassée, un pointeur non-initialisé n'aura plus de sens à une certaine profondeur , et permettra donc à une fonction d'en bas d'aller jardiner dans le tableau d'en haut (bug déjà arrivé dans une grosse appli sur laquelle j'ai travaillé (Matra), et extrêmement difficile à déceler)

[orfix]

Une variable non-initialisée est prise sur la pile.

Une variable initialisée aussi, non ? (variable locale à une fonction)

[souviron34]

Une variable initialisée aussi, non ? (variable locale à une fonction)

et comment stockes-tu sa valeur d'initialisation dans le binaire ??

[Jean-Marc.Bourguet]

et comment stockes-tu sa valeur d'initialisation dans le binaire ??

Une variable locale est sur la pile. Sa valeur d'initialisation est quelque part (où, on s'en fout, peut-être n'y at'il simplement que du code qui l'initialise sans recopier quelque chose).

Une variable statique de fonction ou non ne se trouve pas dans la pile. Elle n'est initilisée qu'une fois, au chargement.

[orfix]

Dans le segment de code ?

Code foo.c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
void foo(void)
{
	int a = 5;
	(void)a;
}

Code foo.s :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
foo:
	push	ebp
	mov	ebp, esp
	sub	esp, 16
	mov	DWORD PTR [ebp-4], 5
	leave
	ret
	.size	foo, .-foo

[gl]

C'est la même chose pour le principe d'initialiser systématiquement les pointeurs à NULL au moment de leur création si cette valeur n'est pas pertinente pour la suite du code.

Autant je suis d'accord avec toi pour le reste, autant sur ce point-là, non..

Personnellement, je rejoins l'avis de diogene : si la valeur NULL n'est pas pertinente, pourquoi initialiser la variable avec ? Pourquoi ne pas directement initialiser la variable avec la valeur correcte ?

[souviron34]

Personnellement, je rejoins l'avis de diogene : si la valeur NULL n'est pas pertinente, pourquoi initialiser la variable avec ? Pourquoi ne pas directement initialiser la variable avec la valeur correcte ?

d'une part parce qu'on mélange 2 choses (la déclaration de la variable et l'opération qui va la remplir) , d'autre part parce que, lorsque tu débuggues, c'est nettement plus difficile de savoir où ça plante si tu as plusieurs allocs dans tes initialisations, et enfin parce que si c'est fait dans les initialisations il est plus aisé de sauter sur les tests ou les actions à prendre si l'allocation s'est mal passée, ou si les allocations devaient être faites en cascade..