Bien gérer les pointeurs

Bonjour,

Dans le but de bien coder et éviter tout bug de mon code, comment traiter un pointeur avant de l'utiliser c'est à dire mettre un point ou un -> après?

Code:

---

1 2	if (pTable->GetValue(6)) ((CBCGPGridItem*)(pTable->GetValue(6)))->AddFieldYard(*cClass);

---

(ici GetValue retourne un pointeur)
ne suffit pas je pense car quelquefois les pointeurs prennent des valeurs non valides mais pas NULL: 0xCCCCCCCC, 0xCDCDCDCD, etc*

Je ne sais pas si je trop prévoyant mais les codes open source que j'ai regardé ne prêtent pas attention à cela!! Or je pense qu'il faut toujours tester un pointeur avant de l'utiliser, quelquefois, on a déjà libéré le pointeur avant

Il faut toujours initialiser ses pointeurs. Et bien évidemment les tester avant usage pour vérifier qu'ils ne sont pas égaux à NULL.

Citation:

---

Envoyé par TheGzD

Il faut toujours initialiser ses pointeurs. Et bien évidemment les tester avant usage pour vérifier qu'ils ne sont pas égaux à NULL.

---

C'est un peu ce que j'avais dit!
Un pointeur non NULL ne veut pas dire OK !!!

Un article en anglais relevait les 5 erreurs en programmation C++:
1. Null Pointer dereference
2. Null pointer dereference from function
3. Memory leaks
4. Array index out of bounds
5. Uninitialized variables

http://kloctalk.klocwork.com/?tag=nu...er-dereference

Ce que j'aimerais apprendre c'est comment gérer 1. Null Pointer dereference

Un truc comme cela ? (ou alors je n'ai pas compris)

Code:

---

1 2 3 4 5 6 7 8 9

... if(ptr == NULL) { // leve une exception ou retourne une erreur (au choix) throw exception; return false; } int ma_variable = *ptr; ...

---

Bonjour,

Pour gérer un pointeur non NULL mais pointant vers une méthode ou un membre donnée incorrect on pourrait être tenter de gérer l'exception résultante (via try / catch par exemple) mais c'est une très mauvaise idée.

On trouve souvent ce genre de problème lors de tests d'injection de fautes sur programmes.

La solution est de prendre le problème à l'envers: non pas "comment je gère ce problème ?" mais se demander plutôt "comment puis-je pour que cela n'arrive pas !"

Chaque problématique appelle une solution précise.

Exemple: Dans le cas d'un "use after free" - utilisation d'un pointeur ou de données en mémoire alors que le pointeur (ou le bloc mémoire) a déjà été libéré - il faut s'assurer que justement on ne va pas tenter d'utiliser un pointeur déjà libérer.

Solution: Quand un pointeur est libéré, on le force automatiquement à NULL et tous les tests subséquents s'effectueront sur NULL, comme le montre l'exemple de ram-0000.

La base de donnée des faiblesses communes en programmation s'appelle CWE (Common Weakness Enumeration), je la recommande vivement:

http://cwe.mitre.org/data/index.html

Exemple avec le CWE-416 (use after free) :

http://cwe.mitre.org/data/definitions/416.html

Je suis entrain de lire ce tuto: http://loic-joly.developpez.com/tuto...mart-pointers/ pour voir si ça me convient?

Neitsa, je ne comprends pas bien où veux-tu en venir?

Si tu sais avec précision que tu n'utilises plus ton pointeur tu l'initialises à NULL

Code:

---

1 2 3 4 5 6 7

// work work work... if(pObject) { delete pObject; // bon j'en finis avec pObject = NULL; // et je le ramène à NULL pour prévenir. }

---

New est un opérateur retournant un pointeur, donc à gérer aussi!

Que diriez-vous si je fais à partir de maintenant cette transformation à chaque utilisation de NEW

Code:

---

1 2 3 4 5 6

CLoad* pSET = new CLoad(44, NULL);   if (pSET) { m_pListEntity->push_back(pSET); }

---

devient

Code:

---

1 2 3

std::auto_ptr<CLoad> pSET(new CLoad(44, NULL)); m_pListEntity->push_back(pSET.get()); pSET.release();

---

Utilisation de auto_ptr dans l'en-tête <memory>