Peut-on légitimement être dépendant des parameters régionaux en C

Dans la section relative à setlocale, la norme ANSI C indique dans une note de bas de page que les seules fonctions ctype.h dont le comportement n’est pas affecté par les parameters régionaux actuels sont isdigit et isxdigit.

L’implémentation Microsoft d’isdigit dépend des parameters régionaux, par exemple, dans les parameters régionaux utilisant la page de codes 1250. Isdigit renvoie uniquement des valeurs non nulles pour les caractères compris entre 0x30 (‘0’) et 0x39 (‘9’), tandis que les parameters régionaux utilisant une page de codes 1252 isdigit renvoie également une valeur autre que zéro pour les chiffres en exposant 0xB2 (‘²’), 0xB3 (‘³’) et 0xB9 (‘¹’).

Microsoft enfreint-il la norme C en faisant dépendre l’environnement local isdigit?

Dans cette question, je m’intéresse principalement à C90, à laquelle Microsoft prétend se conformer, plutôt qu’à C99.

Contexte supplémentaire:

La propre documentation de Microsoft sur setlocale indique à tort que isdigit n’est pas affecté par la partie LC_CTYPE des parameters régionaux.

La section de la norme C qui couvre les fonctions ctype.h contient des termes que je considère ambigus:

Le comportement de ces fonctions est affecté par les parameters régionaux en cours. Les fonctions qui ont des aspects spécifiques aux parameters régionaux uniquement lorsqu’elles ne sont pas dans les parameters régionaux “C” sont indiquées ci-dessous.

Je considère cela comme ambigu, car on ne sait pas très bien ce qu’il essaie de dire à propos de fonctions telles que isdigit pour lesquelles il n’ya pas de notes sur les aspects spécifiques aux parameters régionaux. On pourrait peut-être essayer de dire que de telles fonctions doivent être supposées dépendre de la localisation, auquel cas l’implémentation de isdigit par Microsoft serait OK. (Sauf que la note de bas de page que j’ai mentionnée plus haut semble contredire cette interprétation.)

  1. Microsoft a toujours raison.
  2. Si Microsoft n’a pas raison, voir le point 1.

Microsoft a toujours sa propre interprétation de la spécification. Et généralement, la phrase «mais Microsoft a tort» n’a pas de poids pour votre PDG, vous devez donc coder autour de bogues / interprétations liés à la SP.

La quantité de code permettant de prendre en charge le comportement incorrect d’IE et d’Outlook est stupéfiante.

Dans de nombreux cas, la seule solution consiste à lancer votre propre version de la fonction qui fait la bonne chose et à faire quelque chose comme ceci:

int my_isdigit( int c ) { #ifdef WIN32 your implementation goes here #else return isdigit( c ); #endif } 

Le jeu de caractères requirejs est défini à la section 2.2.1. La section 2.2.1.2 décrit ensuite le comportement des caractères d’extension:

  • Les caractères à un octet définis dans $ 2.2.1 doivent être présents.
  • La présence, la signification et la représentation de tout membre supplémentaire est spécifique à l’environnement local.