Маленький сюрприз при переходе на 64x

[Kelkos]

Маленький сюрприз при переходе на 64x

Ох и намаялся я с сайтом, когда перенёс его с Фряхи 6.2 на Фряху 7-ю 64 бит.

Прямо таки пасхальные яйца какие то.

Функа ip2long на 32-х и 64-х битной системе даёт разные результаты.

кто не верит - тестите.
<?
echo ip2long('246.11.104.186');
?>

Меня очень удивило, что подобные баги не правятся в новых версиях php. Религия, что ли, запрещает? %)

 

[Wicked]

Религия, что ли, запрещает? %)

именно так: http://phpclub.ru/talk/showthread.php?threadid=114598

-~{}~ 15.06.09 09:40:

.

 

[Kelkos]

именно так: http://phpclub.ru/talk/showthread.php?threadid=114598

Фигасе. Идиотизм какой то.

Кто знает, сколько хочет денег Tony2001, что бы исправить эти баги?

 

[iceman]

Kelkos
переопредели функции, если не хочется те во всем проекте менять их...

 

[Wicked]

iceman
осталось узнать, как в пхп переопределять функции

 

[флоппик]

сталось узнать, как в пхп переопределять функции

перекомпиляцией

 

[Wicked]

ага... наш метод .-)

интересно, кстати... а в самом пхп есть юнит-тесты, которые предусматривают, что на 32-битных машинах должно возвращаться одно значение, а на 64 - другое?

 

[grigori]

Kelkos "я поставила бы этой планете ноль" (С)

Wicked, ручками в исходниках

тесты очень даже нужны - напиши их! в qa.php.net нужна помощь

 

[iceman]

APD +)))
http://ru.php.net/manual/ru/function.override-function.php

runkit отпадает... он для пользовательских...

а вообще, как Тони2001 исправит ему эти "глюки", даже за деньги? +)

 

[Wicked]

ахахаха )

ext/standard/tests/network/ip_x86_64.phpt:

--EXPECTF--<--->
...
int(4294967295)
string(15) "255.255.255.255"
int(4294967040)
string(13) "255.255.255.0"

ext/standard/tests/network/ip.phpt:

--EXPECTF--<--->
...
int(-1)
string(15) "255.255.255.255"
int(-256)
string(13) "255.255.255.0"

 

[grigori]

iceman
гораздо проще дописать свою ф-ю и заменить все использования встроенной ф-ции на свою во всех файлах
например, notepadd++

 

[zerkms]

показательный костыльчик

 

[флоппик]

zerkms, правильно, если под баг подогнать тесты, то это уже не баг, а документированная фича.
Только вот на тони мне кажется, наезжают зря. Все же, он тоже всего лишь человек, да еще и один человек.

 

[grigori]

вероятно, в этом поведении есть некоторая логика

я не знаю, как в системном программировании принято транслировать ip4-адрес в 64-bit int

если его транслировать в отрицательный 64, то по битам это будет совсем не то же, что 32-разрядный
при "прямой" трансляции в старшие разряды просто дописываются нули
а PHP, естесно, "отрисовывает" int так, как умеет
но правильная отрисовка бинарного представления адреса в строку - дело программиста, а не команды PHP

так что не факт ...

 

[Kelkos]

grigori, может быть и есть. Может быть там даже есть тонкий юмор.
Но всё это не оценят ни владельцы сайтов, ни владельцы хостингов, ни программеры, которые "напоролись" на это.

Предствьте, что есть сайты, где функи с такими багами активно юзаются. Всё живёт годами на 32-х битной системе.
Потом хостер меняет на 64-х и понеслаааась... Крики, вопли, срач, претензии друг к другу..


В моём случае это вызвало вообще ступор сервака и никто 2-е суток не мог понять в чём трабел. (в паре очень важных мест была привязка именно к этой функе.). Чуть было не дошло до того, что бы покупать новый серв. (вот потеха бы была. хех)
Как итог - люди налетели на баблос (за простой сайтов) и теперь ищут крайних. Отмазки типа "Йопанный Zend!!!!" не катят.

а вообще, как Тони2001 исправит ему эти "глюки", даже за деньги? +)

Ну, Тони как бэ имеет некоторое отношение к пхптим, А значит может двинуть мысль типа "А давайте не будем тупить и сделаем, как нас просят!" в своём узком кругу "пхптимы".
Глядишь и сдвинется дело с мёртвой точки.

 

[atv]

Как итог - люди налетели на баблос (за простой сайтов) и теперь ищут крайних. Отмазки типа "Йопанный Zend!!!!" не катят.

Когда ставили линух на сервак, знали что делали, когда пхп туда ставили, тоже знали что делали, когда писали 99% аптайм, и тогда знали что делали, хай платят баблосы владельцы хостингов.

 

[флоппик]

вероятно, в этом поведении есть некоторая логика

Логика есть. Но есть несколько но - да, ПХП не умеет «отображать» unsigned int. Поэтому он возвращает signed, и часть значений могут стать отрицательными. Да, в 64 битных версиях он соотвестно, может вернуть «половинку» 64битного инта, и он будет положительным.

Проблема в том, что язык высокого уровня по определению предназначен для того, что бы скрывать разницу между платформами, на которых он работает. Поэтому - это баг.
Парадокс в том, что поведение этих функций на 64битной платформе «правильней» чем на 32х битной. Но решить это для 32битной платформы сейчас, я думаю, очень сложно. Поэтому либо мы должны гнатся за backward comp., имитируя поведение 32битной функции на 64битной платформе, пусть даже путем введения каких-то флагов в таких функциях... либо - я не знаю.

Ну, Тони как бэ имеет некоторое отношение к пхптим, А значит может двинуть мысль

Имеет, может. Имхо, он вносит огромный вклад в пхп. Но он человек, может злится, может уставать. Возможно, если бы дискуссия с учестием него была бы более мирной, все бы уже давно подвинулось хотябы в сторону обсуждения, Однако почему то все предпочли на него психовать.

-~{}~ 15.06.09 20:13:

Ну конечно, с тестами честно говоря, выглядит довольно смешно. Тесты кагбы пишут, что бы решать такие проблемы. Какой толк в покрытии тестами, если тесты подгоняют результаты?

 

[Kelkos]

Поэтому - это баг.

Самое забавное, что решить его можно только введя в новые версии PHP какую то глобальную настройку, типа 32x_compliance, Т.к. если просто исправить функи, то начнутся траблы у сайтов, которые уже приработались на 64x
По крайне мере, хостер может нивелировать переход на 64 бита со старых 32х битных систем с помощью этого параметра.

Вообщем, капец.

 

[Lightning]

Это баг безусловно, но его действительно не так уж сложно самому исправить.

 

[Santiago]

Автор оригинала: флоппик
то это уже не баг, а документированная фича

Именно так и есть. Причем такое поведение задокументировано. И то, что поведение функции отличается на различных платформах, должно быть в первую очередь предусмотрено пользователем этой функции (опять же, в случае документирования сего факта).
Ну а если есть мысли, почему это поведение надо изменить, то php.internals для всех открыт. Но далеко не факт, что если кто-то считает, что что-то неправильно, на самом деле так и есть.