Je viens de bloquer sur un problème assez étrange. Prenons une machine
Sun Sparc sous solaris 8 et un jdk1.4.2
Imaginons une fonction C qui affiche sur un terminal un chiffre décimal
(1.123 par exemple). Suivant la variable LANG (et consoeurs), le système
affiche soit 1.123 soit 1,123 (Et encore ce n'est pas sûr).
Position les variables pour un environnement français. Et bien si cette
fonction est appelée par un main C, le programme affiche "1.123" et si
cette fonction est wrapper avec JNI le programme affiche "1,123". Ce qui
m'embête beaucoup car je parse le fichier généré par la suite. Mon
programme doit être multi plate-forme (à la compilation près) et je
rencontre ce comportement qu'avec cette configuration (solaris) et pas
avec linux ni windows.
Je suis intéressé par toute observation.
Je peux poster des exemples peut-être clairs si la description de mon
problème ne l'est pas suffisamment...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
John Gallet
Bonjour,
Je viens de bloquer sur un problème assez étrange. Meuhnon ! C'est du C. Avec un super touillage de cette @#! de JVM qui
n'a pas un comportement intuitif par dessus.
Imaginons une fonction C qui affiche sur un terminal un chiffre décimal (1.123 par exemple). Suivant la variable LANG (et consoeurs), le système affiche soit 1.123 soit 1,123 (Et encore ce n'est pas sûr).
En effet. C'est son comportement normal que d'être sensible au "locale".
Position les variables pour un environnement français. Et bien si cette fonction est appelée par un main C, le programme affiche "1.123" et si cette fonction est wrapper avec JNI le programme affiche "1,123".
Oui. Car la jvm semble bien triturer les variables d'environnement de manière "sympa".
Je suis intéressé par toute observation.
J'ai eu à régler un problème similaire (pour moi, on aurait obtenu dans ton exemple 1,0000000 dans le cas que j'ai eu à régler), voici ce que j'ai fait.
Tu as deux solutions : externe (environnement) ou interne (en C).
Le coupable est la variable LANG en conjonction avec la variable LC_CTYPE.
Si LANG n'est pas settée ou settée à 'en', pas de problèmes. Si LANG est settée à 'fr' mais que LC_CTYPE n'est pas settée correctement, problèmes.
Pour que LANG puisse être settée à 'fr', il faut que LC_CTYPE soit settée à la valeur 'C' ou à la valeur 'en_US.ISO8859-15' par exemple, bref, à une valeur qui admet le '.' comme séparateur de décimales. Ceci est un comportement normal et standard d'un programme C faisant appel aux fonctions C *printf*().
Donc ne pas setter la variable LANG ou de setter LC_CTYPE = C si tu résoud par variables d'environnement.
Sinon tu peux aussi dans ton programme JNI setter ces variables pour le temps de l'exécution en appelant tout simplement char *setlocale(int category, const char *locale); en forçcant le LC_TYPE ou carrément le LC_ALL à "C".
HTH JG
Bonjour,
Je viens de bloquer sur un problème assez étrange.
Meuhnon ! C'est du C. Avec un super touillage de cette @#! de JVM qui
n'a pas un comportement intuitif par dessus.
Imaginons une fonction C qui affiche sur un terminal un chiffre décimal
(1.123 par exemple). Suivant la variable LANG (et consoeurs), le système
affiche soit 1.123 soit 1,123 (Et encore ce n'est pas sûr).
En effet. C'est son comportement normal que d'être sensible au "locale".
Position les variables pour un environnement français. Et bien si cette
fonction est appelée par un main C, le programme affiche "1.123" et si
cette fonction est wrapper avec JNI le programme affiche "1,123".
Oui. Car la jvm semble bien triturer les variables d'environnement de
manière "sympa".
Je suis intéressé par toute observation.
J'ai eu à régler un problème similaire (pour moi, on aurait obtenu dans
ton exemple 1,0000000 dans le cas que j'ai eu à régler), voici ce que
j'ai fait.
Tu as deux solutions : externe (environnement) ou interne (en C).
Le coupable est la variable LANG en conjonction avec la variable
LC_CTYPE.
Si LANG n'est pas settée ou settée à 'en', pas de problèmes. Si LANG est
settée à 'fr' mais que LC_CTYPE n'est pas settée correctement,
problèmes.
Pour que LANG puisse être settée à 'fr', il faut que LC_CTYPE soit
settée à la valeur 'C' ou à la valeur 'en_US.ISO8859-15' par exemple,
bref, à une valeur qui admet le '.' comme séparateur de décimales. Ceci
est un comportement normal et standard d'un programme C faisant appel
aux fonctions C *printf*().
Donc ne pas setter la variable LANG ou de setter LC_CTYPE = C si tu
résoud par variables d'environnement.
Sinon tu peux aussi dans ton programme JNI setter ces variables pour le
temps de l'exécution en appelant tout simplement char *setlocale(int
category, const char *locale); en forçcant le LC_TYPE ou carrément le
LC_ALL à "C".
Je viens de bloquer sur un problème assez étrange. Meuhnon ! C'est du C. Avec un super touillage de cette @#! de JVM qui
n'a pas un comportement intuitif par dessus.
Imaginons une fonction C qui affiche sur un terminal un chiffre décimal (1.123 par exemple). Suivant la variable LANG (et consoeurs), le système affiche soit 1.123 soit 1,123 (Et encore ce n'est pas sûr).
En effet. C'est son comportement normal que d'être sensible au "locale".
Position les variables pour un environnement français. Et bien si cette fonction est appelée par un main C, le programme affiche "1.123" et si cette fonction est wrapper avec JNI le programme affiche "1,123".
Oui. Car la jvm semble bien triturer les variables d'environnement de manière "sympa".
Je suis intéressé par toute observation.
J'ai eu à régler un problème similaire (pour moi, on aurait obtenu dans ton exemple 1,0000000 dans le cas que j'ai eu à régler), voici ce que j'ai fait.
Tu as deux solutions : externe (environnement) ou interne (en C).
Le coupable est la variable LANG en conjonction avec la variable LC_CTYPE.
Si LANG n'est pas settée ou settée à 'en', pas de problèmes. Si LANG est settée à 'fr' mais que LC_CTYPE n'est pas settée correctement, problèmes.
Pour que LANG puisse être settée à 'fr', il faut que LC_CTYPE soit settée à la valeur 'C' ou à la valeur 'en_US.ISO8859-15' par exemple, bref, à une valeur qui admet le '.' comme séparateur de décimales. Ceci est un comportement normal et standard d'un programme C faisant appel aux fonctions C *printf*().
Donc ne pas setter la variable LANG ou de setter LC_CTYPE = C si tu résoud par variables d'environnement.
Sinon tu peux aussi dans ton programme JNI setter ces variables pour le temps de l'exécution en appelant tout simplement char *setlocale(int category, const char *locale); en forçcant le LC_TYPE ou carrément le LC_ALL à "C".
