ivan386, видимо, из-за того, что когда реализацию JS писали, 64-битных процессоров ещё не существовало. А так-то JS сплошь и рядом состоит из костылей, эмулирующих ошибки первого JS-интерпретатора, потому и ограничение в 32 бит для сдвига - тоже портировали судя по всему, дабы не сломать совместимость. Либо в угоду независимости от платформы - дабы и в 32-битных и в 64-битных браузерах код возвращал один и тот же результат.
Точно также, к примеру, операция | 0 (межбитовое или с нулём) приводит переменную к 32-разрядному целому числу, тупо отсекая старшие биты, если они не влазят в 32 бита.
Максим Шадрин, могу ещё предположить, что хром синхронизировал некоторые вирусы на сервер и при синхронизации обратно - подтягивает их. Либо вы не все вирусы почистили. Антивирусы далеко не 100% решение.
Rsa97, по-моему, подобная гадость была ещё в IE4. Но вот современные браузеры - да, портировали подобное говноповедение не сразу, а начиная с какого-то времени.
Verolomstvo, filter_has_var проверяет именно существование (возвращает true/false), а filter_input - и существование проверяет, и возвращает отфильтрованное значение (в случае существования).
Автору потом нужно эту переменную сравнить с двумя возможными значениями, потому оптимальнее - сразу использовать filter_input и не городить лишний код.
Для Atom кстати есть плагин, позволяющий прямо в редакторе переключать ветки, делать коммиты и пушить, не переключаясь ради этого в консоль (а также отображает изменённые но незакомиченные файлы в боковой панели другим цветом) - само собою, возможностей плагина намного меньше, чем у командной строки, но основные функции выполнить за пару кликов позволяет.
Но минус большого cost в том, что на вычисление хэша одного пароля будет затрачено больше процессорного времени, в результате если одновременно в систему будет входить сотня человек - сервер подвиснет, пока все эти хэши сосчитает.
Достаточно разрешить 10 неудачных попыток за 5 минут блокировки (без увеличения интервала), и через это бутылочное горлышко будет крайне трудно подобрать, а 10 раз пытаться вбить неправильный пароль и надеяться его вспомнить - нужно быть отчаянным.
Или не блокировать на 5 минут, а после 10 неудачных попыток просто показывать капчу (автоматически её снимать через 5 минут после последней попытки например)
Александр, ещё мне недавно очень пригодилось с размерами, когда дали макет в фотошопе, где всё было в пикселях, а надо было отмасштабировать в процентах, там я вместо того, чтобы проценты считать, просто задавал величины наподобие width: 120 * $scale (где 120 это величина в макете в пикселях, а $scale равнялось 100vw, делённых на ширину макета).
hckn, чаще всего отдельно генерировать соль не имеет смысла, обычно функция сама генерирует рандомную соль, если никакую ей не задавать. Читайте документацию, там обычно написано, с какими параметрами вызывать, чтобы получить случайную соль
А менять значение соли для уже сгенерированного хэша - не вижу случаев, когда это может понадобиться. При утечке хэшей для каждого солёного хэша подбирать пароль придётся всё равно индивидуально (в отличие от несолёных хэшей, которые можно подобрать для всех сразу) - потому разницы никакой не будет, какая именно соль там, важно только, чтобы они были достаточно случайными и не повторялись (но и если случайно повторится 2-3 соли - это не смертельно, просто злоумышленник эти конкретные 2-3 пароля сможет подбирать вместе, что чуточку ему облегчит задачу, но не сильно). А если хэш утёк, то поможет разве что смена самого пароля, а не соли (к тому моменту, как злоумышленник вычислит старый, если ему хватит на это вычислительной мощности - этот пароль уже не будет подходить).
hckn, нет смысла. Во всяком случае можете проверить, если без отдельного задания соли будет работать функция проверки хэша (возвращать true на правильном пароле и false на неправильном) - то отдельно задавать соль бессмысленно.
longclaps, я имею ввиду, не стоит вручную резолвить адреса объектов и каким-нибудь образом полагаться на них, например, сравнивать их. В случае с оператором is то понятное дело, что объекты по обе стороны живы на время его вызова
Boris19, тогда исходники Питона в руки и смотрите, где и как происходит выделение памяти и почему в разных случаях по-разному.
Но вообще - на адреса памяти никогда не следует полагаться, что они будут те или иные, они могут быть в общем-то довольно произвольными, полагаться можно только на то, что если объект жив - он будет доступен по тому адресу, где он лежит (но только на этот момент исполнения программы, в следующий раз он может быть другим, а может быть и таким же, а если объект сдох - то тот же адрес может впоследствии быть назначен другому объекту, а может больше и не быть никому назначен и там будет лежать "труп" старого объекта)
Точно также, к примеру, операция | 0 (межбитовое или с нулём) приводит переменную к 32-разрядному целому числу, тупо отсекая старшие биты, если они не влазят в 32 бита.