1 = faux et 0 = vrai?
j'ai trouvé une fonction is_equals() dans une API c au travail qui renvoie 1 pour les tables sql non-égales (false) et 0 pour les tables égales (true). Je ne l'ai réalisé qu'après avoir lancé des cas de test sur mon code, un pour l'exemple positif et un pour le négatif et ils ont tous les deux échoué ce qui, au début, avait peu de sens. Le code dans L'API n'a pas de bogue car la sortie a été enregistrée correctement dans sa documentation.
Mes questions - là à l'envers mondes parallèles univers / langages de codage où cette notation logique est normale? Est-ce que 1 n'est pas vrai d'habitude? Le codeur de L'API fait-il une erreur?
6 réponses
il est courant pour les fonctions de comparaison de retourner 0 sur" égal", de sorte qu'ils peuvent également retourner un nombre négatif pour" inférieur à "et un nombre positif pour"supérieur à". strcmp() et memcmp() fonctionnent ainsi.
il est, cependant, idiomatique pour zéro d'être faux et non zéro pour être vrai, parce que c'est la façon dont le C contrôle le flux et les opérateurs booléens logiques fonctionnent. Il se peut donc que les valeurs de retour choisies pour cette fonction soient correctes, est la fonction de nom qui est dans l'erreur (il devrait vraiment être appelé compare() ou similaire).
ce monde à l'envers est commun avec les retours d'erreurs de processus. La variable shell $? rapporte la valeur de retour du programme précédent à exécuter à partir du shell, il est donc facile de dire si un programme réussit ou échoue:
$ false ; echo $?
1
$ true ; echo $?
0
cela a été choisi parce qu'il y a un seul cas où un programme réussit mais il pourrait y avoir des douzaines de raisons pour lesquelles un programme échoue -- en permettant qu'il y ait de nombreux codes d'erreur d'échec différents, un programme peut déterminer pourquoi un autre programme a échoué sans avoir à analyser la sortie.
Un exemple concret est le aa-status programme fourni avec le AppArmor contrôle d'accès obligatoire outil:
Upon exiting, aa-status will set its return value to the
following values:
0 if apparmor is enabled and policy is loaded.
1 if apparmor is not enabled/loaded.
2 if apparmor is enabled but no policy is loaded.
3 if the apparmor control files aren't available under
/sys/kernel/security/.
4 if the user running the script doesn't have enough
privileges to read the apparmor control files.
(je suis sûr qu'il y a des programmes plus répandus avec ce comportement, mais je connais bien celui-ci. :)
je soupçonne qu'il est juste de suivre le Linux / Unix standard pour retour 0 sur le succès .
Fait vraiment dire "1" est faux et "0" est vraie?
il n'y a pas de bonne raison pour que 1 soit vrai et 0 soit faux; c'est juste la façon dont les choses ont toujours été notées. Donc, d'un point de vue logique, la fonction de votre API n'est pas "erronée" en soi.
cela dit, il n'est normalement pas conseillé de travailler contre les expressions idiomatiques de n'importe quel langage ou cadre que vous utilisez sans une raison sacrément bonne de le faire, donc celui qui a écrit cette fonction était probablement assez Osée, en supposant que ce n'est pas simplement un bug.
cela peut très bien être une erreur sur l'auteur original, mais la notion que 1 est vrai et 0 est faux n'est pas un concept universel. Dans shell scripting 0 est retourné pour le succès, et tout autre nombre pour l'échec. Dans D'autres langues comme Ruby, seulement zéro et faux sont considérés comme faux, et toute autre valeur est considérée comme vraie, donc dans Ruby les deux 1 et 0 seraient considérés comme vrais.
Je ne suis pas sûr de répondre à la question correctement, mais voici un exemple familier:
le type de retour de GetLastError() dans Windows est non nul s'il y a eu une erreur, ou zéro autrement. L'inverse est généralement vrai de la valeur de retour de la fonction appelée.