PHP problème sur uen égalité => soit je suis con, soit je deviens fou ! - Page 1

voici le problème :

que devrait afficher le code suivant :

<?php
	$a = 0;
	$b = 'x';
	echo $a.' = '.$b.' => '.($a==$b ? 'oui' : 'non');	
?>

pour moi ca devrait me retourner 'non', et ca me retourne 'oui' !!!

quelqu'un aurait une explication ?

echo $a.' = '.$b.' => '.(($a==$b) ? 'oui' : 'non'); ?

http://fr2.php.net/manual/fr/language.types.string.php

a la partie "conversion"

La valeur est définie par la première partie de la chaîne. Si la chaîne de caractères débute par une valeur numérique cette valeur sera celle utilisée. Sinon, la valeur sera égale à 0 (zéro).

les . c'est des concatenations
pour les ? et : c'est un test conditionnel (condition ? a_faire_si_vrai : a_faire_si_faux)

ça te va pas ma raison?

exemple de la doc:
$foo = 1 + "bob3"; // $foo est du type integer (1)

en gros une chaine de caracteres qui n'est pas un nombre vaut zéro.

./4 Je sais bien, je proposais un parenthésage supplémentaire, pour lever une ambiguïté possible (je ne connais pas par coeur les priorités des opérateurs).
Sinon, tu peux utiliser === pour éviter le pb dont parle squalyl.

(ah ouf j'ai cru être ignoré)

ce qui est marrant c'est que 0 soit pas converti en chaine "0"
doit y'avoir une autre règle qq part qui explique pourquoi

Sasume (./6) :
Je sais bien, je proposais un parenthésage supplémentaire, pour lever une ambiguïté possible

ah oui, pardon, j'avais pas vu les parenthèses supplémentaires ! mais ça ne résout pas le pb

squalyl (./5) :
exemple de la doc: $foo = 1 + "bob3"; // $foo est du type integer (1)

oui, ca je sais, c'est normal.

mais la, c'est de l'égalité dont on parle. il a d'un côté un integer et d'un autre un string, et ce qui me dérange, c'est qu'il convertisse mon 'x' en entier et qu'il fasse donc la conversion la plus destructive au lieu de convertir mon 0 en string

squalyl (./7) :
ce qui est marrant c'est que 0 soit pas converti en chaine "0"

voilà, on est d'accord !

y'a des infos sur cette page
http://fr3.php.net/manual/fr/types.comparisons.php

http://fr3.php.net/manual/fr/language.types.type-juggling.php
Le transtypage n'a pas toujours un résultat prévisible lors du transtypage entre certains types.

ça m'a l'air d'être au petit bonheur

surtout un sacré bordel !

je n'arrive pas à comprendre certains éléments du 2em tableau de http://fr3.php.net/manual/fr/types.comparisons.php

comment est-ce que 0 et n'importe quelle chaine de caractère peuvent être égaux ?!

parce qu'une chaine non convertible en nombre vaut zéro et pas NaN (qui existe pas pour les entiers), mais on retombe sur la question précédente, pourquoi convertit il en entier et pas en chaine dans cette comparaison ?

d'ailleurs:

[squalyl@dedibox ~]$ cat test.c
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>

int main(void)
{
        long int l;
        char *data,*end;

        data="12345";
        errno=0;
        l=strtol(data,&end,10);
        printf("data=[%s] long=[%ld] errno=[%d] end=data+%d\n",data,l,errno,end-data);

        data="plop";
        errno=0;
        l=strtol(data,&end,10);
        printf("data=[%s] long=[%ld] errno=[%d] end=data+%d\n",data,l,errno,end-data);

        return 0;
}

[squalyl@dedibox ~]$ gcc test.c
[squalyl@dedibox ~]$ ./a.out
data=[12345] long=[12345] errno=[0] end=data+5
data=[plop] long=[0] errno=[0] end=data+0

donc ça résout bien le pb pour la valeur des chaines non convertibles, et ça change même pas errno!
pour savoir quel type est utilisé dans la comparaison, j'ai bien peur qu'il faille aller voir dans le code himself

edit: idem pour les doubles:

[squalyl@dedibox ~]$ cat test.c
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>

int main(void)
{
        double l;
        char *data,*end;

        data="12345";
        errno=0;
        l=strtod(data,&end);
        printf("data=[%s] double=[%g] errno=[%d] end=data+%d\n",data,l,errno,end-data);

        data="plop";
        errno=0;
        l=strtod(data,&end);
        printf("data=[%s] double=[%g] errno=[%d] end=data+%d\n",data,l,errno,end-data);

        return 0;
}

[squalyl@dedibox ~]$ gcc test.c
[squalyl@dedibox ~]$ ./a.out
data=[12345] double=[12345] errno=[0] end=data+5
data=[plop] double=[0] errno=[0] end=data+0

clair et le pire c'est que j'ai passé 2 hrs à essayer de trouver ou etait l'erreur dans mon code, sans imaginer une seule seconde que ca pouvait venir de là !

J'ai pas compris l'intérêt de ton code en C squalyl
Sinon Spipu la solution proposée en ./6 ne convenait pas ?

je trouve ça quand même spécialement dangereux ces conversions automatiques étranges sans aucun avertissement ni rien :/

(sinon pareil, pas capté le rapport entre le bout de code en C et le topic)

Sasume (./14) :
J'ai pas compris l'intérêt de ton code en C squalyl
Sinon Spipu la solution proposée en ./6 ne convenait pas ?

sisi, mais j'avais la solution avant de poster c'est pourquoi j'avais demandé une explication et non une solution

(et sinon, idem pas capté le rapport avec le bout de code en C)

but: montrer le comportement de strtod quand on lui file une chaine pas convertible.

c'était pas indispensable, ok

Perso j'utilise jamais deux types de données différents dans la même expression en php sans expliciter celui qui m'intéresse (avec intval/strval/etc). Ca évite les problèmes.

La tristesse des langages faiblement typés …

autrement dit, java rox ?

Pas forcément.
Java roxxe sur le fait qu’il est fortement typé (difficile (mais pas impossible) d’avoir des gros soucis de transtypage).
Asm roxxe sur le fait qu’il n’est pas du tout typé (le programmeur sait pertinemment qu’il doit faire très attention, mais il a toute liberté pour faire les checks kivonbien et pour faire des feintes de l’ours grâce à l’absence de type).
Alors qu’un langage faiblement typé cumule les inconvénients des langages fortement typés et pas du tout typés.