считать всё корректно для уникода (и особенно для UTF-8) чуть менее просто.
Тут зависит от реализации. Для раста можно заменить итератор по bytes на итератор по chars и получить всё то же самое и без особой просадки производительности.
А на php с кем-то предложенным тут mb_substr это будет уже O(n⁴), потому что для взятия каждого следующего символа надо будет пробежать по всей строке.
У достаточно большого, не статический, но внешний.
Не могу сейчас найти, но был даже публичный сервис, который предлагал всем желающим ssh-нуться к ним и показывал проблемы и уязвимости вашего клиентсвкого конфига. Они как раз статистику собирали.
В очень большом проценте случаев этого достаточно, чтобы, воспользовавшись агентом, добраться до машины пользователя (где этот же ключ лежит в authorized_keys) и дальше с правами пользователя выполнить что угодно:
— стянуть приватный ключ, если он не запаролен
— прописать свой ключ в authorized_keys и ходить на пользовательскую машину пользоваться уже локальным агентом
— запустить любые туннели или сервисы
В РФ таможенная пошлина для товаров бытового назначения, полученных из заграничных интернет-магазинов, платится просто на почте при получении посылки. Никуда идти не нужно.
Так только если продавец отправляет товар обычной почтой. Если какой-нибудь более быстрой службой — всё будет уже интереснее.
(Что инетерсно тот товарищ, который source-map делает он даже написал собственный аллокатор памяти для WASM — потому что встроенный в Rust был слишком большой… ну у меня даже слов нет.)
Не знаю про ту ситуацию и не очень в курсе, как это всё работает в WASM, но возможно он просто не захотел разбираться: в расте по умолчанию используется достаточно жирный jemalloc, но вообще при компиляции можно попросить использовать обычный системный аллокатор.
Я скорее про затраты на поддержание. Легко говорить о сложностях сборки, когда сам всеми силами их избегаешь и правишь итоговый результат :)
А если честно собирать и то, и другое, то вроде так на так и выходит, наверное.
Тут надо быть немного осторожнее с утверждениями, потому что ещё в XVIII-XIX вв. свежевошедшие в язык слова «офици[н]альный», «офис» и другие писались и так, и сяк, в том числе и с двумя «ф» :) Поэтому если говорить о традиции, то там всё немного сложно.
Ну не странно ли, учитывая явно слышимое Э и иностранное происхождение слова?
Иностранные слова со звуком [э] очень часто заимствуются в русский с буквой «е» в написании: «претензия», «секс», «бутерброд». «э» пишется чаще либо в начале слова («эхо»), либо в сочетаниях с гласными («маэстро»), либо для устранения неоднозначности («мэтр»/«метр»). Впрочем, исключений в обе стороны тонны и правописание конкретно «флешки» обсуждаемо. Поиск говорит о трёхкратном превосходстве варианта «флешка» (81 млн результатов против 27 млн у «флэшка»).
Да, и он работает так же, как работают абсолютно все: генерируем си-враппер, подключаем его через FFI.
Таким способом невозможно использовать шаблоны, кроме явно инстанцированных (ещё вероятно можно вручную попросить инстанцировать нужные специализации, но в описании я ничего такого не нашёл).
А ещё это будет очень весело работать с обёрнутым #ifdef-ами кодом: чтобы правильно сгенерировать обёртку к библиотеке, надо (как-то) выставить все те же дефайны, с которыми она собиралась, т.е. любую библиотеку из системного репозитория придётся фактически пересобирать, т.е. мы всё-таки начинаем кроме раста и обёртки компилировать ещё и плюсовый код. И если у нас есть библиотека, обмазанная autotools, то потребуется: autotools для библиотеки, cmake для cpp_to_rust, и cargo для сборки всего воедино — три билд-системы.
Вообще довольно странно выглядит требование работать с библиотеками на C++, учитывая то, что никто не может работать с библиотеками на C++ (даже C++):
В стандарте так и не зафиксировано, как должны выглядеть символы для классов, методов, инстанцированных шаблонов, мэнглинг может различаться в зависимости от компилятора, языка, архитектуры, чего угодно. В windows нельзя из собранного студией кода использовать dll, собранный mingw, и наоборот. Как этим должен пользоваться внешний инструмент?
Шаблоны в С++, которые хочет автор, существуют только в заголовочных файлах. Долгая затея с экспортируемыми шаблонами, введённая в 98-м стандарте, провалилась, поддержать их за десять лет смог ровно один компилятор Comeau, и в C++11 их из стандарта выкинули. Сейчас затею пытаются повторить с модулями, но чем это всё кончится, пока непонятно. Поэтому единственный способ их поддержать — самому стать компилятором C++-кода, чтобы обрабатывать заголовочные файлы с шаблонами. Затея, изначально обречённая на провал.
Всё просто, либо вы тащите с собой этот патч до скончания веков — накладываете его на новые версии библиотеки, чините мерж-конфликты — либо держите устаревшую версию с возможными багами, уязвимостями и проблемами совместимости с новыми системами, героически превозмогая ещё и это.
Обычно хорошие разработчики стараются всего этого избежать, поэтому пропихивание патча в апстрим решает чисто ваши собственные проблемы.
Тут зависит от реализации. Для раста можно заменить итератор по bytes на итератор по chars и получить всё то же самое и без особой просадки производительности.
А на php с кем-то предложенным тут mb_substr это будет уже O(n⁴), потому что для взятия каждого следующего символа надо будет пробежать по всей строке.
Вот так, читая про духовку, я узнал, как чинить свой холодильник)
Не могу сейчас найти, но был даже публичный сервис, который предлагал всем желающим ssh-нуться к ним и показывал проблемы и уязвимости вашего клиентсвкого конфига. Они как раз статистику собирали.
— стянуть приватный ключ, если он не запаролен
— прописать свой ключ в authorized_keys и ходить на пользовательскую машину пользоваться уже локальным агентом
— запустить любые туннели или сервисы
Так только если продавец отправляет товар обычной почтой. Если какой-нибудь более быстрой службой — всё будет уже интереснее.
И этот большой аллокатор написан авторами wasm32-unknown-emscripten-тулчейна, понятно.
Не знаю про ту ситуацию и не очень в курсе, как это всё работает в WASM, но возможно он просто не захотел разбираться: в расте по умолчанию используется достаточно жирный jemalloc, но вообще при компиляции можно попросить использовать обычный системный аллокатор.
А если честно собирать и то, и другое, то вроде так на так и выходит, наверное.
Но ведь если я правильно понял статью, Вы тоже напрямую редактировали сгенерированный код, чтобы не возиться с пересборкой?
Иностранные слова со звуком [э] очень часто заимствуются в русский с буквой «е» в написании: «претензия», «секс», «бутерброд». «э» пишется чаще либо в начале слова («эхо»), либо в сочетаниях с гласными («маэстро»), либо для устранения неоднозначности («мэтр»/«метр»). Впрочем, исключений в обе стороны тонны и правописание конкретно «флешки» обсуждаемо. Поиск говорит о трёхкратном превосходстве варианта «флешка» (81 млн результатов против 27 млн у «флэшка»).
Таким способом невозможно использовать шаблоны, кроме явно инстанцированных (ещё вероятно можно вручную попросить инстанцировать нужные специализации, но в описании я ничего такого не нашёл).
А ещё это будет очень весело работать с обёрнутым #ifdef-ами кодом: чтобы правильно сгенерировать обёртку к библиотеке, надо (как-то) выставить все те же дефайны, с которыми она собиралась, т.е. любую библиотеку из системного репозитория придётся фактически пересобирать, т.е. мы всё-таки начинаем кроме раста и обёртки компилировать ещё и плюсовый код. И если у нас есть библиотека, обмазанная autotools, то потребуется: autotools для библиотеки, cmake для cpp_to_rust, и cargo для сборки всего воедино — три билд-системы.
Вообще довольно странно выглядит требование работать с библиотеками на C++, учитывая то, что никто не может работать с библиотеками на C++ (даже C++):
Обычно хорошие разработчики стараются всего этого избежать, поэтому пропихивание патча в апстрим решает чисто ваши собственные проблемы.
Зависть. Понимаю, что опыт и фантазия, но всё равно зависть.