Description de strcmp dans la norme

Wykaaa

03/08/2008 à 10:38

candide a écrit :

Bonjour,

Deux choses me gênent dans la description de la fonction strcmp dans la
norme (C90 tout comme C99) :

1er point :

--------------------------------8<-----------------------------------
7.21.4 Comparison functions
1 The sign of a nonzero value returned by the comparison functions
memcmp, strcmp, and strncmp is determined by the sign of the difference
between the values of the first pair of characters (both interpreted as
unsigned char) that differ in the objects being compared.
-------------------------------->8-----------------------------------

Pourquoi employer l'expression "is determined" qui est assez vague
(pour moi, ici ça veut dire "est déterminé") ? Pourquoi ne pas dire
que les signes sont identiques (donc "coincides with" ou "matches" ou
"is identical to", etc) ?

2ème point :

--------------------------------8<-----------------------------------
7.21.4.2 p3 The strcmp function returns an integer greater than, equal
to, or less than zero, accordingly as the string pointed to by s1 is
greater than, equal to, or less than the string pointed to by s2.
-------------------------------->8-----------------------------------

Où dans la norme la notion de "chaîne plus grande qu'une autre" est-elle
définie ?

Merci

Par rapport à l'ordre lexicographique (codage des caractères).

Richard Delorme

03/08/2008 à 20:00

candide a écrit :

Bonjour,

Deux choses me gênent dans la description de la fonction strcmp dans la
norme (C90 tout comme C99) :

1er point :

--------------------------------8<-----------------------------------
7.21.4 Comparison functions
1 The sign of a nonzero value returned by the comparison functions
memcmp, strcmp, and strncmp is determined by the sign of the difference
between the values of the first pair of characters (both interpreted as
unsigned char) that differ in the objects being compared.
-------------------------------->8-----------------------------------

Pourquoi employer l'expression "is determined" qui est assez vague
(pour moi, ici ça veut dire "est déterminé") ? Pourquoi ne pas dire
que les signes sont identiques (donc "coincides with" ou "matches" ou
"is identical to", etc) ?

Personnellement, Je préfère la formulation du standard qui décrit une
action (calculer le signe d'une valeur) et non un état (identité des
deux signes).

2ème point :

--------------------------------8<-----------------------------------
7.21.4.2 p3 The strcmp function returns an integer greater than, equal
to, or less than zero, accordingly as the string pointed to by s1 is
greater than, equal to, or less than the string pointed to by s2.
-------------------------------->8-----------------------------------

Où dans la norme la notion de "chaîne plus grande qu'une autre" est-elle
définie ?

7.1.1.1

[...] the value of a string is the sequence of the values of the
contained characters, in order.

candide

03/08/2008 à 23:18

Richard Delorme a écrit :

--------------------------------8<-----------------------------------
7.21.4 Comparison functions
1 The sign of a nonzero value returned by the comparison functions
memcmp, strcmp, and strncmp is determined by the sign of the
difference between the values of the first pair of characters (both
interpreted as unsigned char) that differ in the objects being compared.
-------------------------------->8-----------------------------------

Personnellement, Je préfère la formulation du standard qui décrit une
action (calculer le signe d'une valeur) et non un état (identité des
deux signes).

Certes mais le problème est que si je suis à la lettre ce que dit
7.21.4p1, je NE sais PAS quel est le signe de la valeur retournée.

C'est comme si je disais : le signe du trinôme du second degré réel
ax*x+b*x+c est déterminé par le signe de 4*a*c-b*b. C'est vrai mais
c'est incomplet car non exploitable tel quel.

Au passage, j'observe que la nature du contenu de ce sous paragraphe de
la Norme est assez floue :

1°) dans le paragraphe 7.21.4, chaque sous-paragraphe a son titre et sa
fonction : soit il introduit une fonction soit c'est "synopis", soit
c'est "description" ou soit c'est "returns". Le paragraphe cité
ci-dessus n'as pas de titre, c'est une sorte de préambule qu'on ne sait
pas à quoi rattacher ;
2°) dans le paragraphe 7.21 (<tring.h>), les fonctions sont regroupées
par type de fonctionnalité (fonctions de copie, de concaténation, etc).
Le seul paragraphe qui contienne un préambule est notre paragraphe 7.21.4.

7.1.1.1

[...] the value of a string is the sequence of the values of the
contained characters, in order.

Ce point m'avait échappé. Je note au passage que cette définition ne
figure pas dans C90 alors que la formulation de la spécification de
strcmp y est totalement identique ...

Mais de toute façon, cette précision indique ce qu'est la valeur d'une
chaîne mais ne définit pas la relation d'ordre entre les chaînes. Le
préambule laisse entendre qu'il s'agit de la relation d'ordre
lexicographique -- au demeurant, croissant ou décroissant, je ne vois
pas comment on pourrait le dire (à cause de l'expression vague "is
determined").

Bref, ce §7.21.4 me paraît extrêmement mal rédigé.

Au passage puisqu'il est question de "chaîne" et du § 7.1.1 (partie
/Library/ de la Norme), il est quand même surprenant que ce soit là
qu'on y trouve la définition de "string" alors que ce terme est employé
dans la partie /Language/ à de très nombreuses occasions, au point que
je me pose parfois la question : parle-t-on des même "string" dans ces
deux parties ?

Richard Delorme a écrit :

--------------------------------8<-----------------------------------
7.21.4 Comparison functions
1 The sign of a nonzero value returned by the comparison functions
memcmp, strcmp, and strncmp is determined by the sign of the
difference between the values of the first pair of characters (both
interpreted as unsigned char) that differ in the objects being compared.
-------------------------------->8-----------------------------------

Personnellement, Je préfère la formulation du standard qui décrit une
action (calculer le signe d'une valeur) et non un état (identité des
deux signes).

Certes mais le problème est que si je suis à la lettre ce que dit
7.21.4p1, je NE sais PAS quel est le signe de la valeur retournée.

C'est comme si je disais : le signe du trinôme du second degré réel
ax*x+b*x+c est déterminé par le signe de 4*a*c-b*b. C'est vrai mais
c'est incomplet car non exploitable tel quel.

Au passage, j'observe que la nature du contenu de ce sous paragraphe de
la Norme est assez floue :

1°) dans le paragraphe 7.21.4, chaque sous-paragraphe a son titre et sa
fonction : soit il introduit une fonction soit c'est "synopis", soit
c'est "description" ou soit c'est "returns". Le paragraphe cité
ci-dessus n'as pas de titre, c'est une sorte de préambule qu'on ne sait
pas à quoi rattacher ;
2°) dans le paragraphe 7.21 (<tring.h>), les fonctions sont regroupées
par type de fonctionnalité (fonctions de copie, de concaténation, etc).
Le seul paragraphe qui contienne un préambule est notre paragraphe 7.21.4.

7.1.1.1

[...] the value of a string is the sequence of the values of the
contained characters, in order.

Ce point m'avait échappé. Je note au passage que cette définition ne
figure pas dans C90 alors que la formulation de la spécification de
strcmp y est totalement identique ...

Mais de toute façon, cette précision indique ce qu'est la valeur d'une
chaîne mais ne définit pas la relation d'ordre entre les chaînes. Le
préambule laisse entendre qu'il s'agit de la relation d'ordre
lexicographique -- au demeurant, croissant ou décroissant, je ne vois
pas comment on pourrait le dire (à cause de l'expression vague "is
determined").

Bref, ce §7.21.4 me paraît extrêmement mal rédigé.

Au passage puisqu'il est question de "chaîne" et du § 7.1.1 (partie
/Library/ de la Norme), il est quand même surprenant que ce soit là
qu'on y trouve la définition de "string" alors que ce terme est employé
dans la partie /Language/ à de très nombreuses occasions, au point que
je me pose parfois la question : parle-t-on des même "string" dans ces
deux parties ?

