было бы странно, если бы я ограничивал числовую переменную неопределёнными числами. PS: респект за букву ё! ну да и пох
Повторюсь, после проверки могут быть разные действия, по этому она может быть лишней. Тем самым создать строгость, типизировать. Зато ты точно будешь уверен, что там ничего лишнего не придет. И задачу ты облегчишь, и данные пере-привести сможешь в любой момент.
Тебе да... А представь что твой метод говорит что там 123, а мой говорит что там строка длинной в 14 символов, а третий метод смотрит и офигевает от нашей математики !!!! Добавлено спустя 55 секунд: Её ограничивает только математика, и ограничение это от минус бесконечность, до плюс бесконечность... Добавлено спустя 5 минут 45 секунд: А в GET/POST только целые числа идут ? т.е если идёт число, то оно обязательно целое ? У меня на роутере такая фигня, какой-то умник написал такую привязку к целому, в результате у меня за месяц трафика менее 2 гигов в статистике, а я в день бывает по 20 гигов качаю... Добавлено спустя 1 минуту 32 секунды: А после моей проверки я не буду уверен ?
Я вижу единственный смысл в этом - избавиться от дублей страниц (типа для поисковиков). Ну то есть если вдруг кто-нибудь возьмёт и понаставит в интернетах кучу неправильных ссылок на сайт - типа http://www.site.ru/index.php?mode=articles&page=12asdasd http://www.site.ru/index.php?mode=articles&page=12zxczxc http://www.site.ru/index.php?mode=articles&page=12qweqwe При обычном (int) в принципе, сайт по любой из этих ссылок выдаст одинаковый контент, что, возможно, плохо скажется на отношении поисковиков к нему. Хотя я не знаю, это просто предположение, что так может быть. А может и наоборот - гугл скажет "Ух ты, сколько ссылок на http://www.site.ru - это, наверно, хороший сайт, раз его везде цитируют!" В общем, спорный вопрос. Возможно, в ответ на page=12asdasd стоит отдавать 404 страницу. Добавлено спустя 1 минуту 48 секунд: Другого смысла в том, чтобы использовать проверку вместо приведения к (int) - я не вижу. При этом приведение к инту - удобнее лично для меня.
Ты подумай логически. Код (PHP): $a; // Notice. будет в else{} $a=''; // будет в else{} $a=""; // будет в else{} $a=' '; // будет в else{} $a="\n"; // будет в else{} $a=null; // будет в else{} $a=false; // будет в else{} $a=0; // будет в else{} if(trim($a)) { } Если ты о проверках без вредных. Нам останется только привести к типу и не марочиться.) И какую нужно процедуру провести и в каком месте как нужно это решить уже привидениями и другими функциями... Конечно, условия, проверки некоторые соблюдать нужно и можно, этого никто не запрещает, но лишний раз вызывать функции!? Кому, как вообщем! Иногда если там конкретное решение, конечно лучше сделать проверку, до... А вот когда там много разных связей, то лучше не париться. Лишние условия никому не нужны. Ну можно и так решать, что надо: Код (PHP): if(trim($a) || false===$a) { }
Все равно надо считать целые, потому что дроби приведут к неточностям. Как раз тот случай, когда надо считать байты, в 64-битном INT x)
Код (PHP): echo (int) ( (0.1+0.7) * 10 ); // выводит 7! Разрабы PHP не хотят хитрить, честно отдают машине сконверить, как она может, не округляя. После умножения 0.8 (а может и 0.7999999999999998) на 10 получилось что-то вроде 7.99999999999998, далее приведение к int оставляет только целую часть числа. И никакой проверки на исходную разрядность числа, просто "0.1" парсится и конвертится в 0.09999999999 во внутреннем представлении.
Числа с дробной частью это отдельная песня. Там никогда нет никаких гарантий ни в чем. Так уж работают современные компы.
Короче почитал я это и решил делать проверку на число регуляркой... А почему бы не убить двух зайцев одним выстрелом? Я например не делаю проверку на число в самом SQL-запросе, я делаю её перед запросом. Код (PHP): if (!preg_match("^[0-9]$",$string)) { error_message('Попытка взлома', 'Оставайтесь на месте, за вами уже выехали'); die; }
Потому что зачем тебе число, если ты не сможешь с ним работать? Если это ЧИСЛО, то ты должен быть уверен, что оно уместится в нужный тип, чтобы ты мог с ним работать как с числом. Если это циферная строка, то проверяй регуляркой, но не относись к ней, как к числу.
А если у тебя в БД bigint а ты его обрежешь ? И если оно наоборот не умещается, то это неправильное число, зачем его обрезанным в базу пихать ? Полностью согласен, так и надо.
[vs], Да это все, это законченно для этих человеков =), тут резону объяснять нет, надо походу сразу с ходу в лобешник. =) Да конечно, делай все регулярками и потребляй больше ресурсов. Ты на верном пути чувак, продолжай в том же духе. Сделай весь свой говно двиг в регулярках и выброси его в корзину. Ты такую х уйню говоришь, что просто пздц. Большие числа считаются float. Это рас. Под BIGINT отводится 8 байт. Больше 2^64 значений всё равно влепить не удастся. Это два. http://pear.php.net/package/Math_BigInteger/docs/latest/li_ ... teger.html И в третьих если нужно такие прям большие числа Читай тут php.net/manual/ru/refs.math.php. Это три. А, то, что вы тут заносите, проверки не нужны и т.д., руки за это отшибают. Вам это не говорят чутьли не каждую переменную приводить. Вы толи тему не читаете, толи не врубаетесь, что говорят, третьего не дано.
Да ничего он не будет в таких случаях приводить. Он отдаст как есть, так как это число большое для int. Как уже выше пост сказан, он приведет, да если отправим в int но число будет 2+ миллиарда не больше. Большие числа не желательно использовать, может возникнуть недразумение. А приведение типов желательно использовать для типизаций, чтобы явное приведение было, а не динамическое. Динамика может быть не верной. Было у меня много случаев, иначе бы я просто так не говорил бы.
У тебя столбец bigint тебе надо на 32 битной системе закинуть в базу число 99999999999999999 Ты пишешь $num = (int)$_GET итд (как все тут предлагают) и что ???? Вы похоже не понимаете о чём я и пишете о своём чём-то...
Vladson, Если будет bigint - то приводить к int, конечно же, не будем. В случае, когда в базе bigint - будем использовать другие функции для обработки данных. Просто на практике - я не помню ни единого случая, чтобы я использовал bigint. Всегда обычного int более чем достаточно.
Учитывая что BIGINT - это пресловутые 64 бит, об этом "недостатке" конструкции (int) все скоро забудут.
Может, но в этом топике никто не говорит этого, все пишут что пишут инт "всегда где числа" О магических кавычках хотели забыть ещё в 2004-м году, но до сих пор они актуальны и надо проверять включены ли они... Добавлено спустя 1 минуту 31 секунду: Почему их не использовать сразу ? Хотя бы на тот случай если завтра не появится какой нибудь суперпуперинт на 100500бит ? что любопытно варианты есть и были ещё в РНР3 Или так нравится каждый раз переписывать код под каждую новую версию ?