Discussion :

[Mattness69]

Bonsoir,

Je malloc un char* dans une fonction puis je le remplit dans une autre fonction, ducoup, valgrind me bombarde de

Conditional jump or move depends on uninitialised value(s)

Ma question est : est-ce que c'est grave et surtout est-ce qu'il y a un risque de faire planter le programme ?

PS : Je free absolument tout je n'ai aucune fuite de mémoire

[Bousk]

Ça veut surtout dire que tu as un fonctionnement indéterminé et un check qui dépend de ce qui traînait dans la mémoire avait auparavant.
Faudrait voir le vrai code pour ça, un malloc ou free n'a quasi rien à voir ici.

[Mattness69]

en gros le code source donne ça

Code :

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

1
2
3
4
5
6
7
8
9
while (condition) {
        str1 = realloc(str1, nb1);
        //fill_str(str1, nb1);
        str2 = realloc(str2, nb2);
        //fill_str(rstr2, nb2);
       //je manipule str1 et str2 à l'aide d'autres fonctions 
}
free(str1)
free(str2)

fill_str est une fonction qui va remplir l'intégralité de la string (jusqu'à l'index souhaité) par des '\0' :

Code :

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

1
2
3
4
5
void fill_str(char *str, int len)
{
    for (int i = 0; i < len; i++)
        str[i] = '\0';
}

dans l'exemple, j'ai mis en commentaire l'appel à la fonction fill_str afin d'avoir le warning de valgrind :

Conditional jump or move depends on uninitialised value(s)

[Sve@r]

Bonjour

en gros le code source donne ça

Code :

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

1
2
3
4
5
6
7
8
9
while (condition) {
        str1 = realloc(str1, nb1);
        //fill_str(str1, nb1);
        str2 = realloc(str2, nb2);
        //fill_str(rstr2, nb2);
       //je manipule str1 et str2 à l'aide d'autres fonctions 
}
free(str1)
free(str2)

Il faut impérativement que "str1" et "str2" aient été initialisés. Soit avec un malloc, soit avec NULL.

fill_str est une fonction qui va remplir l'intégralité de la string (jusqu'à l'index souhaité) par des '\0' :

Code :

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

1
2
3
4
5
void fill_str(char *str, int len)
{
    for (int i = 0; i < len; i++)
        str[i] = '\0';
}

Pour aller plus vite je serais passé directement par le pointeur "str" ce qui évite une indirection => for (int i=0; i < len; i++) {*str=0; str++;}.
Mais sinon pourquoi ne pas utiliser memset() qui est justement faite pour ça...?

Ma question est : est-ce que c'est grave et surtout est-ce qu'il y a un risque de faire planter le programme ?

On peut résumer les soucis liés aux variables en deux axiomes élémentaires

1. ne jamais lire une variable sans l'avoir remplie au préalable
2. ne jamais remplir deux fois une variable sans la lire entre temps

Le second axiome peut être plus ou moins négligé et n'aura aucun effet néfaste si c'est le cas (au pire, remplir plusieurs fois la même variable ralentira juste le code sans le corrompre). Il m'arrive d'ailleurs parfois d'initialiser un truc tout en sachant que je pourrai peut-être y re-écrire plus tard sans l'avoir forcément lu entre temps.
Mais le premier reste incontournable. Tu ne pourras jamais avoir un résultat correct si tu ne l'as pas d'abord calculé et éventuellement stocké. Et tu ne pourras jamais calculer le bon résultat si tu n'initialises pas d'abord les variables servant à le calculer. "0" est peut-être l'élément neutre de l'addition mais il est implicite en mathématique et doit être explicité en C.

Et dans ce que tu me montres, fill_str() ne viole aucun de ces deux axiomes. Seul reste l'éventuel souci de "str1" et "str2" non initialisés (et bien évidemment aussi "nb1" et "nb2" cela va sans dire)

[Mattness69]

J'initialise bien str1, str2, nb1 et nb2.

Effectivement, je ne m'étais jamais intéressé à la fonction memset() merci pour ton aide.

Il y a cependant quelque chose que je n'ai pas bien compris

Pour aller plus vite je serais passé directement par le pointeur "str" ce qui évite une indirection => for (int i=0; i < len; i++) {*str=0; str++;}.

Cela représente quoi selon une indirection dans cette exemple ?
Nous n'avons probablement pas la même idée en tête.

[Sve@r]

J'initialise bien str1, str2, nb1 et nb2.

Ca pourrait être plus subtil.
Par exemple ceci

Code c :

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

1
2
3
4
5
6
7
8
9
10
11
12
initialisation str1 et str2
while(truc_a_la_con) {
	while (condition) {
		str1 = realloc(str1, nb1);
		//fill_str(str1, nb1);
		str2 = realloc(str2, nb2);
		//fill_str(rstr2, nb2);
		//je manipule str1 et str2 à l'aide d'autres fonctions 
	}
	free(str1);
	free(str2);
}

Ca fonctionnera à la première itération puis partira ensuite en torche parce que les free() auront rendu "str1" et "str2" totalement invalides aux realloc suivants. Nul doute que valgrind verrait ce genre de souci.

Cela représente quoi selon une indirection dans cette exemple ?
Nous n'avons probablement pas la même idée en tête.

Une indirection c'est chaque fois qu'on écrit t[x] ("t" étant un tableau quelconque). Le compilateur le traduit par

• déplacement au début du tableau
• décalage de "x" positions

Imagine par exemple tout le travail qui sera généré dans ces simples lignes

Code c :

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

1
2
3
int tab[]={1, 2, 3, 4, 5};
for (i=0; i < 5; i++)
	printf("Le carré de %d est %d\n", tab[i], tab[i] * tab[i]);

Et c'est encore pire quand on utilise un tableau de structures au lieu d'un tableau de types élémentaires...

Si on utilise un pointeur déjà placé à la bonne case, ces deux opérations disparaissent.
Imagine alors ce que tu gagnes en modifiant le code ainsi

Code c :

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

1
2
3
4
int tab[]={1, 2, 3, 4, 5};
int *pt;
for (i=0, pt=tab; i < 5; i++, pt++)
	printf("Le carré de %d est %d\n", *pt, (*pt) * (*pt));

C'est pas super compliqué à transformer. C'est ce que j'ai fait avec ta fonction et là c'était encore plus facile vu que j'avais déjà le pointeur disponible dans le paramètre reçu. J'ai même été tenté d'écrire for (i=0; i < len; i++, *(str++)=0); mais mis à part rendre le code juste plus compliqué à relire, on ne gagne rien et ça fait juste ressortir mon manque de mémoire des 14 priorités des opérateurs du C vu que j'ai mis des parenthèses dont je ne suis pas certain qu'elles soient nécessaires.