Vous avez filtré cet utilisateur ! Consultez son message

Richard Delorme a écrit :

--------------------------------8<-----------------------------------
7.21.4 Comparison functions
1 The sign of a nonzero value returned by the comparison functions
memcmp, strcmp, and strncmp is determined by the sign of the
difference between the values of the first pair of characters (both
interpreted as unsigned char) that differ in the objects being compared.
-------------------------------->8-----------------------------------

Personnellement, Je préfère la formulation du standard qui décrit une
action (calculer le signe d'une valeur) et non un état (identité des
deux signes).

Certes mais le problème est que si je suis à la lettre ce que dit
7.21.4p1, je NE sais PAS quel est le signe de la valeur retournée.

C'est comme si je disais : le signe du trinôme du second degré réel
ax*x+b*x+c est déterminé par le signe de 4*a*c-b*b. C'est vrai mais
c'est incomplet car non exploitable tel quel.

Au passage, j'observe que la nature du contenu de ce sous paragraphe de
la Norme est assez floue :

1°) dans le paragraphe 7.21.4, chaque sous-paragraphe a son titre et sa
fonction : soit il introduit une fonction soit c'est "synopis", soit
c'est "description" ou soit c'est "returns". Le paragraphe cité
ci-dessus n'as pas de titre, c'est une sorte de préambule qu'on ne sait
pas à quoi rattacher ;
2°) dans le paragraphe 7.21 (<tring.h>), les fonctions sont regroupées
par type de fonctionnalité (fonctions de copie, de concaténation, etc).
Le seul paragraphe qui contienne un préambule est notre paragraphe 7.21.4.

7.1.1.1

[...] the value of a string is the sequence of the values of the
contained characters, in order.

Ce point m'avait échappé. Je note au passage que cette définition ne
figure pas dans C90 alors que la formulation de la spécification de
strcmp y est totalement identique ...

Mais de toute façon, cette précision indique ce qu'est la valeur d'une
chaîne mais ne définit pas la relation d'ordre entre les chaînes. Le
préambule laisse entendre qu'il s'agit de la relation d'ordre
lexicographique -- au demeurant, croissant ou décroissant, je ne vois
pas comment on pourrait le dire (à cause de l'expression vague "is
determined").

Bref, ce §7.21.4 me paraît extrêmement mal rédigé.

Au passage puisqu'il est question de "chaîne" et du § 7.1.1 (partie
/Library/ de la Norme), il est quand même surprenant que ce soit là
qu'on y trouve la définition de "string" alors que ce terme est employé
dans la partie /Language/ à de très nombreuses occasions, au point que
je me pose parfois la question : parle-t-on des même "string" dans ces
deux parties ?

Richard Delorme

04/08/2008 à 02:39

candide a écrit :

Richard Delorme a écrit :

--------------------------------8<-----------------------------------
7.21.4 Comparison functions
1 The sign of a nonzero value returned by the comparison functions
memcmp, strcmp, and strncmp is determined by the sign of the
difference between the values of the first pair of characters (both
interpreted as unsigned char) that differ in the objects being compared.
-------------------------------->8-----------------------------------

Personnellement, Je préfère la formulation du standard qui décrit une
action (calculer le signe d'une valeur) et non un état (identité des
deux signes).

Certes mais le problème est que si je suis à la lettre ce que dit
7.21.4p1, je NE sais PAS quel est le signe de la valeur retournée.

C'est comme si je disais : le signe du trinôme du second degré réel
ax*x+b*x+c est déterminé par le signe de 4*a*c-b*b. C'est vrai mais
c'est incomplet car non exploitable tel quel.

Je ne crois pas que "déterminer" à un sens aussi flou. A te lire, on
devrait comprendre qu'une chose déterminée reste indéterminée, ce qui me
semble quelque part absurde.

Au passage, j'observe que la nature du contenu de ce sous paragraphe de
la Norme est assez floue :

1°) dans le paragraphe 7.21.4, chaque sous-paragraphe a son titre et sa
fonction : soit il introduit une fonction soit c'est "synopis", soit
c'est "description" ou soit c'est "returns". Le paragraphe cité
ci-dessus n'as pas de titre, c'est une sorte de préambule qu'on ne sait
pas à quoi rattacher ;
2°) dans le paragraphe 7.21 (<tring.h>), les fonctions sont regroupées
par type de fonctionnalité (fonctions de copie, de concaténation, etc).
Le seul paragraphe qui contienne un préambule est notre paragraphe 7.21.4.

Bof, il y a plein de préambule semblable dans le chapitre 7 de la norme.

Au passage puisqu'il est question de "chaîne" et du § 7.1.1 (partie
/Library/ de la Norme), il est quand même surprenant que ce soit là
qu'on y trouve la définition de "string" alors que ce terme est employé
dans la partie /Language/ à de très nombreuses occasions, au point que
je me pose parfois la question : parle-t-on des même "string" dans ces
deux parties ?

Dans la partie /language/, on parle surtout de "string literal", qui est
en effet quelque chose de différent. Sinon, cette partie contient aussi
des "forward references" vers le § 7.1.1. (p.ex. au § 5.2.1). De plus,
la norme s'appuie sur d'autres glossaires normalisés (IOS/IEC 2382) où
la notion de /character string/ est définie.

--
Richard

candide a écrit :

Richard Delorme a écrit :

--------------------------------8<-----------------------------------
7.21.4 Comparison functions
1 The sign of a nonzero value returned by the comparison functions
memcmp, strcmp, and strncmp is determined by the sign of the
difference between the values of the first pair of characters (both
interpreted as unsigned char) that differ in the objects being compared.
-------------------------------->8-----------------------------------

Personnellement, Je préfère la formulation du standard qui décrit une
action (calculer le signe d'une valeur) et non un état (identité des
deux signes).

Certes mais le problème est que si je suis à la lettre ce que dit
7.21.4p1, je NE sais PAS quel est le signe de la valeur retournée.

C'est comme si je disais : le signe du trinôme du second degré réel
ax*x+b*x+c est déterminé par le signe de 4*a*c-b*b. C'est vrai mais
c'est incomplet car non exploitable tel quel.

Je ne crois pas que "déterminer" à un sens aussi flou. A te lire, on
devrait comprendre qu'une chose déterminée reste indéterminée, ce qui me
semble quelque part absurde.

Au passage, j'observe que la nature du contenu de ce sous paragraphe de
la Norme est assez floue :

1°) dans le paragraphe 7.21.4, chaque sous-paragraphe a son titre et sa
fonction : soit il introduit une fonction soit c'est "synopis", soit
c'est "description" ou soit c'est "returns". Le paragraphe cité
ci-dessus n'as pas de titre, c'est une sorte de préambule qu'on ne sait
pas à quoi rattacher ;
2°) dans le paragraphe 7.21 (<tring.h>), les fonctions sont regroupées
par type de fonctionnalité (fonctions de copie, de concaténation, etc).
Le seul paragraphe qui contienne un préambule est notre paragraphe 7.21.4.

Bof, il y a plein de préambule semblable dans le chapitre 7 de la norme.

