Discussion :

[kidpaddle2]

Même si j'avance mon nouveau projet en parallèle, je reste coincé quant à celui-ci : personne ne peut m'aider, svp ?

[souviron34]

d'autre part, à ce sujet, j'avais déjà signalé, mais je me demande bien pourquoi on met

Code :

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

#define bool int

et non pas

Code :

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

#define bool char

ce qui fait quand même économiser 3 octets par valeur.... (en moyenne )

[souviron34]

Très intéressante la comparaison avec le principe d'incertitude... par ailleurs, d'après ce que je vois, le mode debugger allouerait plus de mémoire qu'il n'en est nécessaire (je suis sous Code::Blocks) ?

je dirais même plus : systématiquement l'usage d'un debugger ou d'un outil incluant un debugger modifie le comportement vis-à-vis de la mémoire... car en général il "surveille" grâce à ses propres mallocs/frees, et est lui-même en général chargé ce qui modifie signaficativement les segments utilisés...


Et enfin c'est un comportement symptomatique bien connu d'un problème de fuite de mémoire..

[souviron34]

et en passant rapidement sur le code original, je m'aperçois que :

• Pas de test si les allocations/réallocations se sont correctement effectuées.
• Donc des copies et des frees potentiellement erronés
• Une erreur de longueur d'allocation (débordement) :
  
  

  Code :

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

  1
  2
      This->list[This->count-1] = malloc( (strlen(path)+1) * sizeof (char));

En passant en 3 minutes...

[DaZumba]

Code :

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

#define bool char

ce qui fait quand même économiser 3 octets par valeur...

...mais peut augmenter la taille du code (et le temps d'execution) s'il y a beaucoup de conversion a faire vers int. Si on est limite en memoire, char est bon choix. Sinon, il y a peu de raisons de ne pas utiliser int.

[souviron34]

...mais peut augmenter la taille du code (et le temps d'execution) s'il y a beaucoup de conversion a faire vers int.

bah à ce compte-là pourquoi utiliser un booléen ??

c'est bien 0 ou 1, si mes souvenirs sont bons

Donc pourquoi stocker dans une variable qui peut aller jusqu'à INT_MAX ??

256 valeurs c'est déjà largement suffisant pour en représenter 2....

Et si il y a beaucoup de conversion vers int c'est qu'on a mal choisi sa variable....

[Médinoc]

Je rappelle que les paramètres de fonction sont facilement promus en Int, et que les procs les plus rapides ne savent pas faire des opérations (même des comparaisons à zéro) sur plus petit...

[DaZumba]

Je rappelle que les paramètres de fonction sont facilement promus en Int, et que les procs les plus rapides ne savent pas faire des opérations (même des comparaisons à zéro) sur plus petit...

... et je complete que la norme precise que le resultat des operateurs relationnels (< > <= >=) et des operateurs d'egalite (== !=) est de type int (6.5.8, 6.5.9). int est donc un type naturel pour quelque-chose qui se retrouve dans un if()...

bah à ce compte-là pourquoi utiliser un booléen ??

Exactement. Perso, je n'en ai jamais eu besoin...

[souviron34]

..Exactement. Perso, je n'en ai jamais eu besoin...

Moi une seule fois, pour compléter des types de données (réels, entier, chaines, char, et booléen (donc char ) ).

[kidpaddle2]

Le débat portant sur la justification d'un type booléen fait rage, à ce que je vois, mais je rappelle que ce n'est pas le sujet de ce topic. En revanche, suite à une des réponses de souviron34 -que je remercie donc, en plus de ceux qui ont daigné répondre ^^ -, que voilà :

Une erreur de longueur d'allocation (débordement) :

Code C :

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

This->list[This->count-1] = malloc( (strlen(path)+1) * sizeof (char));

Avec cette modification, le programme s'exécute sans problème, que ce soit en mode release ou debug. Après avoir réfléchis un peu par la suite, j'ai émis l'hypothèse que cette distinction debug/release soit due à une potentielle initialisation du segment de mémoire utilisé par le programme (par le debugger) à 0. Ainsi, l'absence du caractère NULL final serait comblée par sa présence au sein du reste de la mémoire...

Enfin bref, tout ça pour dire que l'aiguille a finalement été trouvée dans cette botte de foin, et que le sujet est conséquemment résolu

Merci à vous tous.