interessante frage zum string casting

[3DMax]

hi,

habe gerade im heiseforum folgende interessante frage entdeckt:

Zum Beispiel der ganze Typendurcheinander geht mir auf den Geist -
wenn man auf Strings castet, dann heißt das nämlich überhaupt nix,
hier ein Beispiel:

if ( (string)'0X2BAD' == (string)'11181' ) {
echo "*ARGH*";
} else {
echo "PHP ist super";
} 

Na? Was kommt wohl raus? Ja, raus kommt:
> *ARGH*
Sowas gibts nur bei PHP. Es gibt zwar den ===, aber da die Typen alle
String sein müssten, müsste auch ein == reichen!

weiß jemand, warum das so ist? ich habe

[Slava]

hm
gut zu wissen.
PHP ist von Menschen entwickelt worden und die Menschen machen die Fehler.

ich finde so ein verhalten natürlich komisch, bei c, c++, java, c# gibt es so ein problem nicht, da jede Variable mit seinem Type deklariert sein muss.

[penizillin]

da gibt es einiges:

http://de2.php.net/manual/en/languag...e-juggling.php
http://de2.php.net/manual/en/languag...ing.conversion

also: einfach vermeiden. das ist einfach.

[ghostgambler]

Re: interessante frage zum string casting

Hm ... scheint mit dem zval zusammen zu hängen, sobald man einen Buchstaben oder eine Zahl ändert funktioniert es nicht mehr, warum es allerdings intern als gleich angesehen wird Oo,

strcmp schafft Abhilfe!

[3DMax]

Original geschrieben von Slava
ich finde so ein verhalten natürlich komisch, bei c, c++, java, c# gibt es so ein problem nicht, da jede Variable mit seinem Type deklariert sein muss.

du weißt schon, dass das hier ein php-forum ist?

[3DMax]

@penizillin && @ ghostgambler

also ist es doch offensichtlich ein php-bug? .. oder wie seht ihr das?
... so langsam geht mir das php-type-casting auch auf die nervern

[3DMax]

Original geschrieben von penizillin also: einfach vermeiden. das ist einfach.

und wie vermeiden?
nenne mal ein konkretes beispiel, anstatt links zu posten.

[Koala]

(string)'0X2BAD' weist ja dem Inhalt 0X2BAD den Typ String zu.

Dies ergibt true.

Und wenn ich eine Typ-Zuweisung mit einer anderen Typ-Zuweisung
vergleiche, dann ergibt das eben auch true.

Also in der if-Abfrage nicht die Zuweisung vergleichen,
sondern den Inhalt der Variablen.

[Slava]

Original geschrieben von Koala
(string)'0X2BAD' weist ja dem Inhalt 0X2BAD den Typ String zu.

Dies ergibt true.

Und wenn ich eine Typ-Zuweisung mit einer anderen Typ-Zuweisung
vergleiche, dann ergibt das eben auch true.

Also in der if-Abfrage nicht die Zuweisung vergleichen,
sondern den Inhalt der Variablen.

nein
wenn du (string)23==(string)24 vergleichst bekommst du false, also kasting macht nur typeumwandlung und kann kein boolean liefern.
Problem ist, das bei 0X2BAD und 11181 handelt es sich um gleichen integer Wert nur eben anderes geschrieben und operator == vergleicht die Werte ohne rücksicht auf die typen.
das bedeutet, dass operator "==" versucht bei vergleich alle mögliche typeumwandlungen durchzutesten und bei erstem positivem vergleich true liefert, sonnst false.

Also meine meinung nach liegt es am ganz normalem gierigem verhalten von "==" operator.
als beweis:
if((string)"false" == (float)0)echo "stimmt?";
operator== ist eine function, die vergleich von 2 Werten ohne rücksicht auf die Type macht. das war schon immer so.
für die typen und werten vergleich gibt es operator===

Original geschrieben von 3DMax
du weißt schon, dass das hier ein php-forum ist?

ja
aber php ist in c geschrieben worden und operator == hat intern eine andere Name:
ZEND_API int compare_function(zval *result, zval *op1, zval *op2 TSRMLS_DC)