Au passage puisqu'il est question de "chaîne" et du § 7.1.1 (partie
/Library/ de la Norme), il est quand même surprenant que ce soit là
qu'on y trouve la définition de "string" alors que ce terme est employé
dans la partie /Language/ à de très nombreuses occasions, au point que
je me pose parfois la question : parle-t-on des même "string" dans ces
deux parties ?

Dans la partie /language/, on parle surtout de "string literal", qui est
en effet quelque chose de différent. Sinon, cette partie contient aussi
des "forward references" vers le § 7.1.1. (p.ex. au § 5.2.1). De plus,
la norme s'appuie sur d'autres glossaires normalisés (IOS/IEC 2382) où
la notion de /character string/ est définie.

--
Richard

Vous avez filtré cet utilisateur ! Consultez son message

candide a écrit :

Richard Delorme a écrit :

--------------------------------8<-----------------------------------
7.21.4 Comparison functions
1 The sign of a nonzero value returned by the comparison functions
memcmp, strcmp, and strncmp is determined by the sign of the
difference between the values of the first pair of characters (both
interpreted as unsigned char) that differ in the objects being compared.
-------------------------------->8-----------------------------------

Personnellement, Je préfère la formulation du standard qui décrit une
action (calculer le signe d'une valeur) et non un état (identité des
deux signes).

Certes mais le problème est que si je suis à la lettre ce que dit
7.21.4p1, je NE sais PAS quel est le signe de la valeur retournée.

C'est comme si je disais : le signe du trinôme du second degré réel
ax*x+b*x+c est déterminé par le signe de 4*a*c-b*b. C'est vrai mais
c'est incomplet car non exploitable tel quel.

Je ne crois pas que "déterminer" à un sens aussi flou. A te lire, on
devrait comprendre qu'une chose déterminée reste indéterminée, ce qui me
semble quelque part absurde.

Au passage, j'observe que la nature du contenu de ce sous paragraphe de
la Norme est assez floue :

1°) dans le paragraphe 7.21.4, chaque sous-paragraphe a son titre et sa
fonction : soit il introduit une fonction soit c'est "synopis", soit
c'est "description" ou soit c'est "returns". Le paragraphe cité
ci-dessus n'as pas de titre, c'est une sorte de préambule qu'on ne sait
pas à quoi rattacher ;
2°) dans le paragraphe 7.21 (<tring.h>), les fonctions sont regroupées
par type de fonctionnalité (fonctions de copie, de concaténation, etc).
Le seul paragraphe qui contienne un préambule est notre paragraphe 7.21.4.

Bof, il y a plein de préambule semblable dans le chapitre 7 de la norme.

Au passage puisqu'il est question de "chaîne" et du § 7.1.1 (partie
/Library/ de la Norme), il est quand même surprenant que ce soit là
qu'on y trouve la définition de "string" alors que ce terme est employé
dans la partie /Language/ à de très nombreuses occasions, au point que
je me pose parfois la question : parle-t-on des même "string" dans ces
deux parties ?

Dans la partie /language/, on parle surtout de "string literal", qui est
en effet quelque chose de différent. Sinon, cette partie contient aussi
des "forward references" vers le § 7.1.1. (p.ex. au § 5.2.1). De plus,
la norme s'appuie sur d'autres glossaires normalisés (IOS/IEC 2382) où
la notion de /character string/ est définie.

--
Richard

candide

04/08/2008 à 04:35

Richard Delorme a écrit :

A te lire, on
devrait comprendre qu'une chose déterminée reste indéterminée, ce qui me
semble quelque part absurde.

Le verbe "déterminer" exprime quelque chose de fort et d'important.
C'est une notion qualitative. Faut-il encore dire comment cette force ou
cette importance se traduisent (la traduction quantitative).
Si je dis z est déterminé par y et z, cela veut juste dire qu'il existe
une fonction f telle que z=f(x,y). Maintenant que f(x,y)=sqrt(x*x+y*y)
ou f(x,y)=|x|+|y| ou que sais-je encore, ce n'est pas pareil.

Ce que je dis c'est que la Norme n'exprime pas COMMENT le signe du
retour est lié au signe de la différence.

Il me semble quand même beaucoup plus précis de dire que le signe est
non seulement "déterminé" mais _identique_ au signe de la différence.
Dire cela évite en outre toutes les explications vaseuses et tout aussi
floues sur "la chaîne plus grande qu'une autre" dans un sens qui n'a
jamais été défini.

Bof, il y a plein de préambule semblable dans le chapitre 7 de la norme.

Pas tant que ça. Et dans <string.h>, c'est bien le seul.

Dans la partie /language/, on parle surtout de "string literal",

Effectivement mais pas seulement, cf. par exemple le passage où il est
question des arguments de la ligne de commande.

qui est
en effet quelque chose de différent.

C'est ce que la norme dit en effet, partie Langage mais en se référant à
la partie Library (bonjour la clarté !) La différence ? c'est vraiment
discuter du sexe des strings.

Voici les définitions :

A string is a contiguous sequence of characters terminated by and
including the first null character.

De l'autre côté :

A character string literal is a sequence of zero or more multibyte
characters enclosed in double-quotes, as in "xyz"

(au passage, quand même assez extraordinaire de définir un concept par
le recours à un exemple, visez le 'as in "xyz"' !!).

La différence ? Réponse :

A character string literal need not be a string (see 7.1.1), because a
null character may be embedded in it by a escape sequence.

Donc quoi ? "titi" serait une chaine littérale qui ne serait pas une
chaîne ? Alors, là je demande à comprendre la validité de ce
contre-exemple au vu des définitions données ci-dessus.

En plus, il faut noter la logique : une chaine littérale de caractères
n'est pas nécessairement une chaîne !

Sinon, cette partie contient aussi
des "forward references" vers le § 7.1.1. (p.ex. au § 5.2.1).

Oui mais dans la mesure où le terme est employé, je me demande s'il
n'aurait pas fallu le définir antérieurement.

De plus,
la norme s'appuie sur d'autres glossaires normalisés (IOS/IEC 2382) où

qui eux-même s'appuient sur d'autres standards ...

la notion de /character string/ est définie.

Pas besoin, la norme la définit, cf. citation ci-dessus.

Richard Delorme a écrit :

A te lire, on
devrait comprendre qu'une chose déterminée reste indéterminée, ce qui me
semble quelque part absurde.

Le verbe "déterminer" exprime quelque chose de fort et d'important.
C'est une notion qualitative. Faut-il encore dire comment cette force ou
cette importance se traduisent (la traduction quantitative).
Si je dis z est déterminé par y et z, cela veut juste dire qu'il existe
une fonction f telle que z=f(x,y). Maintenant que f(x,y)=sqrt(x*x+y*y)
ou f(x,y)=|x|+|y| ou que sais-je encore, ce n'est pas pareil.

Ce que je dis c'est que la Norme n'exprime pas COMMENT le signe du
retour est lié au signe de la différence.

Il me semble quand même beaucoup plus précis de dire que le signe est
non seulement "déterminé" mais _identique_ au signe de la différence.
Dire cela évite en outre toutes les explications vaseuses et tout aussi
floues sur "la chaîne plus grande qu'une autre" dans un sens qui n'a
jamais été défini.

Bof, il y a plein de préambule semblable dans le chapitre 7 de la norme.

Pas tant que ça. Et dans <string.h>, c'est bien le seul.

Dans la partie /language/, on parle surtout de "string literal",

Effectivement mais pas seulement, cf. par exemple le passage où il est
question des arguments de la ligne de commande.

qui est
en effet quelque chose de différent.

C'est ce que la norme dit en effet, partie Langage mais en se référant à
la partie Library (bonjour la clarté !) La différence ? c'est vraiment
discuter du sexe des strings.

