artasInterSkyА что будет если в сжатой строке появится символ Chr(0)?

сжатая строка будет обрезана по этот символ. А с чего бы вдруг ему там появлятся ?

Вообще-то в php не будет :) Не знаю с чего такой вывод, но попробуйте выполнить:


и сами убедитесь.

InterSkyПроверка не дала бы ответа о безопасности наличия символа #0. Его наличие в строке может быть частным случаем... Скажем в Delphi объявляешь строковую переменную в обработчике, и она 100 раз подрат будет пустой, а потом бах и окажется заполненной всякой всячиной. Тоже частный случай...


В программировании не бывает частных случаев :). Один и тот же код не будет отрабатывать по-разному при тех же условиях.
В Дэлфи так происходит потому, что ячейки памяти, выделяемые под локальные переменные не обнуляются (а зачем, если например я создам массив, и решу его сразу записать значениями). Потому там нету никаких "частных случаев", а просто правило - перед чтением переменной её надо записать.

В данном случае подобные нюансы отсутствуют.

InterSkyЯ по этому и спрашиваю у тех кто знает...
А то кто его знает, один раз увидел Chr(0), а потом какой-нибудь Flush пройдёт и подожмёт строки до первых нулей...
В конце концов в РНР много сюрпризов, например:
Данный код вернёт True.

Это не сюрприз (после перехода с delphi у меня тоже были проблемы с нестрогим сравнением и с процедурой приведения типов, но просто надо было разобраться).

в отличие от строгого сравнения (===) при нестрогом сравнении типы переменных приводятся к одному и только тогда сравниваются. Это делается всегда по правилу, более сложный тип приводится к более простому (если так можно выразится). Потому при сравнении двух переменных разного типа, int приводится к boolean, float к int или boolean, string к float или int или boolean и т.д.

Потому то, попробуйте привести "txt" к типу int... что у Вас получится? )) дааа... 0... а теперь сравниваем if(0==0)... что получаем? правильно - true :)
А вот если вместо "txt" написать "1txt", то уже получим false (так как "1txt" после приведения к типу int будет равно 1)

st_stА ещё javascript есть, в нём всё наоборот (или в php всё наоборот) и alert(0=='txt') вернёт false. Также как и две разные строки - ("37127371298379127398733" == "37127371298379127398734") в php это true, а в js false. Это web, здесь всё серьёзно

Ага... а вот "37127371298379127398733b" == "37127371298379127398734b" уже вернёт false. Видимо php по умолчанию все строки вида /^\d+$/ старается сравнивать как integer, а строки /\d+.\d+/ как float. (соответственно в первом случае всё, что больше максимума для integer будет приравниваться к этому максимуму, а во втором просто точность в 14 знаков, а остальное отбрасывается)
))) Кстати, об этом не знал... спасибо :) буду внимательнее следить за строками, если в них есть только цифры.

ScareCrowтред нечетателей документации.

Киньте пожалуйста ссылку на доки, где данное поведение обосновывается (или хотя бы упоминается).

ScareCrow http://www.php.net/manual/en/language.operators.comparison.php
авторIf you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number and the comparison performed numerically. These rules also apply to the switch statement. The type conversion does not take place when the comparison is === or !== as this involves comparing the type as well as the value.

хм) правда есть. спасибо.
Не понятна мне конечно причина такого поведения, но ладно... разрабам виднее ))

ScareCrowавторНе понятна мне конечно причина такого поведения, но ладно
эм? если просто то потому что у нас есть язык с нестрогой типизацией ВЕЗДЕ.
если сложно - то http://lxr.php.net/xref/PHP_5_4/Zend/zend_operators.c#1402

При сравнении двух значений, определяется тип двух переменных и если обе имеют тип string, то отправляется в функцию, которая сначала преобразовывает обе строки в числа (если это возможно) и потом, если произошло переполнение, то идёт переход по ссылке string_cmp (не знаю, может это что стандартное, но я не нашёл данной ссылки в указанном файле), иначе выполняется сравнение двух числовых значений полученных от преобразований.

Непонятно 2 момента (я так понимаю Вы в теме, может сможете объяснить, а то я совсем не въезжаю):
1. почему проверка на переполнение не сработала (там я вижу ещё уйма условий проверяется, может в них дело... не влазил в самую глубину)?
2. а вообще, нафиг это надо (когда сверяем 2 строки). Если например предполагается, что мы хотим сравнить числа записанные в строках, то достаточно проверить обе строки по регулярке /^\d+(\.\d+)?$/ и если есть совпадение у обеих строк, то просто добираем строки нулями так, что бы до точки и после неё количество символов было одинаковым. После чего проводим как и обычно посимвольную сверку строк :)
Разве так не легче и не более правильно?

ScareCrow,

Думал перед тем, как написать, после этого. После Вашего ответа тоже думал... да вот не придумывается. В методе разработчиков есть какая-то сверхумная хитрость?

InterSkyПрограмёрВ методе разработчиков есть какая-то сверхумная хитрость?
Эта хитрость внедрена по просьбе АНБ :)

То есть рассказать никто не сможет? И через сколько предполагается рассекретить?

ScareCrowпроверять регуляркой ВСЕ строки в слабо типизированном языке - медленно.

Вообще, в стандартном случае это не дольше, чем переводить строку в число :) Но учитывая особенность ПХП, где переменная хранится сразу во всех возможных типах (насколько я помню), согласен, будут затраты времени на лишние проверки.

Ну что ж, надо привыкнуть строки сравнивать операцией строгого сравнения :)