Discussion :

[Médinoc]

Ben oui: Toute adresse sur laquelle on vient de faire un free() est une adresse invalide, etc.

Mais seul NULL est testable.

[souviron34]

et on en revient à ce qu'on disait :

• inutile avant un return
  
• inutile si on n'a pas à tester la valeur après
  
• inutile si on SAIT qu'on l'écrase par une nouvelle valeur après

or doncques.... ça mange peut-être pas de pain, mais pouquoi mettre une instruction inutile ??

Dans certains cas, bien sûr que c'est utile.. Mais ce que Sve@r et moi disons, c'est que ce n'est pas une régle d'or, loin s'en faut.. Il y a plus de cas où c'est inutile que de cas où c'est utile, et c'est une des quelques remarques que j'avais d'ailleurs à propos de l'échelle de goret... (une autre étant sur le fait de déclarer une variable par ligne.. Si ta routine a 40 variables, la lecture et la compréhension sont complexifiées par rapport à les mettre sur 5 lignes... Et d'ailleurs même avec moins de variables c'est vrai...)

[Thierry Chappuis]

or doncques.... ça mange peut-être pas de pain, mais pouquoi mettre une instruction inutile ??

Parce que c'est peut-être inutile aujourd'hui, mais le code d'une fonction est (souvent?) appelé à évoluer durant la phase de maintenance d'un soft. Adopter une attitude idiomatique ici m'a rendu service bien des fois.

Enfin bon, je ne suis pas un programmeur très expérimenté.

Thierry

[Emmanuel Delahaye]

Je développe depuis peu en C et je commence tout juste à assimiler les concepts de pointeurs et gestion mémoire. Jusqu'à maintenant je n'ai pas vraiment eu de problemes avec la gestion dynamique de la mémoire. Mais là si. Je n'arrive pas à libérer de la mémoire suite à une structure de données un peu spéciale et qui doit sans doute être fausse. J'aimerai bien une petite explication clair du bug.

Quelques remarques.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
 
/* -ed- j'ai une macro globale qui s'appelle TEST et qui vaut 1... */
#undef TEST
 
#include <stdio.h>
#include <stdlib.h>
 
int main(void)
{
	struct TOTO
	{
		int toto1;
	};
 
	struct TEST
	{
		int test1;
		float test2;
		float test3[2];
		struct TOTO *toto;
	};
 
	struct TEST test;
 
	if((test.toto = (struct TOTO*)malloc(50*sizeof(struct TOTO))) == NULL)
	{
		printf("erreur");
	}
 
	test.test1 = 1234;
	int i;
	for(i=0;i<50;i++)
	{
		test.toto[i].toto1 = i;
	}
 
 
	printf("%d\n",test.test1);
	printf("%d\n",test.toto[33].toto1);
        //je libere la memoire de *toto, enfin je croyais
 
   /* -ed- je conseille de metre en oeuvre tout de suite les
           'Bonnes Pratiques'. Remettre le pointeur à NULL apres usage. */
	free(test.toto), test.toto = NULL;
 
	/* -ed- comportement indetermine... */
	printf("%d\n",test.toto[33].toto1);
 
	return EXIT_SUCCESS;
}

A partir du moment où tu as appelé free() avec la valeur retournée par malloc(), le bloc pointé est libéré. Ta manip ne prouve rien, car elle invoque un comportement indéterminé (accès à un bloc libéré).

[Emmanuel Delahaye]

Généralement on regroupe les deux instructions pour montrer qu'elles vont ensemble

Code :

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

free(test.toto), test.toto = NULL;

Mais dans l'absolu c'est quand-même inutile. Pourquoi mettre un pointeur à NULL ? Si on le réaffecte plus tard le NULL sera écrasé par la nouvelle adresse. Et si on ne le réaffecte pas ça veut dire qu'on ne s'en sert plus. Dans tous les cas la valeur "NULL" ne sert à rien...

