UB используется для оптимизаций, но это не значит, что для оптимизаций нужно UB. какие там инструкции на разных платформах будут генерироваться не подскажу, не знаю, с точки зрения программиста и кода программы оператор + на всех платформах сделает одно и тоже.
Ну это же настоящий межплатформенный UB, на одной платформе получим одно, на другой - другое
А вот тут стоп, это очень важно. Далеко не каждое "плохое", "не очевидное", "странное", " вредное" и т.д. поведение является неопределенным. У вам вообще оксюморон получился, определенное (если на платформе А выполняется Х, а на платформе Б выполняется У, то поведение очень даже определено) неопределенное поведение. Это было бы platform dependent behavior (или implementation-defined behavior, я не уверен, я не программирую на C++). А еще есть unspecified behavior и compiler specific behavior. И это все разные сорта грабель на любой вкус и цвет. Про UB в комментариях под этой статьей много кто много чего полезного рассказал, можно их посмотреть. Еще в комментариях под моей статьей тоже много про это писали, там тоже можно много полезного узнать.
Да и разные инструкции процессору при разных обстоятельствах даже implementation-defined behavior, если компилятор вместо простого сложения чисел в цикле сразу на этапе компиляции это вычислит и оставит от функции только ret 100 это же не UB. С точки зрения программы это эквивалентно, результат то один и тот же.
добавить лишних инструкций на другой платформе
Опять же, не готов тут что-то сказать, понятия не имею что может быть на разных платформах. Нo в Rust числа не только оператором + складывать можно, есть еще пачка методов, типа checked_add, overflowing_add, saturating_add, unchecked_add, wrapping_add, wrapping_add_unsigned, а если этого мало, то есть еще интринсики, в которых (возможно, я не проверял) можно прям нужные инструкции +- напрямую использовать. Так что если хочется под конкретную платформу заоптимизироваться, то в этом никаких проблем нет.
А что, добавить в радиатор системы водяного охлаждения второй контур для чистой воды и можно не вставая из-за стола готовить себе чай, причем как раз пока что-то рендерится/вычисляется, делать все равно нечего, можно и чаю попить)
Так в этом и проблема, что не "тот же самый". x + 1 < x в C и C++ не определено и компилятор может с чистой совестью весь код в соответствующей ветке if удалить (и не только удалить, программа с UB это вообще не программа и гарантированного поведения не имеет) т.к. он недостижим, ведь по стандарту переполнение - это ошибка и UB. В Rust же это как раз таки определено и компилятор такой фигни сделать не может. Т.е. оно может работать не так, как ожидалось и хотелось, но это не UB и можно на 100% понимать, что на самом деле произойдет.
Я же не говорил, что надо выбрать какой-либо вариант и сделать его единственно возможным и все. Я говорил только о том, чтобы сделать поведение определенным, чтобы оптимизатор не мог по велению левой пятки выкидывать (или не выкидывать, или еще что угодно делать) код проверок на переполнение. И из-за этого жизнь становится проще, не надо отключать оптимизации из-за боязни того, что где-то что-то может как-то не так заработать. Просто для другого поведения можно использовать не +, а метод или функцию, если это необходимо.
Как определить Null pointer dereference
Воспользоваться системой типов для того, чтобы такое отлавливалось бы компилятором.
Словом, «И нашим, и вашим» — не получится
Вариант «ну что-то произойдет, может быть то, что тебе надо» точно работает очень плохо.
вряд ли ему следует лезть в C или Rust
В Rust то как раз очень даже можно, ни одной из вышеперечисленных проблем в Rust нет. Т.е. да, можно получить неожиданное переполнение и программа будет работать неправильно, но это дырой неопределенного размера не будет.
Например, из языка C надо выкинуть операцию сложения
Можно же "просто" (понятное дело не в C, а вообще) определить переполнение и не использовать то, что переопределение не определено (т.к. оно определено) в оптимизациях. И все, проблемы (не все проблемы вселенной, а UB) заканчивается и жить становится сильно проще.
Не надо думать, что разработкой будут заниматься олигофрены с тремя классами церковно-приходской школы за плечами
К слову о токсичности, это, видимо, как раз пример не токсичности. А вот статьи и комментарии, что Rust во многих аспектах лучше языка X это да, прям токсичная токсичность, и как только люди это терпят, это же гораздо хуже, чем других олигофренами называть.
Могу это подтвердить, сейчас пишу свой проект используя windows 7 (rustc 1.77.1 (7cf61ebde 2024-03-27)). Причем при компиляции используется не вышеупомянутый таргет, а обычный x86_64-pc-windows-msvc, из-за чего у меня в одной библиотеке не сработал cfg на этот таргет и ничего не работало.
Насколько я помню, дожитие людей до старости (уже сильно после репродуктивного возраста) было очень даже эволюционным преимуществом т.к. они помогали ухаживать за внуками.
Может быть в какой-то конкретной реализации, насколько я понимаю в общем случае это просто количество итераций.
DK = PBKDF2(PRF, Password, Salt, c, dkLen); c is the number of iterations desired
Да и даже если так, за 23 года это количество увеличилось на 2 порядка, увеличение на 1 явно не хватит на "ещё пару ближайших столетий".
Чтобы подбирать 1234, надо точно знать что там хотя бы одни цифры
Начинают как раз с паролей с наименьшей энтропией. Сначала словарные, потом только числа, только строчная латиница и т.д. Даже если повезет, что конкретно этот цифровой пароль в миллионе самых популярных паролей не окажется (а 1234 там в первой двадцатке стабильно), он все равно первый на подбор.
Такие пароли небезопасны, потому что их надо где-то хранить, со всеми из этого вытекающими
Менеджеры паролей придуманы уже очень давно. Даже в режиме параноика (не хранить пароли в облаке (любом), никакой автосинхронизации, нет автозаполнения и т.д.) это все равно удобнее, чем самому этими паролями управлять. Я даже маму свою на keepass подсадил, ничего сложного или неудобного тут нет. При этом это на много порядков безопаснее (как в смысле каждого отдельного пароля, так и того, что каждый пароль уникален и утечка пароля от одного сервиса не влияет на доступы к другим).
When the standard was written in the year 2000 the recommended minimum number of iterations was 1,000, but the parameter is intended to be increased over time as CPU speeds increase. A Kerberos standard in 2005 recommended 4,096 iterations; Apple reportedly used 2,000 for iOS 3, and 10,000 for iOS 4; while LastPass in 2011 used 5,000 iterations for JavaScript clients and 100,000 iterations for server-side hashing. In 2023, OWASP recommended to use 600,000 iterations for PBKDF2-HMAC-SHA256 and 210,000 for PBKDF2-HMAC-SHA512.
И если увеличивать его не с такой же скоростью, как растет скорость вычислений, то, соответственно, увеличится время хеширования. Думаю мало кому понравится ждать логина пару минут (а то и пару часов) чтобы его пароль 1234 был настолько же безопасен, как и kz~:1yIf0ES_s1oG'6Js.
Скорость поиска коллизии можно увеличивать практически до бесконечности
Как раз скорость поиска очень даже ограничена (вычислительными мощностями всей планеты), а вот сложность пароля практически не ограничена. Сейчас будет сравнение апельсинов с карьерным самосвалом, но для увеличения скорости подбора в 2 раза надо либо в 2 раза больше железа (что дорого), либо ждать несколько лет пока индустрия выпустит новое, более мощное (или более эффективное в производительности за рубль) железо. А время подбора можно увеличить в n раз (n - размер словаря) просто добавив 1 символ. Что-то мне подсказывает, что сделать пароль чуть длиннее сильно проще.
Для современных криптографических хеш-функций найти коллизию сложнее, чем подобрать пароль адекватной длины. Для Argon2нужно перебрать 2^256 вариантов. Это, конечно, не 10^100, но 10^77 тоже неплохо.
Ну так это и есть скорость. И комбинация длинного пароля, соли и ресурсоемкого хеша делает невозможным как взлом конкретного пароля, так и создание радужных таблиц для перебора сразу всех.
Так для этого и нужен длинный пароль, чтобы каждым хешем надо было заниматься отдельно, а не за пару часов перебрать всю базу в сотню-другую тысяч пользователей. Мне кажется логичным, что надо предполагать, что взломщик как-то в этом заинтересован и ломает не на core2duo (или даже epyc или xeon), а как минимум на пачке видеокарт, что увеличивает скорость даже не знаю на сколько порядков.
На количество одноразовых паролей в единицу времени тоже обычно ставят ограничение (еще и потому, что сервису надо платить за каждую смску), реальный человек за минуту 100 одноразовых паролей не запросит. Больше 5 одноразовых паролей на операцию - подожди час, выглядит подозрительно.
UB используется для оптимизаций, но это не значит, что для оптимизаций нужно UB. какие там инструкции на разных платформах будут генерироваться не подскажу, не знаю, с точки зрения программиста и кода программы оператор
+на всех платформах сделает одно и тоже.А вот тут стоп, это очень важно. Далеко не каждое "плохое", "не очевидное", "странное", " вредное" и т.д. поведение является неопределенным. У вам вообще оксюморон получился, определенное (если на платформе А выполняется Х, а на платформе Б выполняется У, то поведение очень даже определено) неопределенное поведение. Это было бы platform dependent behavior (или implementation-defined behavior, я не уверен, я не программирую на C++). А еще есть unspecified behavior и compiler specific behavior. И это все разные сорта грабель на любой вкус и цвет. Про UB в комментариях под этой статьей много кто много чего полезного рассказал, можно их посмотреть. Еще в комментариях под моей статьей тоже много про это писали, там тоже можно много полезного узнать.
Да и разные инструкции процессору при разных обстоятельствах даже implementation-defined behavior, если компилятор вместо простого сложения чисел в цикле сразу на этапе компиляции это вычислит и оставит от функции только
ret 100это же не UB. С точки зрения программы это эквивалентно, результат то один и тот же.Опять же, не готов тут что-то сказать, понятия не имею что может быть на разных платформах. Нo в Rust числа не только оператором
+складывать можно, есть еще пачка методов, типа checked_add, overflowing_add, saturating_add, unchecked_add, wrapping_add, wrapping_add_unsigned, а если этого мало, то есть еще интринсики, в которых (возможно, я не проверял) можно прям нужные инструкции +- напрямую использовать. Так что если хочется под конкретную платформу заоптимизироваться, то в этом никаких проблем нет.Не обязательно, можно поставить вторым контуром тепловой насос и так греть что угодно до нужной температуры. Так что все возможно, было бы желание)
А что, добавить в радиатор системы водяного охлаждения второй контур для чистой воды и можно не вставая из-за стола готовить себе чай, причем как раз пока что-то рендерится/вычисляется, делать все равно нечего, можно и чаю попить)
Так в этом и проблема, что не "тот же самый".
x + 1 < xв C и C++ не определено и компилятор может с чистой совестью весь код в соответствующей веткеifудалить (и не только удалить, программа с UB это вообще не программа и гарантированного поведения не имеет) т.к. он недостижим, ведь по стандарту переполнение - это ошибка и UB. В Rust же это как раз таки определено и компилятор такой фигни сделать не может. Т.е. оно может работать не так, как ожидалось и хотелось, но это не UB и можно на 100% понимать, что на самом деле произойдет.Можно сделать указатель (это не ссылка, которым тоже запрещено быть нулевыми), который не может быть нулевым и использовать уже его.
Я же не говорил, что надо выбрать какой-либо вариант и сделать его единственно возможным и все. Я говорил только о том, чтобы сделать поведение определенным, чтобы оптимизатор не мог по велению левой пятки выкидывать (или не выкидывать, или еще что угодно делать) код проверок на переполнение. И из-за этого жизнь становится проще, не надо отключать оптимизации из-за боязни того, что где-то что-то может как-то не так заработать. Просто для другого поведения можно использовать не
+, а метод или функцию, если это необходимо.Воспользоваться системой типов для того, чтобы такое отлавливалось бы компилятором.
Вариант «ну что-то произойдет, может быть то, что тебе надо» точно работает очень плохо.
В Rust то как раз очень даже можно, ни одной из вышеперечисленных проблем в Rust нет. Т.е. да, можно получить неожиданное переполнение и программа будет работать неправильно, но это дырой неопределенного размера не будет.
Можно же "просто" (понятное дело не в C, а вообще) определить переполнение и не использовать то, что переопределение не определено (т.к. оно определено) в оптимизациях. И все, проблемы (не все проблемы вселенной, а UB) заканчивается и жить становится сильно проще.
Так раз оно не нужно, то зачем оно можно?
К слову о токсичности, это, видимо, как раз пример не токсичности. А вот статьи и комментарии, что Rust во многих аспектах лучше языка X это да, прям токсичная токсичность, и как только люди это терпят, это же гораздо хуже, чем других олигофренами называть.
Могу это подтвердить, сейчас пишу свой проект используя windows 7 (rustc 1.77.1 (7cf61ebde 2024-03-27)). Причем при компиляции используется не вышеупомянутый таргет, а обычный
x86_64-pc-windows-msvc, из-за чего у меня в одной библиотеке не сработалcfgна этот таргет и ничего не работало.Да и судя по этому комментарию все не так плохо.
А откуда вы знаете, может это у него брачные игры такие)
Насколько я помню, дожитие людей до старости (уже сильно после репродуктивного возраста) было очень даже эволюционным преимуществом т.к. они помогали ухаживать за внуками.
Может быть в какой-то конкретной реализации, насколько я понимаю в общем случае это просто количество итераций.
Да и даже если так, за 23 года это количество увеличилось на 2 порядка, увеличение на 1 явно не хватит на "ещё пару ближайших столетий".
Начинают как раз с паролей с наименьшей энтропией. Сначала словарные, потом только числа, только строчная латиница и т.д. Даже если повезет, что конкретно этот цифровой пароль в миллионе самых популярных паролей не окажется (а
1234там в первой двадцатке стабильно), он все равно первый на подбор.Менеджеры паролей придуманы уже очень давно. Даже в режиме параноика (не хранить пароли в облаке (любом), никакой автосинхронизации, нет автозаполнения и т.д.) это все равно удобнее, чем самому этими паролями управлять. Я даже маму свою на keepass подсадил, ничего сложного или неудобного тут нет. При этом это на много порядков безопаснее (как в смысле каждого отдельного пароля, так и того, что каждый пароль уникален и утечка пароля от одного сервиса не влияет на доступы к другим).
За 20 лет в 600 раз увеличили
И если увеличивать его не с такой же скоростью, как растет скорость вычислений, то, соответственно, увеличится время хеширования. Думаю мало кому понравится ждать логина пару минут (а то и пару часов) чтобы его пароль
1234был настолько же безопасен, как иkz~:1yIf0ES_s1oG'6Js.Как раз скорость поиска очень даже ограничена (вычислительными мощностями всей планеты), а вот сложность пароля практически не ограничена. Сейчас будет сравнение апельсинов с карьерным самосвалом, но для увеличения скорости подбора в 2 раза надо либо в 2 раза больше железа (что дорого), либо ждать несколько лет пока индустрия выпустит новое, более мощное (или более эффективное в производительности за рубль) железо. А время подбора можно увеличить в n раз (n - размер словаря) просто добавив 1 символ. Что-то мне подсказывает, что сделать пароль чуть длиннее сильно проще.
1234на 16-ом месте по популярности в 2023 году, кстати.Для современных криптографических хеш-функций найти коллизию сложнее, чем подобрать пароль адекватной длины. Для Argon2 нужно перебрать 2^256 вариантов. Это, конечно, не 10^100, но 10^77 тоже неплохо.
Ну так это и есть скорость. И комбинация длинного пароля, соли и ресурсоемкого хеша делает невозможным как взлом конкретного пароля, так и создание радужных таблиц для перебора сразу всех.
Так для этого и нужен длинный пароль, чтобы каждым хешем надо было заниматься отдельно, а не за пару часов перебрать всю базу в сотню-другую тысяч пользователей. Мне кажется логичным, что надо предполагать, что взломщик как-то в этом заинтересован и ломает не на core2duo (или даже epyc или xeon), а как минимум на пачке видеокарт, что увеличивает скорость даже не знаю на сколько порядков.
На количество одноразовых паролей в единицу времени тоже обычно ставят ограничение (еще и потому, что сервису надо платить за каждую смску), реальный человек за минуту 100 одноразовых паролей не запросит. Больше 5 одноразовых паролей на операцию - подожди час, выглядит подозрительно.