Discussion :

[gl]

Régle n°1 quand on déréference un pointeur pouvant être NULL : on test si le pointeur est NULL avant de déréférencer.

Comment distingues-tu un pointeur pouvant être NULL d'un pointeur ne pouvant pas l'être par design ? Sans aller lire l'intégralité du code correspondant (auquel tu n'as pas nécessairement accès d'ailleurs) ou la doc qui a de grand chance d'être ailleurs et incomplète.

C'est le sens de la remarque de Pyramidev.


Les pointeurs en C peuvent, grosso modo, avoir trois cas utilisations : l'allocation dynamique, la "référence" sur un objet existant (ou une partie de celui-ci) et les objets optionnels. Et tu n'as pas de manière d'indiquer, dans le code, dans quel cas tu es et donc s'il est nécessaire de tester la nullité.
Certes on peut partir du fait qu'il faut donc le faire systématiquement, mais ça ouvre la porte aux erreurs d'étourderie, à la négligence et autre. Alors que les langages qui indiquent clairement les différents ne vont bien évidement pas rendre toute erreur impossible mais :

• En rendant les constructions où il est nécessaire de tester moins banales, vont réduire la négligence et les étourderies
• Vont attirer plus facilement l'attention sur cette problématique qu'un simple pointeur lors d'une évolution, d'une revue de code ou d'un refactoring
• Permettent de mettre des contrôles spécifiques dans les compilateurs et les outils d'analyse statique qui vont lever des alertes sur les utilisations sans test préalables. C'est théoriquement possible de le faire en C sur les pointeurs mais c'est plus difficilement acceptables et va occasionner soit des faux positifs en quantité, soit la présence de tests inutiles

Cette non distinction des cas d'usage des pointeurs se posent aussi lorsqu'il s'agit de savoir s'il s'agit d'un pointeur possédant (et donc qu'il faut que nous libérions) ou non. C'est tout aussi grave et là il n'est même pas possible d'avoir une règle générique.