Ben si. Elle sert à être testée. On ne sait pas par quelles circonvolutions plus ou moins tordues est passé le code avant...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
 
   free(test.toto), test.toto = NULL;
 
   ...
 
   if (test.toto != NULL)
   {
      printf("...", test.toto);
      ...
   }

[souviron34]

Ben si. Elle sert à être testée. On ne sait pas par quelles circonvolutions plus ou moins tordues est passé le code avant...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
 
   free(test.toto), test.toto = NULL;
 
   ...
 
   if (test.toto != NULL)
   {
      printf("...", test.toto);
      ...
   }

c'est bien ce que je disais si tu as un gnere de code comme ca, c'est que ta conception etait incorrecte....

[Emmanuel Delahaye]

Il y a des librairies "blindés" contre ce genre d'erreur qui afficheront (null) sans terminer le programme.

Avec pt, oui. Pas avec *pt... (UB).

[Emmanuel Delahaye]

Logique, pourquoi mettre en memoire toute les fonctions existante au monde ?
Donc on demande selement celle que l'on veut pour les programme en cours ( d'ou l'utilisation des includes ).

Euh, rien à voir... Certains éditeurs de liens savent optimiser les morceaux de bibliothèques qui sont effectivement liés (en embarqué, surtout, pour des raison évidentes de taille de code...). Sur PC, c'est plutôt tout ou rien, d'où une séparation entre flottant et le reste (par exemple, libc.a, libm.a etc.)

Ensuite je competterai en disai que les librairie disponnible sur ton ordinateur, change en fonction de ton ordi.
En général on as les même base exemple :

Code :

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

1
2
3
 
#include <stdio.h>
#include <stdlib.h>

Tu ne sais pas faire la différence entre un header et une bibliothèque. Je crois que ce n'est pas la peine de lire la suite.

Revois d'urgence les bases du langage C et tu pourrais essayer d'intervenir utilement ici...

[Emmanuel Delahaye]

Je rappelle au passage que windows a été développez en grande partie par les concepteurs de VMS<...>

Alors soyons clair, tu parles de Windows NT qui est beaucoup plus stable que l'infâme DOS/Windows... (Quoiqu'un Windows 3.11 bien configuré ne fonctionnait pas si mal...)

Souviron, tu parles de quelle version de Windows ?

[Emmanuel Delahaye]

Euh... il y en a d'autres (d'adresse invalide) ???

Testable ? Rien de standard à part NULL.

[nicolas.sitbon]

Alors soyons clair, tu parles de Windows NT qui est beaucoup plus stable que l'infâme DOS/Windows... (Quoiqu'un Windows 3.11 bien configuré ne fonctionnait pas si mal...)

Souviron, tu parles de quelle version de Windows ?

J'ai le bouquin de richter pour windows 95, donc avant 95 je ne dis pas mais à partir de 95 c'est assuré.

[Emmanuel Delahaye]

et on en revient à ce qu'on disait :

• inutile avant un return
• inutile si on n'a pas à tester la valeur après
• inutile si on SAIT qu'on l'écrase par une nouvelle valeur après

or doncques.... ça mange peut-être pas de pain, mais pouquoi mettre une instruction inutile ??

Dans certains cas, bien sûr que c'est utile..

Comment le savoir par avance ? Le fait de remettre le pointeur à NULL est un principe de programmation saine (encore appelée programmation défensive). Si c'est inutile dans 98% des cas, c'est pas génant, par contre, ce sont les 2% restant qui nous intéressent. Dans un code de 2Mlignes, j'ai pas trop de temps à perdre pour savoir si le = NULL est utile ou non. C'est comme les protections contre les inclusions multiples : c'est inutile dans 80% des cas... N'empêche qu'en faire une pratique systématique permet de 'faire le ménage'...

Mais ce que Sve@r et moi disons, c'est que ce n'est pas une régle d'or, loin s'en fau.. Il y a plus de cas où c'est inutile que de cas où c'est utile, et c'est une des quelques remarques que j'avais d'ailleurs à propos de l'échelle de goret... (une autre étant sur le fait de déclarer une variable par ligne.. Si ta routine a 40 variables, la lecture et la compréhension sont complexifiées par rapport à les mettre sur 5 lignes... Et d'ailleurs même avec moins de variables c'est vrai...)