Voici les définitions :

A string is a contiguous sequence of characters terminated by and
including the first null character.

De l'autre côté :

A character string literal is a sequence of zero or more multibyte
characters enclosed in double-quotes, as in "xyz"

(au passage, quand même assez extraordinaire de définir un concept par
le recours à un exemple, visez le 'as in "xyz"' !!).

La différence ? Réponse :

A character string literal need not be a string (see 7.1.1), because a
null character may be embedded in it by a escape sequence.

Donc quoi ? "titi" serait une chaine littérale qui ne serait pas une
chaîne ? Alors, là je demande à comprendre la validité de ce
contre-exemple au vu des définitions données ci-dessus.

En plus, il faut noter la logique : une chaine littérale de caractères
n'est pas nécessairement une chaîne !

Sinon, cette partie contient aussi
des "forward references" vers le § 7.1.1. (p.ex. au § 5.2.1).

Oui mais dans la mesure où le terme est employé, je me demande s'il
n'aurait pas fallu le définir antérieurement.

De plus,
la norme s'appuie sur d'autres glossaires normalisés (IOS/IEC 2382) où

qui eux-même s'appuient sur d'autres standards ...

la notion de /character string/ est définie.

Pas besoin, la norme la définit, cf. citation ci-dessus.

Vous avez filtré cet utilisateur ! Consultez son message

Richard Delorme a écrit :

A te lire, on
devrait comprendre qu'une chose déterminée reste indéterminée, ce qui me
semble quelque part absurde.

Le verbe "déterminer" exprime quelque chose de fort et d'important.
C'est une notion qualitative. Faut-il encore dire comment cette force ou
cette importance se traduisent (la traduction quantitative).
Si je dis z est déterminé par y et z, cela veut juste dire qu'il existe
une fonction f telle que z=f(x,y). Maintenant que f(x,y)=sqrt(x*x+y*y)
ou f(x,y)=|x|+|y| ou que sais-je encore, ce n'est pas pareil.

Ce que je dis c'est que la Norme n'exprime pas COMMENT le signe du
retour est lié au signe de la différence.

Il me semble quand même beaucoup plus précis de dire que le signe est
non seulement "déterminé" mais _identique_ au signe de la différence.
Dire cela évite en outre toutes les explications vaseuses et tout aussi
floues sur "la chaîne plus grande qu'une autre" dans un sens qui n'a
jamais été défini.

Bof, il y a plein de préambule semblable dans le chapitre 7 de la norme.

Pas tant que ça. Et dans <string.h>, c'est bien le seul.

Dans la partie /language/, on parle surtout de "string literal",

Effectivement mais pas seulement, cf. par exemple le passage où il est
question des arguments de la ligne de commande.

qui est
en effet quelque chose de différent.

C'est ce que la norme dit en effet, partie Langage mais en se référant à
la partie Library (bonjour la clarté !) La différence ? c'est vraiment
discuter du sexe des strings.

Voici les définitions :

A string is a contiguous sequence of characters terminated by and
including the first null character.

De l'autre côté :

A character string literal is a sequence of zero or more multibyte
characters enclosed in double-quotes, as in "xyz"

(au passage, quand même assez extraordinaire de définir un concept par
le recours à un exemple, visez le 'as in "xyz"' !!).

La différence ? Réponse :

A character string literal need not be a string (see 7.1.1), because a
null character may be embedded in it by a escape sequence.

Donc quoi ? "titi" serait une chaine littérale qui ne serait pas une
chaîne ? Alors, là je demande à comprendre la validité de ce
contre-exemple au vu des définitions données ci-dessus.

En plus, il faut noter la logique : une chaine littérale de caractères
n'est pas nécessairement une chaîne !

Sinon, cette partie contient aussi
des "forward references" vers le § 7.1.1. (p.ex. au § 5.2.1).

Oui mais dans la mesure où le terme est employé, je me demande s'il
n'aurait pas fallu le définir antérieurement.

De plus,
la norme s'appuie sur d'autres glossaires normalisés (IOS/IEC 2382) où

qui eux-même s'appuient sur d'autres standards ...

la notion de /character string/ est définie.

Pas besoin, la norme la définit, cf. citation ci-dessus.

Antoine Leca

05/08/2008 à 15:34

En news:48962096$0$3720$, candide va escriure:

--------------------------------8<-----------------------------------
7.21.4 Comparison functions
1 The sign of a nonzero value returned by the comparison functions
memcmp, strcmp, and strncmp is determined by the sign of the
difference between the values of the first pair of characters (both
interpreted as unsigned char) that differ in the objects being
compared.
-------------------------------->8-----------------------------------

Certes mais le problème est que si je suis à la lettre ce que dit
7.21.4p1, je NE sais PAS quel est le signe de la valeur retournée.

Et c'est pourquoi la description de chacune des fonctions en 7.21.4.* décrit
la relation univoque entre le signe retourné et le résultat de la
comparaison (résultat qui dépend de la comparaison utilisée, qui elle-même
dépend de la fonction).

7.1.1.1

[...] the value of a string is the sequence of the values of the
contained characters, in order.

[...] cette précision indique ce qu'est la valeur d'une
chaîne mais ne définit pas la relation d'ordre entre les chaînes.

Non seulement les petits bouts cités (en incluant 7.21.4.2p3) suffisent pour
définir deux relations d'ordre (> et >=), mais en plus >= est un ordre total
: qqs deux chaînes avec leurs représentations comme suites d'entiers de type
unsigned char, il n'y a qu'une seule possibilité dans le triplet
{strictement_positif, nul, strictement_négatif} ; et si on prend les deux
premiers (>=), c'est RAT.

Le préambule laisse entendre qu'il s'agit de la relation d'ordre
lexicographique

D'où tires-tu cette interprétation (nouvelle pour moi, je ne savais pas que
z<ñ, ou encore que z<A, dans l'ordre lexicographique) ?

-- au demeurant, croissant ou décroissant, je ne vois
pas comment on pourrait le dire (à cause de l'expression vague "is
determined").

L'ordre est toujours croissant, du fait du texte qui associe les valeurs
positives à l'ordre de >.

Bref, ce §7.21.4 me paraît extrêmement mal rédigé.

Tes propositions d'améliorations doivent être envoyées (en anglais) au
comité WG14.

Au passage puisqu'il est question de "chaîne" et du § 7.1.1 (partie
/Library/ de la Norme), il est quand même surprenant que ce soit là
qu'on y trouve la définition de "string" alors que ce terme est
employé dans la partie /Language/ à de très nombreuses occasions,

La /chaîne/ de la partie 7 possède la propriété complémentaire d'avoir un
zéro final, propriété qui est essentielle dans la partie 7 et qui n'est que
très accessoire dans les occurences des /littéraux chaîne/ de la partie 6.

Antoine

En news:48962096$0$3720$426a74cc@news.free.fr, candide va escriure:

--------------------------------8<-----------------------------------
7.21.4 Comparison functions
1 The sign of a nonzero value returned by the comparison functions
memcmp, strcmp, and strncmp is determined by the sign of the
difference between the values of the first pair of characters (both
interpreted as unsigned char) that differ in the objects being
compared.
-------------------------------->8-----------------------------------

Certes mais le problème est que si je suis à la lettre ce que dit
7.21.4p1, je NE sais PAS quel est le signe de la valeur retournée.

Et c'est pourquoi la description de chacune des fonctions en 7.21.4.* décrit
la relation univoque entre le signe retourné et le résultat de la
comparaison (résultat qui dépend de la comparaison utilisée, qui elle-même
dépend de la fonction).

