PHP bug ili mi nesto nije jasno

I kada sam prijavio bug dobio sam odgovor da to nije bug i da treba da procitam manual.

Uopste mi nije jasno kojom logikom radi. Oba slucaja MORAJU da daju false.

Potpis

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}

Ne bi trebalo da bude false, jer ti "==" automatski konvertuje promenljivu iz stringa u integer pri poredjenju. Samim tim, 127 = 127 u prvom slucaju. Ne znam zasto i u drugom slucaju nije true, moje misljenje je da ima veze sa zaokruzivanjem.

http://php.net/manual/en/function.intval.php - ovde mozes naci dosta informacija :)

Potpis

THE ONLY EASY DAY WAS YESTERDAY

Izgleda da nije problem u intval nego u ==.
Posto je sa jedne strane integer PHP sa druge strane da stavi broj pa uradi prvo float pa int.
i onda se dodje na :


druga ip gde nije 0 drugi broj

Potpis

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}

Ako izbacimo intval i stavimo samo brojeve, imamo:



Ovo daje isto kao i kod u inicijalnom postu. Na php.net piše da se kod operatora == promenljive postavljaju na zajednički tip (ovde valjda integer), ali biće da uzima decimalu iza tačke, tj u prvom slučaju 127.0, a u drugom 127.1.
Kao da rezultat intval pri poređenju tretira kao floatval.

Pa cak i da uzima float, trebalo bi u oba slucaja da daje true...

Potpis

THE ONLY EASY DAY WAS YESTERDAY

Nagađam, ali mi se čini da za 127.0 konta da je isto što i 127, a za 127.1 da nije.

Pa 127 je jednako sa 127.0 ali je problem kako dodje do 127.0.
Cim je sa leve strane pretvorio 127.0.1.1 u 127.0 treba da konta da to nije to i da stane.
Drugo je da sam imao 127.0 kao string i on ga pretvorio u 127.0 kao broj pa to je isto i onda moze dalje da poredi.

Potpis

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}

Ali radi se o tome da uopste ne treba da radi sa float vrednostima, trebalo bi sve da konveruje u integer posto je "intval" funkcija iskoriscena u poredjenju... a i kako god da poredi, poredi 2 iste vrednosti koje se konvertuju opet na ISTI nacin, tako da bi trebalo da daju iste konvertovane vrednosti... ako ima neko logicno objasnjenje za ovaj drugi slucaj bilo bi lepo da se javi.. :)

Potpis

THE ONLY EASY DAY WAS YESTERDAY

Zaista i piše u manual-u objašnjenje za ovakvo ponašanje:

String conversion to numbers

Type Juggling

Što će reći da se string 127.1.1.1 konvertuje u float jer sadrži tačku, a zatim se u poređenju sa int-om int konvertuje u float. Dakle, dešava se:
1) '127.1.1.1' == 127
2) 127.1 == 127
3) 127.1 == 127.0
=>false

Potpis

Pera električar 0637129710, BG, preporučujem.

Da, ali ja nisam radio matemtaicku operaciju po kojoj je on mogao da zakljuci da li ja radim sa brojevima ili stringovima
jer nema matemtaickih operacija sa stringovima.
Radio sam operaciju poredjenja i to je moguce sa stringovima.
Ne znam na koji nacin sam ga naveo da on razmislja sa float-ovima.

Potpis

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}

Kod:


Output:

Nevezano da li se radi o aritmetičkoj ili logičkoj operaciji između stringa i broja (int ili float), sa stringom se dešava sledeće:
- ako sadrži broj na svom početku, biva cast-ovan u int
- ako sadrži broj iza koga sledi na početku iza koga se nalazi '.' , biva cast-ovan u float
- ako sadrži bilo koji drugi karakter na početku, tretira se kao 0

Npr.

'2' + 2 = 4;
'2.5' + 2 = 4.5;
'.5' + 1 = 1.5;
'2somestring' + 2 = 4;
'somestring' + 2 = 2;

nije bug, vilyu je lepo objasnio zasto takav rezultat.

za sta ti ovo tacno treba?

da bi se osigurao eksplicitno kastuj i levu stranu u int



ili mozda jos bolje da koristis sledecu proveru (da li $ip pocinje sa 127)


PS. obavezno koristi === da ne bi dobio lazno tacno poredjenje

Potpis

look
closer

DON'T
PANIC