Pour reprendre une de tes expression pré-citée, "si il y a 40 variables au même endroit, c'est que c'est mal conçu". C'est assez pratique comme réponse (et ça peu même être assez vrai dans certains cas).

Je rappelle que je soutiens le principe de la réduction de la portée des variables (ça fait le ménage) et l'usage des 'contextes' (structures).

[Emmanuel Delahaye]

c'est bien ce que je disais si tu as un gnere de code comme ca, c'est que ta conception etait incorrecte....

Pourquoi ? C'est de la programmation souple. Il peut y avoir des cas où le pointeur est NULL (variable 'optionnelle' non créée) et des cas où il est non NULL (option active)... Tu n'as jamais traité de configurations un peu évoluées ?

[Sve@r]

Ahlàlàlà quelle discussion. Le problème c'est que beaucoup d'arguments sont valables des 2 cotés. D'un coté il y a le programmeur alone qui maîtrise ses pointeurs et qui trouve inutile d'y mettre NULL "inutilement" (si je puis dire) et de l'autre il y a le programmeur qui bosse en équipe et qui, quand il récupère un pointeur venu d'on ne sais-où, aime bien qu'il soit à NULL s'il n'est pas encore utilisé (ce qui lui évite de se poser des questions métaphysiques)
A mon avis je pense qu'on ne pourra jamais dire avec certitude "il faut faire ceci ou cela". Nous tous, programmeurs "habitués du C" que nous sommes et qui sommes tenants d'une philosophie ou d'une autre savons ce que nous faisons et je crois que c'est suffisant.
Pour moi, le truc vraiment important à dire et à faire savoir aux débutants du C, c'est qu'on manipule toujours un pointeur avec précaution.

[souviron34]

Souviron, tu parles de quelle version de Windows ?

bah meme NT que j'ai sur mon Acer d'il y a 1 an 1/2 gele regulierement (un DVD qui demarre pas et qui bloque tout, un truc du style IE qui est fige et bloque tout.. bref... "Panic button"...

[souviron34]

Pour moi, le truc vraiment important à dire et à faire savoir aux débutants du C, c'est qu'on manipule toujours un pointeur avec précaution.

[Emmanuel Delahaye]

J'ai le bouquin de richter pour windows 95, donc avant 95 je ne dis pas mais à partir de 95 c'est assuré.

95 n'est pas un NT. C'est un DOS/Windows.

[Emmanuel Delahaye]

bah meme NT que j'ai sur mon Acer d'il y a 1 an 1/2 gele regulierement (un DVD qui demarre pas et qui bloque tout, un truc du style IE qui est fige et bloque tout.. bref... "Panic button"...

Il est possible que ça vienne de NT, ou des drivers, ou du matériel... (barrette mémoire défectueuse, ventilateur HS...). Il y a des tas de raisons qui peuvent faire planter une bécane, même sous Linux...

[nicolas.sitbon]

95 n'est pas un NT. C'est un DOS/Windows.

Le bouquin s'appelle "Développer sous Windows 95 et Windows NT 4.0" édité chez microsoft press, on le trouve encore sur amazon, j'ai précisé 95 car c'est le plus ancien mais la remarque vaut pour NT.
Autrement j'ai d'autre bouquin de richter plus récent mais ça n'apportera rien de plus à part répéter ce qui a été dit.

[souviron34]

Il est possible que ça vienne de NT, ou des drivers, ou du matériel... (barrette mémoire défectueuse, ventilateur HS...). Il y a des tas de raisons qui peuvent faire planter une bécane, même sous Linux...

ptete ben.. Mais la meme machine sous Linux ne plante jamais ..

et par exemple, avec la JVM, des que je laisse tourner +4h, ca gele tout.... (comment ?? on a dit "garbage collector" ?? ) et ca se voit que c'est la memoire ... il dit "plus assez de place.. augmente la memoire virtuelle...".. et la il en sort jamais...