7.1.1.1

[...] the value of a string is the sequence of the values of the
contained characters, in order.

[...] cette précision indique ce qu'est la valeur d'une
chaîne mais ne définit pas la relation d'ordre entre les chaînes.

Non seulement les petits bouts cités (en incluant 7.21.4.2p3) suffisent pour
définir deux relations d'ordre (> et >=), mais en plus >= est un ordre total
: qqs deux chaînes avec leurs représentations comme suites d'entiers de type
unsigned char, il n'y a qu'une seule possibilité dans le triplet
{strictement_positif, nul, strictement_négatif} ; et si on prend les deux
premiers (>=), c'est RAT.

Le préambule laisse entendre qu'il s'agit de la relation d'ordre
lexicographique

D'où tires-tu cette interprétation (nouvelle pour moi, je ne savais pas que
z<ñ, ou encore que z<A, dans l'ordre lexicographique) ?

-- au demeurant, croissant ou décroissant, je ne vois
pas comment on pourrait le dire (à cause de l'expression vague "is
determined").

L'ordre est toujours croissant, du fait du texte qui associe les valeurs
positives à l'ordre de >.

Bref, ce §7.21.4 me paraît extrêmement mal rédigé.

Tes propositions d'améliorations doivent être envoyées (en anglais) au
comité WG14.

Au passage puisqu'il est question de "chaîne" et du § 7.1.1 (partie
/Library/ de la Norme), il est quand même surprenant que ce soit là
qu'on y trouve la définition de "string" alors que ce terme est
employé dans la partie /Language/ à de très nombreuses occasions,

La /chaîne/ de la partie 7 possède la propriété complémentaire d'avoir un
zéro final, propriété qui est essentielle dans la partie 7 et qui n'est que
très accessoire dans les occurences des /littéraux chaîne/ de la partie 6.

Antoine

Vous avez filtré cet utilisateur ! Consultez son message

En news:48962096$0$3720$, candide va escriure:

--------------------------------8<-----------------------------------
7.21.4 Comparison functions
1 The sign of a nonzero value returned by the comparison functions
memcmp, strcmp, and strncmp is determined by the sign of the
difference between the values of the first pair of characters (both
interpreted as unsigned char) that differ in the objects being
compared.
-------------------------------->8-----------------------------------

Certes mais le problème est que si je suis à la lettre ce que dit
7.21.4p1, je NE sais PAS quel est le signe de la valeur retournée.

Et c'est pourquoi la description de chacune des fonctions en 7.21.4.* décrit
la relation univoque entre le signe retourné et le résultat de la
comparaison (résultat qui dépend de la comparaison utilisée, qui elle-même
dépend de la fonction).

7.1.1.1

[...] the value of a string is the sequence of the values of the
contained characters, in order.

[...] cette précision indique ce qu'est la valeur d'une
chaîne mais ne définit pas la relation d'ordre entre les chaînes.

Non seulement les petits bouts cités (en incluant 7.21.4.2p3) suffisent pour
définir deux relations d'ordre (> et >=), mais en plus >= est un ordre total
: qqs deux chaînes avec leurs représentations comme suites d'entiers de type
unsigned char, il n'y a qu'une seule possibilité dans le triplet
{strictement_positif, nul, strictement_négatif} ; et si on prend les deux
premiers (>=), c'est RAT.

Le préambule laisse entendre qu'il s'agit de la relation d'ordre
lexicographique

D'où tires-tu cette interprétation (nouvelle pour moi, je ne savais pas que
z<ñ, ou encore que z<A, dans l'ordre lexicographique) ?

-- au demeurant, croissant ou décroissant, je ne vois
pas comment on pourrait le dire (à cause de l'expression vague "is
determined").

L'ordre est toujours croissant, du fait du texte qui associe les valeurs
positives à l'ordre de >.

Bref, ce §7.21.4 me paraît extrêmement mal rédigé.

Tes propositions d'améliorations doivent être envoyées (en anglais) au
comité WG14.

Au passage puisqu'il est question de "chaîne" et du § 7.1.1 (partie
/Library/ de la Norme), il est quand même surprenant que ce soit là
qu'on y trouve la définition de "string" alors que ce terme est
employé dans la partie /Language/ à de très nombreuses occasions,

La /chaîne/ de la partie 7 possède la propriété complémentaire d'avoir un
zéro final, propriété qui est essentielle dans la partie 7 et qui n'est que
très accessoire dans les occurences des /littéraux chaîne/ de la partie 6.

Antoine

Antoine Leca

05/08/2008 à 15:39

En news:48956e6b$0$945$, Wykaaa va escriure:

Par rapport à l'ordre lexicographique (codage des caractères).

Mmmm, ce n'est pas la même chose...

LEXICOGRAPHIQUE adj. XIXe siècle. Dérivé de /lexicographie/.
Relatif à la lexicographie. /Travaux lexicographiques./

LEXICOGRAPHIE n. f. XVIIIe siècle. Dérivé de /lexicographe/.
1. Science et technique de la composition et de la rédaction de lexiques,
de dictionnaires. [...]

ex. Dictionnaire de l'Académie, neuvième édition.

Antoine

Antoine Leca

05/08/2008 à 16:06

En news:48966b0a$0$18200$, candide va escriure:

Le verbe "déterminer" exprime quelque chose de fort et d'important.

Non. Relis le premier alinéa de la clause 3. Ensuite recherche les
occurrences de "to determine": elles ne sont pas en italique. Donc le terme
n'est pas particulièrement important dans le cadre de la norme C.

Si je dis z est déterminé par y et z, cela veut juste dire qu'il
existe une fonction f telle que z=f(x,y). Maintenant que
f(x,y)=sqrt(x*x+y*y) ou f(x,y)=|x|+|y| ou que sais-je encore,
ce n'est pas pareil.