du kannst auch Geburt von diesem operator nachvollziehen, wenn du die source dateien zend_operators.c und zend_operators.h anschaust

[ghostgambler]

Original geschrieben von Slava
Problem ist, das bei 0X2BAD und 11181 handelt es sich um gleichen integer Wert nur eben anderes geschrieben

Das Problem ist aber trotzdem merkwürdig, da

<?php
echo intval('0X2BAD');
echo intval('11181');

ergibt

0
11181

D.h. die interne Konvertierung in der zval-struct, ist wiederum anders als die, die bei PHP ausgeführt wird, weshalb alles ziemlich tricky ist...

Aber wenn das auf Heise schon stand, gehe ich davon aus, dass sich das Verhalten in einer der nächsten php-Versionen ändern wird. Ganz abgesehen von dem Verhalten in php6, wenn die Unicode-Unterstützung kommen wird ... mal abwarten

[closure]

@ghostgambler
das kann auch an der implementierung von intval liegen und hat
keinen beweischaracter. Es ist doch schon ein unding, dass php
automatisch versucht stringliterale die zufällig mal aussehen
wie zahlen auch bei vergleichen wie zahlen behandelt.

Der "cast" im konkreten fall von string zu string (was ja eigentlich
kein cast ist) und der anschliessende vergleich lassen das doch deutlich werden.

OffTopic:

---

Solche dinge und noch vieles mehr, hat mich schon vor einiger zeit
dazu gebracht in php nicht mehr zu sehen als spielerei. Etwa wie brainfuck, nur
das brainfuck konsistenter ist.

Seht es ein, ihr befindet euch auf einem sinkenden schiff. Ihr wollt
doch nicht die letzten sein, die es verlassen oder ?

---

grets

[Slava]

also hier finde ich das verhalten von "intval" comisch
es siht so aus, dass intval mit hexadezimalen werten nicht umgehen kann.
wenn du
echo hexdec('0X2BAD');
machst, dann bekommst du eigentlich 11181.

operator == macht einfach wie ich schon gesagt habe alle mögliche Vergleiche und bei erstem Positivem Vergleich liefert True zurück.

Ich kenne der genaue Hintergrund nicht, aber vermute einfach, dass es extra gemacht wurde , um direkt ein wert von einer Variable z.b.s mit Inhalt von POST Variable durchzuführen ohne Rücksicht auf die Type.

Wir müssen auch bedenken, dass bei älteren PHP-versionen (wenn ich mich nicht irre) überhaupt kein casting ind form (type) gegeben hat, sondern es wurde automatisch durchgeführt, und wenn es uns nicht gepasst hat, dann haben wir einfach $var*1 oder $var.""
bzw intval, strval aufgerufen.

Fazit:
1) nur === kann mit Garantie 2 werte mit Ihren Typen vergleichen
2)wenn du 2 werte mit == vergleichen willst, dann mach dir keine mühe wegen Typenumwandlung, da "==" pfeift einfach darauf.

[Slava]

Original geschrieben von closure

Seht es ein, ihr befindet euch auf einem sinkenden schiff. Ihr wollt
doch nicht die letzten sein, die es verlassen oder ?

[/OT]

grets [/B]

mir macht es nichts aus.
ich bin schon gesunken.
ich bin mir sicher, dass PHP sehr gute Zukunft

[onemorenerd]

Na das sehe ich aber anders. Ein sinkendes Schiff sieht nie wieder einen Hafen, erst recht keine Werft. PHP wird aber weiterentwickelt.
Diese Vergleichsanomalien (gibt sicher mehr als die eine von Heise) können durchaus schnell beseitigt werden - der Entwicklungskurs wendet sich zwar nur langsam in Richtung der vielstimmig geforderten Enterprise-Fähigkeit, aber das hat nichts damit zu tun, dass Fehler nicht beseitigt werden: Einfach einen Bugreport absetzen (sicher schon passiert) und mit dem nächsten Release ist 1=1 bestimmt schon true.

[3DMax]

Original geschrieben von closure
Solche dinge und noch vieles mehr, hat mich schon vor einiger zeit
dazu gebracht in php nicht mehr zu sehen als spielerei.

er hat "jehova" gesagt, steinigt ihn