Que ce soit en C ou C ++, dois-je vérifier les paramètres de pointeur par rapport à NULL / nullptr?

Question

Cette question a été inspiré par cette réponse.

J'ai toujours été de la philosophie que le destinataire de l'appel n'est jamais responsable lorsque l'appelant n'a quelque chose de stupide, comme le passage de paramètres non valides. Je suis arrivé à cette conclusion pour plusieurs raisons, mais peut-être le plus important provient de cet article:

Tout n'est pas défini n'est pas défini.

Si une fonction n'est pas dit dans les docs que c'est valable pour la transmission de nullptr, alors vous sacrément bien mieux de ne pas passer nullptr de cette fonction. Je ne pense pas qu'il est de la responsabilité du destinataire de l'appel pour faire face à de tels choses.

Cependant, je sais qu'il va y avoir certains qui sont en désaccord avec moi. Je suis curieux de savoir si oui ou non je devrais vérifier pour ces choses, et pourquoi.

Answer 1

Si vous allez vérifier pointeur NULL arguments où vous n'avez pas conclu un contrat d'accepter et de les interpréter, de le faire avec un assert, pas une condition de retour d'erreur. De cette façon, les bugs en l'appelant sera immédiatement détecté et peut être fixé, et il est facile de désactiver les frais généraux de production s'appuie. Je doute de la valeur de l' assert sauf que de la documentation; cependant, une erreur de segmentation à partir de déréférencement du pointeur NULL est tout aussi efficace pour le débogage.

Si vous retourner un code d'erreur à une personne qui a déjà fait ses preuves buggy, le résultat le plus probable est que l'appelant ignorer l'erreur, et de mauvaises choses vont arriver beaucoup plus tard en bas de la ligne lorsque la cause d'origine de l'erreur est devenue difficile, voire impossible à retracer. Pourquoi est-il raisonnable de supposer l'appelant ignorer l'erreur à votre retour? Parce que l'appelant déjà ignoré le retour en cas d'erreur de malloc ou fopen ou d'une autre bibliothèque spécifique à la fonction d'allocation qui a retourné NULL pour indiquer une erreur!

Answer 2

En C ++, si vous ne souhaitez pas accepter les pointeurs NULL, ne prenez pas cette chance : acceptez plutôt une référence.

Answer 3

Alors qu'en général je ne vois pas l'intérêt de détecter NULL (pourquoi NULL et pas une autre adresse invalide?) Pour une API publique, je le ferais probablement encore simplement parce que de nombreux programmeurs C et C ++ s'attendent à un tel comportement.

Answer 4

Le principe de Défense en profondeur dit oui. S'il s'agit d'une API externe, alors c'est absolument essentiel. Sinon, au moins une assertion pour aider au débogage de l’utilisation abusive de votre API.

Vous pouvez documenter le contrat jusqu'à ce que vous deveniez bleu, mais vous ne pouvez pas empêcher, dans le code appelé, d'empêcher une utilisation abusive mal intentionnée ou malveillante de votre fonction. La décision que vous devez prendre est le coût probable d'une mauvaise utilisation.

Answer 5

À mon avis, ce n'est pas une question de responsabilité. C'est une question de robustesse.

À moins que je maîtrise totalement l'appelant et que je doive optimiser même la vitesse, je vérifie toujours la valeur NULL.