Est-ce que le "ignoring case" correspond à la locale C (i.e. par
rapport au jeu de caractères de base) ou à la locale courante
(i.e. par rapport à islower/isupper)?
J'ai voulu tester avec la glibc en "tr_TR.iso88599", mais les
développeurs n'ont pas dû réfléchir au problème, car ça bugge
(le "INF" n'est même pas accepté). J'ai fait un rapport de bug
ici:
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
Antoine Leca
En <news:20050823000746$, Vincent Lefevre va escriure:
Dans la norme, il est dit pour strtod: -- one of INF or INFINITY, ignoring case
Est-ce que le "ignoring case" correspond à la locale C (i.e. par rapport au jeu de caractères de base) ou à la locale courante (i.e. par rapport à islower/isupper)?
Logiquement, "C". La locale courante peut permettre d'autres séquences (et dans le cas de ta locale turque, les séquences "inf" et "infinity", ignorant la casse, devraient absolument être permises).
Le cas du séparateur décimal (qui varie suivant la locale) est un cas particulier, avec un alinéa à part en 7.1.1.
J'ai voulu tester avec la glibc en "tr_TR.iso88599",
Taquin.
mais les développeurs n'ont pas dû réfléchir au problème,
:-)
car ça bugge (le "INF" n'est même pas accepté).
Ce qui est clairement inadmissible, c'est écrit en toutes lettres (je suppose que "inf", lui, fonctionne).
Enfin tout cela, c'est mon avis.
Antoine
En <news:20050823000746$1d0e@prunille.vinc17.org>,
Vincent Lefevre va escriure:
Dans la norme, il est dit pour strtod:
-- one of INF or INFINITY, ignoring case
Est-ce que le "ignoring case" correspond à la locale C (i.e. par
rapport au jeu de caractères de base) ou à la locale courante
(i.e. par rapport à islower/isupper)?
Logiquement, "C". La locale courante peut permettre d'autres séquences (et
dans le cas de ta locale turque, les séquences "inf" et "infinity", ignorant
la casse, devraient absolument être permises).
Le cas du séparateur décimal (qui varie suivant la locale) est un cas
particulier, avec un alinéa à part en 7.1.1.
J'ai voulu tester avec la glibc en "tr_TR.iso88599",
Taquin.
mais les développeurs n'ont pas dû réfléchir au problème,
:-)
car ça bugge (le "INF" n'est même pas accepté).
Ce qui est clairement inadmissible, c'est écrit en toutes lettres (je
suppose que "inf", lui, fonctionne).
En <news:20050823000746$, Vincent Lefevre va escriure:
Dans la norme, il est dit pour strtod: -- one of INF or INFINITY, ignoring case
Est-ce que le "ignoring case" correspond à la locale C (i.e. par rapport au jeu de caractères de base) ou à la locale courante (i.e. par rapport à islower/isupper)?
Logiquement, "C". La locale courante peut permettre d'autres séquences (et dans le cas de ta locale turque, les séquences "inf" et "infinity", ignorant la casse, devraient absolument être permises).
Le cas du séparateur décimal (qui varie suivant la locale) est un cas particulier, avec un alinéa à part en 7.1.1.
J'ai voulu tester avec la glibc en "tr_TR.iso88599",
Taquin.
mais les développeurs n'ont pas dû réfléchir au problème,
:-)
car ça bugge (le "INF" n'est même pas accepté).
Ce qui est clairement inadmissible, c'est écrit en toutes lettres (je suppose que "inf", lui, fonctionne).
Enfin tout cela, c'est mon avis.
Antoine
Charlie Gordon
"Antoine Leca" wrote in message news:def4u6$fr9$
En <news:20050823000746$, Vincent Lefevre va escriure:
Dans la norme, il est dit pour strtod: -- one of INF or INFINITY, ignoring case
Est-ce que le "ignoring case" correspond à la locale C (i.e. par rapport au jeu de caractères de base) ou à la locale courante (i.e. par rapport à islower/isupper)?
Logiquement, "C". La locale courante peut permettre d'autres séquences (et dans le cas de ta locale turque, les séquences "inf" et "infinity", ignorant la casse, devraient absolument être permises).
Le cas du séparateur décimal (qui varie suivant la locale) est un cas particulier, avec un alinéa à part en 7.1.1.
J'ai voulu tester avec la glibc en "tr_TR.iso88599",
Taquin.
mais les développeurs n'ont pas dû réfléchir au problème,
:-)
car ça bugge (le "INF" n'est même pas accepté).
Ce qui est clairement inadmissible, c'est écrit en toutes lettres (je suppose que "inf", lui, fonctionne).
Enfin tout cela, c'est mon avis.
C'est ce qui s'appelle mettre les points sur les i ;-)
Chqrlie.
"Antoine Leca" <root@localhost.invalid> wrote in message
news:def4u6$fr9$1@shakotay.alphanet.ch...
En <news:20050823000746$1d0e@prunille.vinc17.org>,
Vincent Lefevre va escriure:
Dans la norme, il est dit pour strtod:
-- one of INF or INFINITY, ignoring case
Est-ce que le "ignoring case" correspond à la locale C (i.e. par
rapport au jeu de caractères de base) ou à la locale courante
(i.e. par rapport à islower/isupper)?
Logiquement, "C". La locale courante peut permettre d'autres séquences (et
dans le cas de ta locale turque, les séquences "inf" et "infinity", ignorant
la casse, devraient absolument être permises).
Le cas du séparateur décimal (qui varie suivant la locale) est un cas
particulier, avec un alinéa à part en 7.1.1.
J'ai voulu tester avec la glibc en "tr_TR.iso88599",
Taquin.
mais les développeurs n'ont pas dû réfléchir au problème,
:-)
car ça bugge (le "INF" n'est même pas accepté).
Ce qui est clairement inadmissible, c'est écrit en toutes lettres (je
suppose que "inf", lui, fonctionne).
Enfin tout cela, c'est mon avis.
C'est ce qui s'appelle mettre les points sur les i ;-)
En <news:20050823000746$, Vincent Lefevre va escriure:
Dans la norme, il est dit pour strtod: -- one of INF or INFINITY, ignoring case
Est-ce que le "ignoring case" correspond à la locale C (i.e. par rapport au jeu de caractères de base) ou à la locale courante (i.e. par rapport à islower/isupper)?
Logiquement, "C". La locale courante peut permettre d'autres séquences (et dans le cas de ta locale turque, les séquences "inf" et "infinity", ignorant la casse, devraient absolument être permises).
Le cas du séparateur décimal (qui varie suivant la locale) est un cas particulier, avec un alinéa à part en 7.1.1.
J'ai voulu tester avec la glibc en "tr_TR.iso88599",
Taquin.
mais les développeurs n'ont pas dû réfléchir au problème,
:-)
car ça bugge (le "INF" n'est même pas accepté).
Ce qui est clairement inadmissible, c'est écrit en toutes lettres (je suppose que "inf", lui, fonctionne).
Enfin tout cela, c'est mon avis.
C'est ce qui s'appelle mettre les points sur les i ;-)
Chqrlie.
Vincent Lefevre
Dans l'article <def4u6$fr9$, Antoine Leca écrit:
Ce qui est clairement inadmissible, c'est écrit en toutes lettres (je suppose que "inf", lui, fonctionne).
Oui, le "inf" fonctionne, idem avec le "i" majuscule avec un point. Ce sont les versions avec le "i" sans point (majuscule ou minuscule) qui ne marchent pas.
En gros, la glibc convertit en minuscule et compare avec "inf". Comme la conversion en minuscule dépend de la locale courante, ça bugge pour "INF".
Dans l'article <def4u6$fr9$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> écrit:
Ce qui est clairement inadmissible, c'est écrit en toutes lettres (je
suppose que "inf", lui, fonctionne).
Oui, le "inf" fonctionne, idem avec le "i" majuscule avec un point.
Ce sont les versions avec le "i" sans point (majuscule ou minuscule)
qui ne marchent pas.
En gros, la glibc convertit en minuscule et compare avec "inf".
Comme la conversion en minuscule dépend de la locale courante,
ça bugge pour "INF".
Ce qui est clairement inadmissible, c'est écrit en toutes lettres (je suppose que "inf", lui, fonctionne).
Oui, le "inf" fonctionne, idem avec le "i" majuscule avec un point. Ce sont les versions avec le "i" sans point (majuscule ou minuscule) qui ne marchent pas.
En gros, la glibc convertit en minuscule et compare avec "inf". Comme la conversion en minuscule dépend de la locale courante, ça bugge pour "INF".