Du point de vue de la détermination (ou de l'indétermination), si.

Ce que je dis c'est que la Norme n'exprime pas COMMENT le signe du
retour est lié au signe de la différence.

Le comment est le problème de l'implémenteur, et en l'occurence il a un peu
de marge de manouvre.

Il me semble quand même beaucoup plus précis de dire que le signe est
non seulement "déterminé" mais _identique_ au signe de la différence.

« Identique » est une autre relation (d'équivalence celle-là), et à mon avis
les auteurs ont cherché à éviter de rajouter une autre notion...

Dire cela évite en outre toutes les explications vaseuses et tout
aussi floues sur "la chaîne plus grande qu'une autre" dans un sens
qui n'a jamais été défini.

Qu'est-ce qui n'est pas défini dans :
- si les premiers éléments de chacune des deux suites sont différents, on
compare leurs valeurs ;
- sinon, on compare le reste des deux suites.

(et il s'agit ici d'une reformulation inférieure au texte de la norme).

Dans la partie /language/, on parle surtout de "string literal",

Effectivement mais pas seulement, cf. par exemple le passage où il est
question des arguments de la ligne de commande.

Tu peux effectivement proposer un renvoi vers 7.1.1 dans 5.1.2, j'ai
remarqué cela aussi en relisant.

qui est
en effet quelque chose de différent.

C'est ce que la norme dit en effet, partie Langage mais en se
référant à la partie Library (bonjour la clarté !) La différence ?
c'est vraiment discuter du sexe des strings.

Voici les définitions :

A string is a contiguous sequence of characters terminated by and
including the first null character.

De l'autre côté :

A character string literal is a sequence of zero or more multibyte
characters enclosed in double-quotes, as in "xyz"

(au passage, quand même assez extraordinaire de définir un concept par
le recours à un exemple, visez le 'as in "xyz"' !!).

La différence ? Réponse :

A character string literal need not be a string (see 7.1.1), because a
null character may be embedded in it by a escape sequence.

Il y a une autre différence : le premier est toujours dans le jeu
d'exécution, tandis que le second peut être constitué d'éléments du jeu
source.

Par ailleurs, il semble assez évident à lire les définitions que le 0 final
est inclus dans la première (et n'importe pas dans la seconde).

Donc quoi ? "titi" serait une chaine littérale

Un littéral chaîne, oui.

qui ne serait pas une chaîne ?

La chaîne commençant à la même adresse est { 't', 'i', 0 }, en supposant
qu'on l'ait assigné;
si l'objet auquel a été assigné le littéral fait 6 bytes ou plus, il y a une
seconde chaîne commençant 3 bytes plus loin (et avec la même valeur).

Alors, là je demande à comprendre la validité de ce
contre-exemple au vu des définitions données ci-dessus.

C'est typique des exemples qui font planter les compilateurs... (et par
conséquent à éviter pour les programmeurs).

En plus, il faut noter la logique : une chaine littérale de caractères
n'est pas nécessairement une chaîne !

Oui, c'est le fruit de l'histoire. C'est pour cela que la phrase du début de
la clause 3 est importante : il faut considérer les expressions en italiques
comme des touts indissociables, et ne pas chercher à en interpréter les
termes.

Par ailleurs, tu vois bien les différences entre un littéral en virgule
flottante et un objet de type flottant, non ?

Antoine

En news:48966b0a$0$18200$426a74cc@news.free.fr, candide va escriure:

Le verbe "déterminer" exprime quelque chose de fort et d'important.

Non. Relis le premier alinéa de la clause 3. Ensuite recherche les
occurrences de "to determine": elles ne sont pas en italique. Donc le terme
n'est pas particulièrement important dans le cadre de la norme C.

Si je dis z est déterminé par y et z, cela veut juste dire qu'il
existe une fonction f telle que z=f(x,y). Maintenant que
f(x,y)=sqrt(x*x+y*y) ou f(x,y)=|x|+|y| ou que sais-je encore,
ce n'est pas pareil.

Du point de vue de la détermination (ou de l'indétermination), si.

Ce que je dis c'est que la Norme n'exprime pas COMMENT le signe du
retour est lié au signe de la différence.

Le comment est le problème de l'implémenteur, et en l'occurence il a un peu
de marge de manouvre.

Il me semble quand même beaucoup plus précis de dire que le signe est
non seulement "déterminé" mais _identique_ au signe de la différence.

« Identique » est une autre relation (d'équivalence celle-là), et à mon avis
les auteurs ont cherché à éviter de rajouter une autre notion...

Dire cela évite en outre toutes les explications vaseuses et tout
aussi floues sur "la chaîne plus grande qu'une autre" dans un sens
qui n'a jamais été défini.

Qu'est-ce qui n'est pas défini dans :
- si les premiers éléments de chacune des deux suites sont différents, on
compare leurs valeurs ;
- sinon, on compare le reste des deux suites.

(et il s'agit ici d'une reformulation inférieure au texte de la norme).

Dans la partie /language/, on parle surtout de "string literal",

Effectivement mais pas seulement, cf. par exemple le passage où il est
question des arguments de la ligne de commande.

Tu peux effectivement proposer un renvoi vers 7.1.1 dans 5.1.2, j'ai
remarqué cela aussi en relisant.

qui est
en effet quelque chose de différent.

C'est ce que la norme dit en effet, partie Langage mais en se
référant à la partie Library (bonjour la clarté !) La différence ?
c'est vraiment discuter du sexe des strings.

Voici les définitions :

A string is a contiguous sequence of characters terminated by and
including the first null character.

De l'autre côté :

A character string literal is a sequence of zero or more multibyte
characters enclosed in double-quotes, as in "xyz"

(au passage, quand même assez extraordinaire de définir un concept par
le recours à un exemple, visez le 'as in "xyz"' !!).

La différence ? Réponse :

A character string literal need not be a string (see 7.1.1), because a
null character may be embedded in it by a escape sequence.

Il y a une autre différence : le premier est toujours dans le jeu
d'exécution, tandis que le second peut être constitué d'éléments du jeu
source.

Par ailleurs, il semble assez évident à lire les définitions que le 0 final
est inclus dans la première (et n'importe pas dans la seconde).

Donc quoi ? "titi" serait une chaine littérale

Un littéral chaîne, oui.

qui ne serait pas une chaîne ?

La chaîne commençant à la même adresse est { 't', 'i', 0 }, en supposant
qu'on l'ait assigné;
si l'objet auquel a été assigné le littéral fait 6 bytes ou plus, il y a une
seconde chaîne commençant 3 bytes plus loin (et avec la même valeur).

Alors, là je demande à comprendre la validité de ce
contre-exemple au vu des définitions données ci-dessus.

C'est typique des exemples qui font planter les compilateurs... (et par
conséquent à éviter pour les programmeurs).

En plus, il faut noter la logique : une chaine littérale de caractères
n'est pas nécessairement une chaîne !

Oui, c'est le fruit de l'histoire. C'est pour cela que la phrase du début de
la clause 3 est importante : il faut considérer les expressions en italiques
comme des touts indissociables, et ne pas chercher à en interpréter les
termes.

Par ailleurs, tu vois bien les différences entre un littéral en virgule
flottante et un objet de type flottant, non ?

Antoine

Vous avez filtré cet utilisateur ! Consultez son message

En news:48966b0a$0$18200$, candide va escriure:

Le verbe "déterminer" exprime quelque chose de fort et d'important.

Non. Relis le premier alinéa de la clause 3. Ensuite recherche les
occurrences de "to determine": elles ne sont pas en italique. Donc le terme
n'est pas particulièrement important dans le cadre de la norme C.

Si je dis z est déterminé par y et z, cela veut juste dire qu'il
existe une fonction f telle que z=f(x,y). Maintenant que
f(x,y)=sqrt(x*x+y*y) ou f(x,y)=|x|+|y| ou que sais-je encore,
ce n'est pas pareil.

Du point de vue de la détermination (ou de l'indétermination), si.

Ce que je dis c'est que la Norme n'exprime pas COMMENT le signe du
retour est lié au signe de la différence.

Le comment est le problème de l'implémenteur, et en l'occurence il a un peu
de marge de manouvre.

Il me semble quand même beaucoup plus précis de dire que le signe est
non seulement "déterminé" mais _identique_ au signe de la différence.

« Identique » est une autre relation (d'équivalence celle-là), et à mon avis
les auteurs ont cherché à éviter de rajouter une autre notion...

Dire cela évite en outre toutes les explications vaseuses et tout
aussi floues sur "la chaîne plus grande qu'une autre" dans un sens
qui n'a jamais été défini.

Qu'est-ce qui n'est pas défini dans :
- si les premiers éléments de chacune des deux suites sont différents, on
compare leurs valeurs ;
- sinon, on compare le reste des deux suites.

(et il s'agit ici d'une reformulation inférieure au texte de la norme).

Dans la partie /language/, on parle surtout de "string literal",

Effectivement mais pas seulement, cf. par exemple le passage où il est
question des arguments de la ligne de commande.

Tu peux effectivement proposer un renvoi vers 7.1.1 dans 5.1.2, j'ai
remarqué cela aussi en relisant.

qui est
en effet quelque chose de différent.

C'est ce que la norme dit en effet, partie Langage mais en se
référant à la partie Library (bonjour la clarté !) La différence ?
c'est vraiment discuter du sexe des strings.

Voici les définitions :

A string is a contiguous sequence of characters terminated by and
including the first null character.

De l'autre côté :

A character string literal is a sequence of zero or more multibyte
characters enclosed in double-quotes, as in "xyz"

(au passage, quand même assez extraordinaire de définir un concept par
le recours à un exemple, visez le 'as in "xyz"' !!).

La différence ? Réponse :

A character string literal need not be a string (see 7.1.1), because a
null character may be embedded in it by a escape sequence.

Il y a une autre différence : le premier est toujours dans le jeu
d'exécution, tandis que le second peut être constitué d'éléments du jeu
source.

Par ailleurs, il semble assez évident à lire les définitions que le 0 final
est inclus dans la première (et n'importe pas dans la seconde).

Donc quoi ? "titi" serait une chaine littérale

Un littéral chaîne, oui.

qui ne serait pas une chaîne ?

La chaîne commençant à la même adresse est { 't', 'i', 0 }, en supposant
qu'on l'ait assigné;
si l'objet auquel a été assigné le littéral fait 6 bytes ou plus, il y a une
seconde chaîne commençant 3 bytes plus loin (et avec la même valeur).

Alors, là je demande à comprendre la validité de ce
contre-exemple au vu des définitions données ci-dessus.

C'est typique des exemples qui font planter les compilateurs... (et par
conséquent à éviter pour les programmeurs).

En plus, il faut noter la logique : une chaine littérale de caractères
n'est pas nécessairement une chaîne !

Oui, c'est le fruit de l'histoire. C'est pour cela que la phrase du début de
la clause 3 est importante : il faut considérer les expressions en italiques
comme des touts indissociables, et ne pas chercher à en interpréter les
termes.

Par ailleurs, tu vois bien les différences entre un littéral en virgule
flottante et un objet de type flottant, non ?

Antoine

candide

05/08/2008 à 19:38

Antoine Leca a écrit :

En news:48962096$0$3720$, candide va escriure:
--------------------------------8<-----------------------------------
7.21.4 Comparison functions
1 The sign of a nonzero value returned by the comparison functions
memcmp, strcmp, and strncmp is determined by the sign of the
difference between the values of the first pair of characters (both
interpreted as unsigned char) that differ in the objects being
compared.
-------------------------------->8-----------------------------------

Certes mais le problème est que si je suis à la lettre ce que dit
7.21.4p1, je NE sais PAS quel est le signe de la valeur retournée.

Et c'est pourquoi

Comment dois-je comprendre ton "c'est pourquoi" quand je dit

"je NE sais PAS quel est le signe de la valeur retournée" ?

Abonderais-tu dans mon sens en disant "Et c'est pourquoi " ?

la relation univoque entre le signe retourné et le résultat de la
comparaison (résultat qui dépend de la comparaison utilisée, qui elle-même
dépend de la fonction).

Je ne comprends rien à ce que tu dis. C'est quoi la relation /univoque/
? "univoque" dans le sens déterminé sans ambiguïté ? ça reste à prouver.

Non seulement les petits bouts cités (en incluant 7.21.4.2p3) suffisent pour
définir deux relations d'ordre (> et >=)

La question n'est pas là. Je n'ai pas à recoller des petits bouts de-ci
de-là. Où la norme dit que je dois le faire et comment je dois le faire.
? Tu extrapoles complètement.

: qqs deux chaînes avec leurs représentations comme suites d'entiers de type
unsigned char, il n'y a qu'une seule possibilité dans le triplet
{strictement_positif, nul, strictement_négatif} ; et si on prend les deux
premiers (>=), c'est RAT.

Mais le problème n'est pas là, j'ai parfaitement compris le sens de tout
cela. Le seul problème c'est que la norme ne dit nullement quel est le
signe retourné, elle dit qu'il est "déterminé" mais ça ne me dit pas
quel _est_ (= _vaut_) ce signe.

Le préambule laisse entendre qu'il s'agit de la relation d'ordre
lexicographique

D'où tires-tu cette interprétation (nouvelle pour moi, je ne savais pas que
z<ñ, ou encore que z<A, dans l'ordre lexicographique) ?

Là je tombe de haut.

http://fr.wikipedia.org/wiki/Ordre_lexicographique#Ordre_lexicographique_sur_des_suites_finies

Bien évidemment, je parle au sens mathématique du terme pas au sens
Monsieur Larousse ou Monsieur Robert même si au fond ça revient au même.

-- au demeurant, croissant ou décroissant, je ne vois
pas comment on pourrait le dire (à cause de l'expression vague "is
determined").

L'ordre est toujours croissant, du fait du texte qui associe les valeurs
positives à l'ordre de >.

Non rien de tel n'est dit. C'est tout au plus suggéré. Et encore, en
faisant vraiment preuve de bonne volonté.

Bref, ce §7.21.4 me paraît extrêmement mal rédigé.

Tes propositions d'améliorations doivent être envoyées (en anglais) au
comité WG14.

Autre chose à faire. Pourtant, il est évident qu'il est facile de pondre
un texte clair qui définirait strcmp, je m'en sens tout à fait capable
(pas en anglais certes), il suffit de recoller comme il faut les deux
bouts de texte de la norme : le préambule et le passage que tu viens
d'évoquer avec ton histoire d'ordre croissant. A croire que le
paragraphe a été rédigé par deux personnes différentes.

La /chaîne/ de la partie 7 possède la propriété complémentaire d'avoir un

"complémentaire" : non ! le mot chaine n'a pas été défini. Devant ce
genre de situation, le lecteur de la norme a un comportement indéterminé
: tout est possible, il peut décompresser les short en long, transformer
les pointeurs en pointeuses, etc

zéro final, propriété qui est essentielle dans la partie 7 et qui n'est que
très accessoire dans les occurences des /littéraux chaîne/ de la partie 6.

un littéral chaine comme tu dis (chaîne a donc le statut d'adjectif ?)
n'est pas une chaine !

Antoine Leca a écrit :

En news:48962096$0$3720$426a74cc@news.free.fr, candide va escriure:

--------------------------------8<-----------------------------------
7.21.4 Comparison functions
1 The sign of a nonzero value returned by the comparison functions
memcmp, strcmp, and strncmp is determined by the sign of the
difference between the values of the first pair of characters (both
interpreted as unsigned char) that differ in the objects being
compared.
-------------------------------->8-----------------------------------

Certes mais le problème est que si je suis à la lettre ce que dit
7.21.4p1, je NE sais PAS quel est le signe de la valeur retournée.

Et c'est pourquoi

Comment dois-je comprendre ton "c'est pourquoi" quand je dit

"je NE sais PAS quel est le signe de la valeur retournée" ?

Abonderais-tu dans mon sens en disant "Et c'est pourquoi " ?

la relation univoque entre le signe retourné et le résultat de la
comparaison (résultat qui dépend de la comparaison utilisée, qui elle-même
dépend de la fonction).

Je ne comprends rien à ce que tu dis. C'est quoi la relation /univoque/
? "univoque" dans le sens déterminé sans ambiguïté ? ça reste à prouver.

Non seulement les petits bouts cités (en incluant 7.21.4.2p3) suffisent pour
définir deux relations d'ordre (> et >=)

La question n'est pas là. Je n'ai pas à recoller des petits bouts de-ci
de-là. Où la norme dit que je dois le faire et comment je dois le faire.
? Tu extrapoles complètement.

: qqs deux chaînes avec leurs représentations comme suites d'entiers de type
unsigned char, il n'y a qu'une seule possibilité dans le triplet
{strictement_positif, nul, strictement_négatif} ; et si on prend les deux
premiers (>=), c'est RAT.

Mais le problème n'est pas là, j'ai parfaitement compris le sens de tout
cela. Le seul problème c'est que la norme ne dit nullement quel est le
signe retourné, elle dit qu'il est "déterminé" mais ça ne me dit pas
quel _est_ (= _vaut_) ce signe.

Le préambule laisse entendre qu'il s'agit de la relation d'ordre
lexicographique

D'où tires-tu cette interprétation (nouvelle pour moi, je ne savais pas que
z<ñ, ou encore que z<A, dans l'ordre lexicographique) ?

Là je tombe de haut.

http://fr.wikipedia.org/wiki/Ordre_lexicographique#Ordre_lexicographique_sur_des_suites_finies

Bien évidemment, je parle au sens mathématique du terme pas au sens
Monsieur Larousse ou Monsieur Robert même si au fond ça revient au même.

-- au demeurant, croissant ou décroissant, je ne vois
pas comment on pourrait le dire (à cause de l'expression vague "is
determined").

L'ordre est toujours croissant, du fait du texte qui associe les valeurs
positives à l'ordre de >.

Non rien de tel n'est dit. C'est tout au plus suggéré. Et encore, en
faisant vraiment preuve de bonne volonté.

Bref, ce §7.21.4 me paraît extrêmement mal rédigé.

Tes propositions d'améliorations doivent être envoyées (en anglais) au
comité WG14.

Autre chose à faire. Pourtant, il est évident qu'il est facile de pondre
un texte clair qui définirait strcmp, je m'en sens tout à fait capable
(pas en anglais certes), il suffit de recoller comme il faut les deux
bouts de texte de la norme : le préambule et le passage que tu viens
d'évoquer avec ton histoire d'ordre croissant. A croire que le
paragraphe a été rédigé par deux personnes différentes.

La /chaîne/ de la partie 7 possède la propriété complémentaire d'avoir un

"complémentaire" : non ! le mot chaine n'a pas été défini. Devant ce
genre de situation, le lecteur de la norme a un comportement indéterminé
: tout est possible, il peut décompresser les short en long, transformer
les pointeurs en pointeuses, etc

zéro final, propriété qui est essentielle dans la partie 7 et qui n'est que
très accessoire dans les occurences des /littéraux chaîne/ de la partie 6.

un littéral chaine comme tu dis (chaîne a donc le statut d'adjectif ?)
n'est pas une chaine !

Vous avez filtré cet utilisateur ! Consultez son message

Antoine Leca a écrit :

En news:48962096$0$3720$, candide va escriure:
--------------------------------8<-----------------------------------
7.21.4 Comparison functions
1 The sign of a nonzero value returned by the comparison functions
memcmp, strcmp, and strncmp is determined by the sign of the
difference between the values of the first pair of characters (both
interpreted as unsigned char) that differ in the objects being
compared.
-------------------------------->8-----------------------------------

Certes mais le problème est que si je suis à la lettre ce que dit
7.21.4p1, je NE sais PAS quel est le signe de la valeur retournée.

Et c'est pourquoi

Comment dois-je comprendre ton "c'est pourquoi" quand je dit

"je NE sais PAS quel est le signe de la valeur retournée" ?

Abonderais-tu dans mon sens en disant "Et c'est pourquoi " ?

la relation univoque entre le signe retourné et le résultat de la
comparaison (résultat qui dépend de la comparaison utilisée, qui elle-même
dépend de la fonction).

Je ne comprends rien à ce que tu dis. C'est quoi la relation /univoque/
? "univoque" dans le sens déterminé sans ambiguïté ? ça reste à prouver.

Non seulement les petits bouts cités (en incluant 7.21.4.2p3) suffisent pour
définir deux relations d'ordre (> et >=)

La question n'est pas là. Je n'ai pas à recoller des petits bouts de-ci
de-là. Où la norme dit que je dois le faire et comment je dois le faire.
? Tu extrapoles complètement.

: qqs deux chaînes avec leurs représentations comme suites d'entiers de type
unsigned char, il n'y a qu'une seule possibilité dans le triplet
{strictement_positif, nul, strictement_négatif} ; et si on prend les deux
premiers (>=), c'est RAT.

Mais le problème n'est pas là, j'ai parfaitement compris le sens de tout
cela. Le seul problème c'est que la norme ne dit nullement quel est le
signe retourné, elle dit qu'il est "déterminé" mais ça ne me dit pas
quel _est_ (= _vaut_) ce signe.

Le préambule laisse entendre qu'il s'agit de la relation d'ordre
lexicographique

D'où tires-tu cette interprétation (nouvelle pour moi, je ne savais pas que
z<ñ, ou encore que z<A, dans l'ordre lexicographique) ?

Là je tombe de haut.

http://fr.wikipedia.org/wiki/Ordre_lexicographique#Ordre_lexicographique_sur_des_suites_finies

Bien évidemment, je parle au sens mathématique du terme pas au sens
Monsieur Larousse ou Monsieur Robert même si au fond ça revient au même.

-- au demeurant, croissant ou décroissant, je ne vois
pas comment on pourrait le dire (à cause de l'expression vague "is
determined").

L'ordre est toujours croissant, du fait du texte qui associe les valeurs
positives à l'ordre de >.

Non rien de tel n'est dit. C'est tout au plus suggéré. Et encore, en
faisant vraiment preuve de bonne volonté.

Bref, ce §7.21.4 me paraît extrêmement mal rédigé.

Tes propositions d'améliorations doivent être envoyées (en anglais) au
comité WG14.

Autre chose à faire. Pourtant, il est évident qu'il est facile de pondre
un texte clair qui définirait strcmp, je m'en sens tout à fait capable
(pas en anglais certes), il suffit de recoller comme il faut les deux
bouts de texte de la norme : le préambule et le passage que tu viens
d'évoquer avec ton histoire d'ordre croissant. A croire que le
paragraphe a été rédigé par deux personnes différentes.

La /chaîne/ de la partie 7 possède la propriété complémentaire d'avoir un

"complémentaire" : non ! le mot chaine n'a pas été défini. Devant ce
genre de situation, le lecteur de la norme a un comportement indéterminé
: tout est possible, il peut décompresser les short en long, transformer
les pointeurs en pointeuses, etc

zéro final, propriété qui est essentielle dans la partie 7 et qui n'est que
très accessoire dans les occurences des /littéraux chaîne/ de la partie 6.

un littéral chaine comme tu dis (chaîne a donc le statut d'adjectif ?)
n'est pas une chaine !

candide

05/08/2008 à 22:18

Antoine Leca a écrit :

LEXICOGRAPHIQUE adj. XIXe siècle. Dérivé de /lexicographie/.
Relatif à la lexicographie. /Travaux lexicographiques./

LEXICOGRAPHIE n. f. XVIIIe siècle. Dérivé de /lexicographe/.
1. Science et technique de la composition et de la rédaction de lexiques,
de dictionnaires. [...]

ex. Dictionnaire de l'Académie, neuvième édition.

Heu à mon avis, sauf oulipisme chevillé au corps, on ne lit pas la Norme
avec un dictionnaire littéraire !
Pourquoi pas un dictionnaire de poésie ou un dictionnaire des rimes tant
qu'on y est ;) !!

Description de strcmp dans la norme

10 réponses

Veuillez sélectionner un problème