Est-il sécuritaire d'appeler les fonctions de avec des arguments de caractère?

L'historique derrière le type Char est qu'il était à l'origine le type utilisé pour décrire les caractères ASCII 7 bits. Dans le même temps, c Manque de type integer 8 bits séparé. Donc, dans les jours de pré-standard des années quatre-vingt, certains compilateurs fabriqués sans signé - car il n'a pas de sens d'avoir des indices négatifs dans une table de symboles, tandis que d'autres compilateurs ont fait char Signé, pour le rendre cohérent avec tous les autres types entier.

Quand le temps est venu de normaliser c, les deux versions existaient. Malheureusement, le Comité a décidé de le laisser rester de cette façon, laissant la décision au compilateur. Au lieu de cela, ils ont ajouté deux autres types: signé Char et non signé Char . SIGNÉ CHAR fait partie des types d'entiers signés, Unsigned Char fait partie des types d'entiers non signés et Char fait partie de l'un ni l'autre Doit avoir la même représentation que l'un ou l'autre signé caractère ou non signé Char . (Ceci est tout décrit dans C11 6.2.5)

notamment, Char n'a jamais été quelque chose que 8 bits sur toutes les implémentations connues, économisez de certains DSP de boules d'odeur exotiques qui fonctionnaient avec 16 bitts. Lorsque des tables de symboles "étendues" ont été utilisées, la mise en œuvre est passée de 7 à 8 caractères bits, soit wchar_t a été utilisé. Veuillez noter que wchar_t est dans la langue C depuis le début, supposant ainsi que Char était à un moment donné pour des éléments tels que UTF8 est probablement incorrect (bien possible théoriquement).

maintenant si Char est signé et que vous stockez une valeur supérieure à char_max ou plus petit que char_min à l'intérieur, vous invoquez un comportement non défini, conformément au C11 6.5 §5. Point final. Donc, si vous avez un tableau de Char et n'importe quel article à l'intérieur, il enfreint les limites de type, vous avez déjà un comportement indéfini là-bas. Même si les types de caractères doivent piéger des représentations, un comportement indéfini pourrait entraîner une mauvaise conduite du code d'une autre manière, telles que des optimisations incorrectes.

Les fonctions CTYPE.H Autoriser EOF comme paramètre, mais autrement se comporter comme si vous travaillez avec des types de caractères, même si le paramètre est int pour autoriser eof . Le texte du 7.4 §1 dit principalement que "si vous passez du hasard int à cette fonction, qui n'est ni de la même représentation qu'un caractère, ni EOF, le comportement n'est pas défini" .

Mais si vous passez un char où vous avez déjà invoqué SIGNÉ ENTREGER Overflow / Integer, vous avez déjà un comportement non défini avant d'appeler la fonction - cela n'a rien à voir avec les fonctions CTYPE.H ou toute autre fonction. Ainsi, votre hypothèse que la fonction postée "supérieure" est dangereuse est incorrecte - ce code n'est pas différent de tout autre code à l'aide du type char .

Un exemple de comportement non défini causé par les restrictions CITE CITE.H dans 7.4 serait plutôt quelque chose comme Toupper (666) . .