The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Уязвимость в Rust-библиотеках для формата TAR, приводящая к распаковке файлов из вложенного архива

21.10.2025 23:04

В написанной на языке Rust библиотеке async-tar, предоставляющей функции для чтения и записи tar-архивов, выявлена уязвимость (CVE-2025-62518, кодовое имя TARmageddon), позволяющая при распаковке специально оформленного tar-архива не только извлечь размещённые в нём файлы, но и файлы, содержащиеся во вложенном tar-архиве. Уязвимость может быть использована для обхода систем верификации архивов и распаковки файлов, для которых не выполнялась проверка.

Уязвимость также проявляется в форках библиотеки async-tar, таких как tokio-tar, krata-tokio-tar и astral-tokio-tar, а также в утилитах на их основе, например, в пакетном менеджере uv, развиваемом в качестве высокопроизводительной замены "pip" для проектов на языке Python. Из популярных проектов, использующих уязвимые библиотеки, также отмечаются инструментарий testcontainers для запуска docker-контейнеров и WebAssembly runtime wasmCloud. В репозитории crates.is за последние 90 дней библиотека async-tar насчитывает 1.3 млн загрузок, tokio-tar - 2.2 млн, testcontainers - 2.9 млн.

Уязвимость вызвана некорректным выбором позиции в потоке при разборе разных значений размера в заголовках ustar и PAX. В tar-архивах в формате PAX для каждого файла внутри архива указываются два заголовка - классический ustar и расширенный PAX. Проблема вызвана тем, что уязвимые библиотеки при распаковке файлов вместо вычисления смещения на основе размера из расширенного заголовка PAX, брали размер из устаревшего заголовка ustar. При нулевом значении размера в заголовке ustar, идущее за ним содержимое файла обрабатывалось как корректный блок TAR-заголовков для следующего файла.

Для совершения атаки достаточно создать TAR-архив, в котором в ustar-заголовке указан нулевой размер, а в заголовке для формата PAX актуальный размер, из-за чего содержимое файла с другим tar-архивом будет обработано как часть основного архива. Пример кода для создания подобных архивов размещён на GitHub. Уязвимость устранена в выпусках tokio-tar 0.5.6 и uv 0.9.5. Для остальных библиотек исправления пока не опубликованы, но для astral-tokio-tar, async-tar и krata-tokio-tar отдельно подготовлены патчи.

Уязвимости в библиотеках присвоен уровень опасности 8.1 из 10, так как проблема может использоваться для перезаписи распаковываемых файлов (в уязвимых реализациях будут распакованы не те файлы, что были видны в архиве). При этом уязвимость в пакетном менеджере uv отмечена как неопасная, так как если атакующий может влиять на содержимое исходного архива, нет смысла усложнять атаку и эксплуатировать уязвимость через вложенный архив, когда можно добиться выполнения кода через сборочные сценарии в основном архиве.

Выявившие уязвимость исследователи предложили несколько гипотетических сценариев атак, позволяющих обойти проверки безопасности и добиться выполнения кода через замену файлов конфигурации или вмешательство в сборочный процесс. Подразумевается, что присланный архив сможет пройти автоматизированную проверку сканером безопасности и ручной аудит, в ходе которого проверяющий не обратит внимание на странный вложенный архив с другими файлами, после чего при распаковке при помощи Rust-библиотек из архива будет извлечено иное содержимое, чем ожидалось.

Например, атакующий может загрузить модифицированный архив в репозиторий PyPI, который пройдёт проверку на основе анализа содержимого основного архива, содержащего легитимный файл pyproject.toml. При обработке данного пакета при помощи утилиты uv легитимный pyproject.toml будет заменён на вредоносный вариант из вложенного архива, содержащий команды, которые будут выполнены при сборке на компьютере разработчика или в системе непрерывной интеграции. Аналогично, можно организовать перезапись файлов контейнера при извлечении образа контейнера при помощи инструментария testcontainers.

  1. Главная ссылка к новости (https://edera.dev/stories/tarm...)
  2. OpenNews: Уязвимости в tar-fs и 7-Zip, позволяющие записать файлы за пределы базового каталога
  3. OpenNews: Уязвимость в Python-модуле TarFile, допускающая запись в любые части ФС
  4. OpenNews: Уязвимость в zlib, проявляющаяся при сжатии специально оформленных данных
  5. OpenNews: Уязвимости в cpio и libarchive
  6. OpenNews: Уязвимости в Libarchive, приводящие к выходу за границы буфера
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/64093-tar
Ключевые слова: tar, rust
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (194) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Аноним (2), 23:15, 21/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +96 +/
    Это успех, я считаю!

    Кто со мной согласен - ставим плюсик

     
     
  • 2.4, Tron is Whistling (?), 23:22, 21/10/2025 [^] [^^] [^^^] [ответить]  
  • +27 +/
    Не просто плюсик, а ++ - два плюсика.
     
     
  • 3.10, Anonimbus (?), 23:27, 21/10/2025 [^] [^^] [^^^] [ответить]  
  • –3 +/
    С плюсом-плюсом XD
     
  • 2.49, Грустный (?), 00:33, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Наконец-то хорошая новость.
     
  • 2.133, Соль земли2 (?), 09:49, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    И слепой поведёт слепого.
     
  • 2.144, Смузихлеб забывший пароль (?), 10:24, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +8 +/
    но ведь... но безопасно же и боровы чекают и вообще, нельзя выйти за границу массива и безопасная работа с памятью
     

  • 1.6, Аноним (6), 23:24, 21/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +29 +/
    Вы не понимаете! Это другое!
     
     
  • 2.15, Аноним (15), 23:37, 21/10/2025 [^] [^^] [^^^] [ответить]  
  • –4 +/
    А ты зоркий. Молодец, заметил - именно что другое. А то бы налетели сейчас местные сишники-ПравильныеПогромисты... Никаких тебе выходов за пределы буфера, обращения к освобожденной памяти или двойного освобождения памяти... Ну, именно того, от чего и должен спасать раст. А просто "логическая" ошибка. От которой никто не обещал (и не мог) защитить. Не в той позиции что-то там в файле считали и не проверили. Ну это те самые гугловско-майкрософтовские оставшиеся "30% ошибок", которые уже только напряжением мозгов нужно избегать.
     
     
  • 3.24, Аноним (24), 23:57, 21/10/2025 [^] [^^] [^^^] [ответить]  
  • +18 +/
    В новости ошибка работы с памятью. Да, ошибка не с оперативной памятью.
    Так выход за границы массива это логическая ошибка или нет? Если программист на Си ошибётся в размере массива, то это одно, а когда на rust ошибка с размером в структуре данных, то это другое?
    Нет, дружочек, это одного рода проблемы. Да, rust спасает от ошибок с оперативной памятью, с этим спорить не буду.
     
     
  • 4.34, morphe (?), 00:08, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +10 +/
    > В новости ошибка работы с памятью.

    В новости ошибка с неправильной интерпретацией спецификации

    В файле стоит

    Заголовок ustar:
      размер этого файла 0 байт
    Заголовок PAX:
      размер этого файла 20мбайт

    Старая реализация приоритетной считала значение из ustar, читала 0 байт файла, и дальше читала вложенный tar как содержимое основного tar файла

    А должна была читать PAX, и пропускать 20мбайт как содержимое файла

    Спека говно, и точно таким же образом обсираются все реализации tar которые PAX не поддерживают.
    PAX является якобы обратно совместимым, поскольку данные от него пропускаются легаси реализациями, однако он может содержать в себе копию размера, от чего и возможны такие конфликты

     
     
  • 5.273, RM (ok), 21:46, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Если одну и ту же информацию хранить больше чем в одном месте - рано или поздно содержимое копий не совпадет. "И чо тогда?"
    На... т.е. зачем было добавлять еще одно поле размера, особенно если старое все еще должно быть совместимо, т.е. о увеличении разрядности речь не идёт - непонятно совсем.
    Похоже спека таки кривая, т.е. непродуманая.
     
  • 4.39, Аноним (15), 00:13, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Чисто казуистический прием Разницу-то в ошибках вы да все остальные всё равно... большой текст свёрнут, показать
     
     
  • 5.66, Аноним (24), 00:59, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > а есть остальные, "логические" (вот как раз когда не то или не оттуда считали или введенное значение на допустимость значений не проверили или когда уставший сонный программист знаки больше с меньше перепутал).

    Так выход за границы массива – это буквально всё, что вы перечислили.

    Считали неопределённые данные.
    Не проверили границу.
    Уставший сонный программист запутался в инкременте в цикле for.

     
     
  • 6.69, Витюшка (?), 01:20, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Уровень кекспертизы подоспел.
    У вас есть буфер с содержимым "слово" из 5 символов.
    По спецификации нужно прочитать третью букву "о", вы этого не поняли и прочитали букву в. Где здесь ошибка работы с памятью и где выходит за границы массива?
     
  • 6.71, Аноним (15), 01:30, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    И тут врёте и всё перекручиваете Говорю же, казуистика Брехня Где тут выход з... большой текст свёрнут, показать
     
  • 4.80, Аноним (80), 02:25, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Так выход за границы массива это логическая ошибка или нет?

    В новости ничего не говорится о выходе за границы массива, Rust от такого защищает.
    >Если программист на Си ошибётся в размере массива

    То будет порча памяти.
    >а когда на rust ошибка с размером в структуре данных

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

    Да, другое. В случае сишной уязвимости, при распаковке можно было бы вызвать условный curl | bash, здесь - только переписать файлы.

     
     
  • 5.86, Аноним (24), 03:27, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > В случае сишной уязвимости, при распаковке можно было бы вызвать условный curl | bash

    Нельзя. С чего бы? Если речь только про ошибку при обработке данных, а не ошибке работы с ram.

     
     
  • 6.122, Аноним (80), 09:23, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    С того, что ошибки обработки данных в сишных программах встречаются редко, а вот ошибки управления памятью - часто.
     
  • 3.25, Аноним (25), 23:58, 21/10/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > оставшиеся "30% ошибок", которые уже только напряжением мозгов нужно избегать

    Ну раз напряжением мозгов, то софт на расте точно обречён. Ибо в него и привлекают-то лишь всякими "вам больше не нужно думать о размере буферов и указателях", а основная масса растофанов прекращает читать на слове "думать".

     
     
  • 4.87, Ruslan (??), 03:54, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Так это же замечательно, что какой-то инструмент позволяет не думать о том, что к делу не относится и сосредоточиться на прикладной задаче.

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

     
     
  • 5.92, Аноним (92), 04:54, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот сосредоточиться на прикладной задаче чет не получается.
     
  • 5.117, Аноним (117), 09:02, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда пиши на луа и питоне
     
  • 3.40, Аноним (6), 00:16, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    На другой тип ошибок нужен еще один ЯП!
     
     
  • 4.52, Аноним (52), 00:34, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Может, Zig?
     
     
  • 5.90, Аноним (90), 04:31, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Хороший вариант. Вон, в Редоксе на него драйвера переписывают.
     
     
  • 6.135, Аноним (52), 09:53, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да ну?! А что же с Растом не так?
     

  • 1.9, Аноним (6), 23:26, 21/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +12 +/
    А сколько багов остаются незамеченными тупо из-за того, что раст вынуждает писать нечитаемую лапшу и раздувать изначально компактный код в несколько раз
     
     
  • 2.19, Аноним (15), 23:43, 21/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    нечитаемая она для местных сишников. А кто вкатился в эту тему и какое-то время  в этом варился - заявляют, что всё прекрасно читается и понимается. Дело привычки. А техдир гугла еще и заявляет что команды, разрабатывающие проекты на расте, в два раза продуктивнее команд сиплюсплюсников. Предположу, что командная работа с "нечитаемой лапшой" не могла бы быть в два раза продуктивнее "абсолютно понятных" божественных плюсов.
     
     
  • 3.26, Аноним (6), 23:59, 21/10/2025 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Ты даже не понимаешь о чем речь, сразу видно что вкатился и варился. Когда даже книжный алгоритм приходится перелопачивать так, что он становится сам на себя не похож. Сколько из-за таких выкрутасов в коде возникает логических ошибок, невозможно и представить. Пока нормальные люди пишут код так, чтобы он был легко читаем и понятен, такие как ты варятся и вкатываются и навязывают остальным свои шизоидные извращения. Необходимы клиники для реабилитации, а еще лучше принудительные работы не связанные с компьютерами
     
     
  • 4.41, Аноним (-), 00:17, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –4 +/
    >  нормальные люди пишут код так, чтобы он был легко читаем и понятен

    Ага, видели мы тот код "от нормальных людей"
    Как тебе функция-портянка на 1000+ строк кода?
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driver
    Естественно с кучей кала в виде goto - нормальной обработки ошибок ведь не завезли...

    И ведь это ядро! Его же пишут профи))

    > Необходимы клиники для реабилитации, а еще лучше принудительные работы не связанные с компьютерами

    А принудительная стререлизация, ну чтобы уже на 100% как faшики, будет?

     
     
  • 5.62, Аноним (6), 00:45, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На расте функция конечно будет не 1000 строк, размер функций же от ЯП зависит
     
  • 5.65, Аноним (92), 00:59, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Функцию на тысячу строк можно на любом языке написать, если что. Понимать подобный код на Rust будет также сложно как на C с goto, поскольку только в Rust и regex смысл строки может кардинально измениться всего из-за одного символа. Неудивительно, что без ИИ с ним не разобраться.
     
     
  • 6.83, morphe (?), 02:55, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > поскольку в Rust смысл строки может кардинально
    > измениться всего из-за одного символа.

    А теперь приведи хоть один пример когда такое может произойти


     
  • 5.85, Аноним (85), 03:24, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Естественно с кучей кала в виде goto - нормальной обработки ошибок ведь
    > не завезли...

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

     
     
  • 6.125, Аноним (80), 09:30, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Лапшекод из goto осуждал ещё Дейкстра. Для нормальной обработки нужен как минимум типы Option и Result. А не спагетти, когда выполнение прыгает туда-сюда.
    >Вот интересно, обработка ошибок по твоему она магическая какая-то или ей занимается отдельный код?

    Да магическая. Поскольку goto ограничен пределами текущей функции, си вынуждает растягивать определния, в то время как монадическая обработка(как минимум) позволяет разбивать функцию на мелкие части.
    >Настоящий кал - это как раз запихать в ядро код обработчиков ошибок.

    Он уже там есть, только в виде лапши из goto.

     
     
  • 7.233, Аноним (233), 15:38, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Да магическая. Поскольку goto ограничен пределами текущей функции, си вынуждает растягивать определния, в то время как монадическая обработка(как минимум) позволяет разбивать функцию на мелкие части.

    Причем тут монадическая обработка? Обработка исключений вроде try ... catch в C++ (и других языках) - это не синтаксический сахар, а генерация отдельного кода под это дело, даже не всегда тривиального. В ядре же стараются избегать неявного кода.

     
  • 6.131, Прохожий (??), 09:42, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Похоже, вы в упор не понимаете разницу между готовыми абстракциями (которые предоставляет Rust) и собственным велосипедом (который из проекта в проект изобретают программисты на C).
     
     
  • 7.175, Аноним (175), 12:09, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >собственным велосипедом (который из проекта в проект изобретают программисты на C

    Э погоди! Ты делаешь необоснованный вброс о том, что велосипеды это плохо. Если сишник начнёт делать что-то более менее верхеуровневое, он неизбежно станет программировать то, что уже до него кто-то делал. Это нормально.

     
  • 6.156, Аноним (-), 11:13, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вот интересно, обработка ошибок по твоему она магическая какая-то или ей занимается  отдельный код?

    Ага.
    Например инвариант который проверит все возможные состояния.

    > Настоящий кал - это как раз запихать в ядро код обработчиков ошибок. Задумайся почему в ядре даже стандартных библиотек нет.

    Потому что ведро писал студент, а там как получилось)
    Зато в ядре есть 100500 велосипедов, про которые этот самый бывший студент недавно говорил:  "You'd think that all the basics would have been fixed long ago, but they're not. We're still dealing with basic issues such as memory management."

    Напомню что в недоязыках на старте не было даже структуры String не было.
    А поддержка UTF до сих пор хромает.

     
     
  • 7.163, Аноним (80), 11:50, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Напомню что в недоязыках на старте не было даже структуры String не было.

    Так и сейчас нет.

     
  • 4.45, Аноним (45), 00:27, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Когда даже книжный алгоритм приходится перелопачивать так, что он становится сам на себя не похож.

    Из этой фразы любому программисту видно, что ты алгоритм заучил, а не понял. Что однозначно определяет тебя как кодера на одном языке, которому никакая клиника уже не поможет.

     
     
  • 5.56, Аноним (6), 00:38, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Мне видно что ты читать не умеешь или какие-то ограничения в мыслительном аппарате, хз. Это где-то в первом классе у детей спрашивают про что пословица "без труда не вытащишь и рыбку из пруда" и они отвечают "про рыбку"
     
  • 4.47, Аноним (15), 00:32, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так а что же ты про техдира гугла не завернул? Вот же он наверное лох, похоже из клиники для реабилитации выступал. Ну или его подло обманули агенты раста с метриками разработки, подло оболгав плюсовиков. Но я конечно поверю тебе, а не ему.

    > Ты даже не понимаешь о чем речь, сразу видно что вкатился и варился

    К твоему сожалению, правда совсем-совсем немного, понимаю. Года три назад, не зная языка, "не вкатываясь", просто взяв примеры кода и подправив их под себя, сделал себе утилитку, работающую с внешними ресурсами (отчеты с биржи стягивает). _Почти_ всё там было понятно и аккуратно. Но да, язык учить надо. Сложное так просто не напишешь. Впрочем, как и на си.

     
  • 4.211, freecoder (ok), 13:28, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    8 лет разрабатываю на Rust, с такими проблемами не сталкивался.
     
  • 4.220, Аноним (220), 13:41, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Это проблема только для олимпиадников, которые алгоритмы зазубрили как стишок. Если понимаешь суть алгоритма, нет никаких проблем в том, чтобы его реализовать с ограничениями ownership. (Да, в ряде частных случаев такая реализация станет менее эффективной - тут всегда выбор, или с этим мириться, или воткнуть unsafe. Но это редкость).
     
  • 2.23, Аноним (15), 23:56, 21/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >  и раздувать изначально компактный код в несколько раз

    и вдогонку, из соседней новости, про принятие в ядро Linux 6.18 реализации Binder IPC для Android, написанная на Rust:

    "...Несмотря на продвинутые возможности и поддержку объектов со сложной семантикой владения, драйвер на Rust получился меньше варианта на Си - 5.5 против 5.8 тысяч строк кода."

    Ну т.е. после этого нам _очень_ интересно твое "икспертное" мнение. Ты наверное много программ написал сразу в двух вариантах - на си и на расте, чтобы сравнить и выдать свои ценные замечания, верно? Ведь верно?

     
     
  • 3.27, Аноним (6), 00:01, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сотни других неудобных примеров мы конечно проигнорируем, да?
     
     
  • 4.51, Аноним (15), 00:33, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Эти "сотни других неудобных примеров" только в Вашей голове? Откуда сотни примеров, если Вы и Ваши соратники утверждаете, что на расте вообще ничего не написано?
     
     
  • 5.59, Аноним (6), 00:41, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ничего не пишут, только переписывают
     
     
  • 6.162, Советский инженер (ok), 11:47, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ничего не пишут, только переписывают

    отлично, о том и разговор.
    значит ты легко приведеш примеры где перерисывание с С на Раст раздуло исходники.

     
  • 4.112, Аноним (112), 08:29, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Сотни других неудобных примеров мы конечно проигнорируем, да?

    Какие сотни, если ты ни одного не привел?

    Тебе вон дали буквально из соседней новости: кодя в Linux залит, и по сравнению с сишным стал не только проще, но и компактнее.

    Скажешь что-то сожержательное?

     
     
  • 5.145, Аноним (6), 10:24, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну даже тут на opennete была куча примеров, что переписали драйвер на расте, функционал меньше, объем кода больше, мне лень гуглить, если у тебя память как у золотой рыбки, какой смысл мне тратить на это время? Все равно ты через секунду забудешь, бросай ты растоманство, совсем с головой худо будет
     
     
  • 6.256, Аноним (256), 17:38, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > на opennete была куча примеров, что переписали драйвер на расте, функционал меньше, объем кода больше

    Не, друг, давай ссылки с цифрами. Пока что ты выдаешь только дешевый треп.

     
     
  • 7.284, Аноним (6), 01:14, 23/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    а ты мне что, друг?
     
  • 3.118, Аноним (118), 09:09, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    в одну строку поди писали, все равно ведь раст нечитаемый.
     
     
  • 4.134, Прохожий (??), 09:51, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >в одну строку поди писали

    1. Зачем вы свои проблемы проецируете на других?

    2. Чтобы не заниматься догадками, можно полезть в исходный код и посмотреть самостоятельно. Или такое действие слишком сложно для типичного "эксперта“, воина борьбы супротив Rust?

    Спойлер. Нет, в одну строчку на Rust (как и на любом другом языке программирования) типичные программисты не пишут.

     
     
  • 5.183, Аноним (183), 12:29, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Чтобы не заниматься догадками, можно полезть в исходный код и посмотреть самостоятельно

    А что им смотреть, если они сами пишут, что синтаксис Раста не осилили? Они ж не поймут ничего! 😂

     
  • 3.218, Пыщь (?), 13:39, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А в байтах какова разница, за вычетом комментариев?
    Я
    //комментарий раз
      могу
    //комментарий два
           оформить
    //комментарий три
                    предложение
    /* очередной бесполезный блок
       с комментарием */
                                так.
    Строк многовато вышло, меряться оформлением - так себе затея. А что, индусам за количество строк платили где-то когда-то..

    Кто-то вообще макросами не часто пользуется, или любит "копировать -> вставить" подобные куски с небольшими отличиями вместо inline с параметрами (навскидку подумалось).

    Мне вот больше интересен результат сборки из исходников: быстродействие, применение внешних библиотек, определение/задействование возможностей исполняющей техники (всякие sse, avx, gpu вычисления и прочее-прочее) и всякие UB в исполняемом файле.

     
  • 2.102, Дурка (?), 07:12, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Лапша есть и возможна на каждом языке программирования.
    Скажите вот эта растовая лапша, почему она вас так цепляет? Давайте проверим.
    Макфа? Есть реакция?
    Есентуки?
    Медведь?
    Анон?
    Opennet?
    Может быть Дядюшка Боб? Что-то есть фиксирую, мы теряем пациента, быстрее введите ему чистый код внутревенно.
    Фух вроде отпустило?

    А если серьезно даже не знаю чел сходи до книжного и прочитай чистая архитектура и идеальная работа.

     
     
  • 3.126, Аноним (80), 09:33, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Лапша есть и возможна на каждом языке программирования.

    Не на каждом. Достаточно убрать goto и количество лапши уже резко упадёт.

     
     
  • 4.178, anonymous (??), 12:14, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Как раз таки вырастет и читаемость упадет.
     
  • 2.113, Аноним (112), 08:34, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Откроем-ка осоеднюю новость https www opennet ru opennews art shtml num 64092... большой текст свёрнут, показать
     
     
  • 3.185, Аноним (183), 12:32, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Как так? 😭

    Боюсь, внятного ответа по теме мы уже не получим. Воин против Раста вон плюсиков за свой вброс получил от собратьев - и все, миссия выполнена.

     
  • 3.271, Аноним (271), 21:00, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >Смотри, эксперт, количество ошибок при использовании Раста только убавилось. Как так?

    Ответ в той же новости: за 15 лет развития "в старом коде накопился заметный технический долг, который усложнял как поиск ошибок, так и дальнейшую разработку. "
    >Смотри, Растовый код не только не раздулся по сравнению с изначальным сишным, но даже стал меньше его!

    300 строк разницы после переписывания с нуля? Если бы переписали на том же языке, результат мог быть лучше

    мимо-эксперт

     
     
  • 4.276, Аноним (-), 22:09, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > 300 строк разницы после переписывания с нуля? Если бы переписали на том  же языке, результат мог быть лучше

    А мог бы и не быть.
    Т.к инструмент остался тот же. Те же goto и отсуттсвие нормальных проверок ошибок, те же километровые функции, и тд
    Мог бы ты каменным топором построить современный дом?


     

  • 1.12, morphe (?), 23:31, 21/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +9 +/
    > Проблема вызвана тем, что уязвимые библиотеки при распаковке файлов вместо вычисления смещения на основе размера из расширенного заголовка PAX, брали размер из устаревшего заголовка ustar. При нулевом значении размера в заголовке ustar, идущее за ним содержимое файла обрабатывалось как корректный блок TAR-заголовков для следующего файла.

    Т.е проблема в том что спецификацию расширили не пойми как, включив несколько размеров для одного и того же файла, и интерпретация спеки на Rust выбрала из двух размеров не тот.

    Остаётся вопрос почему размер из PAX должен иметь приоритет, ведь теперь проблема может быть обратной - реализации TAR без поддержки PAX будут читать архивы иначе чем исправленная версия.

     
     
  • 2.16, Аноним (16), 23:38, 21/10/2025 Скрыто ботом-модератором     [к модератору]
  • –1 +/
     
     
  • 3.53, morphe (?), 00:36, 22/10/2025 Скрыто ботом-модератором     [к модератору]
  • +1 +/
     
  • 2.43, Аноним (-), 00:22, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +8 +/
    > спецификацию расширили не пойми как

    Там всё ещё интереснее. Этих форматов tar было как собак нерезаных. Когда POSIX решил это дело стандартизовать, он взял два формата ustar и PAX и объединил их в один. Это не расширение, это просто какой-то толпоиппизм. Я как-то думал написать реализацию tar в образовательных целях, в рамках ознакомления с каким-то очередным язычком программирования (а заодно и с tar ознакомиться), и забил именно из-за того, что разбираться со всеми этими завихрениями дидовского мышления не было никакого желания.

    Но за этим, на самом деле, прячется целая дидовская философия: работает, не трожь. Вместо того, чтобы сделать по уму, они пытаются сделать так, чтобы ничего не делать. Ну, точнее, пытались. Сейчас они наверное все на пенсии уже. Продолжают пытаться ничего не делать.

    > Остаётся вопрос почему размер из PAX должен иметь приоритет

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

     
     
  • 3.278, Аноним (45), 23:04, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > стандарты не создают реальность, а фиксируют её такой, какая она есть

    Есть два вида стандартов: те, которые фиксируют реальность (обычно с правками тех вещей, которые всех бесят), и те, которые разработаны комитетом (обычно в попытке сформировать реальность).

     

  • 1.18, Аноним (18), 23:41, 21/10/2025 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +2 +/
     

  • 1.20, Аноним (20), 23:46, 21/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Вот видите! Вот такими и должны быть баги, логическими ошибками, а не позорным переполнением буфера
     
     
  • 2.82, Медведь (ok), 02:39, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Вот видите! Вот такими и должны быть баги, логическими ошибками, а не позорным переполнением буфера

    Ффух, мне даже как-то легче стало. Так вот какими они должны быть -- баги на расте! Если я в программе на C сделаю баг как на расте -- можно? Или это будет опять позорный дыряшечный дидовский баг? Или такие баги разрешено делать только на расте, а всем остальным -- ни-ни, не трогай, это на новый год... ой, то есть для раста? Короче, можно полную инструкцию, какими должны быть правильные баги?

     
     
  • 3.94, Аноним (20), 05:45, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Объясняю, почему так вышло - потому что в программе на Си такой баг тоже будет. Но прежде, чем поймать его, вы будете ловить переполнения буффера, двойное освобождение и прочие подобные баги памяти, и только потом логические. А тут вот ловятся сразу уже логические баги. Экономия времени
     
     
  • 4.98, Аноним (-), 06:41, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Во-первых, все баги которые могут случится на чистом Си хорошо документированы и описаны. Кто пишет на чистом Си, и реально желает избежать багов, тот их избежит. Вина в не внимательности и торопливости.

    >А тут вот ловятся сразу уже логические баги. Экономия времени

    Дело не в характере ошибок, делов их в количестве. Не думаю, что общее количество ошибок на Расте меньше, чем в Си.

     
     
  • 5.129, Аноним (80), 09:40, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >Во-первых, все баги которые могут случится на чистом Си хорошо документированы и описаны.

    Часть багов, которые могут случится на си созданы разработчиками си и называются UB. Ещё часть багов никак не называется, но проистекает из тупой сишной семантики, типа отсуствия гигиенических макросов, нультерминированных строк, отсутствии алгебраических типов и так далее. И что в первом, что втором случае, нужно приложить достаточно усилий, чтобы очередной сишник заметил подвох.
    >Дело не в характере ошибок, делов их в количестве. Не думаю, что общее количество ошибок на Расте меньше, чем в Си.

    Как только вы отсекаете ошибки управления памятью, то вы автоматически уменьшаете количество ошибок. Логических ошибок от этого больше не становится.

     
     
  • 6.160, Медведь (ok), 11:37, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Как только вы отсекаете ошибки управления памятью, то вы автоматически уменьшаете количество ошибок. Логических ошибок от этого больше не становится.

    Это было бы прекрасно, если бы не одно жирное "однако". Однако раст исключает (некоторые) ошибки управления памятью за счет драконовских, вообще говоря, ограничений боровчекера и ценой отказа от множества распространенных (проверенных, отработанных и удобных!) парадигм и техник программирования. Я не говорю уже о тормозах при компиляции из-за туевой хучи проверок и тому подобных неудобствах. Фокус в том, что это все вместе взятое вполне себе увеличивает вероятность появления ошибок остальных 100500 сортов, от которых раст не защищает.

     
     
  • 7.173, Аноним (80), 12:04, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Однако раст исключает (некоторые) ошибки управления памятью за счет драконовских, вообще говоря, ограничений боровчекера

    Почему вы до сих пор не предложили не драконовские ограничения? Где соответствующая теория?
    >ценой отказа от множества распространенных (проверенных, отработанных и удобных!) парадигм и техник программирования

    Программа должна быть корректной. Если вам так тяжело писать на rust, то почему бы не перейти на языки с gc, типа go или ocaml?
    >Я не говорю уже о тормозах при компиляции из-за туевой хучи проверок

    Которые вы придумали. Вот пример для крестов https://habr.com/ru/companies/jugru/articles/438260/ когда короткая программа расягивает компиляцию на несколько порядков. Осилите аналогичный пример для rust?

     
     
  • 8.227, Медведь (ok), 14:06, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    О, пардон, я не в курсе что говорю практически с отцом-основателем Так это вы п... текст свёрнут, показать
     
     
  • 9.232, Аноним (80), 15:37, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А почему бы вам не перестать портить память Знаете, у меня нет ни малейшего жел... большой текст свёрнут, показать
     
     
  • 10.241, Медведь (ok), 16:05, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А я порчу Надо же, не знал А что, это патчи на каком-то другом C Респект м... текст свёрнут, показать
     
     
  • 11.244, Аноним (-), 16:11, 22/10/2025 Скрыто ботом-модератором     [к модератору]
  • –1 +/
     
  • 7.214, freecoder (ok), 13:34, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Можете привести распространённые парадигмы, от которых отказывается Rust? Наследование реализации не в счёт, в Си его тоже нет.
     
     
  • 8.267, Аноним (267), 19:30, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    глобальные переменные доступ к разделяемым данным на запись для всех ... текст свёрнут, показать
     
  • 6.205, Аноним (-), 13:10, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Неопределённое певедение возникает из-за особенности архитектуры компьютера Язы... большой текст свёрнут, показать
     
     
  • 7.237, Аноним (80), 15:42, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Такие ситуации должны избегаться автоматически Почему программа с синтаксическо... большой текст свёрнут, показать
     
  • 7.283, Аноним (-), 01:09, 23/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Неопределённое певедение возникает из-за особенности архитектуры компьютера. Язык Си тут не причём.

    Что за бред? Напомните, UB описаны в даташите на процессор или в стандарте Си?

    UB это следствие нарушения инвариантов, заданных спецификацией языка, и никак иначе. Инварианты нарушает программист, а не компьютер.
    Остальное даже не буду комментировать, типичная компетентность сишного иксперта.

     
  • 5.280, Аноним (45), 23:07, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Кто пишет на чистом Си, и реально желает избежать багов, тот их избежит. Вина в не внимательности и торопливости.

    Опять настоящих сишников ищет. Посмотри под юбками настоящих шотладнцев, может они там прячутся.

     
  • 3.128, Аноним (80), 09:36, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Если я в программе на C сделаю баг как на расте -- можно?

    Если матёрые сишники с этим не справляются, то почему вы должны?
    >Короче, можно полную инструкцию, какими должны быть правильные баги?

    Давайте. Как минимум без выхода за границы массива, двойного освобождения, висячих указателей, чтения нулевых указателей.

     
     
  • 4.208, Аноним (-), 13:16, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Давайте. Как минимум без выхода за границы массива

    Не получится. Потому-что подсчётом размера массива занимается сам программист. Растаманам задницу всё время подтирает компилятор, а это плохо. Сишник самостоятелен, растаман нет.

     

  • 1.28, ProfessorNavigator (ok), 00:01, 22/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не, ребят, сегодня не ваш день. Сначала предатели, пардон, производители процессоров вместе с Линусом в спину ударили, а теперь - вот))
     
     
  • 2.29, Аноним (24), 00:02, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Можно подробнее, пожалуйста?
     
     
  • 3.30, ProfessorNavigator (ok), 00:03, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Можно подробнее, пожалуйста?

    https://www.opennet.dev/opennews/art.shtml?num=64091

     
     
  • 4.32, Аноним (24), 00:04, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Спасибо.
     
  • 4.35, Аноним (-), 00:09, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Так и не ваш тоже opennet.ru/opennews/art.shtml?num=64092
    Вы же не будете сравнивать какую-то либу с ядром.

    ЗЫ: а чего в ту тему не заглянули, проффесор? сказать нечего было?

     
     
  • 5.38, ProfessorNavigator (ok), 00:13, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Так и не ваш тоже opennet.ru/opennews/art.shtml?num=64092
    > Вы же не будете сравнивать какую-то либу с ядром.

    Спасибо, посмеялся)) Не, не поможет ;)

    > ЗЫ: а чего в ту тему не заглянули, проффесор? сказать нечего было?

    Потроллить на сон грядущий ;) Не всё ж вам развлекаться))

     
     
  • 6.42, Аноним (-), 00:21, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Спасибо, посмеялся)) Не, не поможет ;)

    Конечно не поможет.
    Если человек ставит в один ряд ядро линукс и какую-то либу от дилетантов.. то это многое о нем говорит)

    > Потроллить на сон грядущий

    Получилось весьма уныло.
    Может лучше про коммунизм? Та щиза хотя бы веселее звучит!

     
     
  • 7.46, ProfessorNavigator (ok), 00:31, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Конечно не поможет.
    > Если человек ставит в один ряд ядро линукс и какую-то либу от
    > дилетантов.. то это многое о нем говорит)

    Снова посмеялся)) Не пытайтесь вырулить, говорю ж - не поможет)) Вам производители процессоров такую свинью подложили, прям загляденье.

    >> Потроллить на сон грядущий
    > Получилось весьма уныло.

    Но вы ж стриггерились - значит уже нормально ;)


     
  • 2.130, Аноним (80), 09:41, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >Не, ребят, сегодня не ваш день

    Сказал человек неосиливший xml парсер. От вас так и веет некомпетентностью.

     
     
  • 3.166, ProfessorNavigator (ok), 11:55, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Сказал человек неосиливший xml парсер. От вас так и веет некомпетентностью.

    И это всё? Кроме унылых попыток перейти на личности больше уже ничего не осталось? Ни высосанных из пальца примеров кода? Ни набросов про undefined behavior?)) Совсем-совсем ничего? Да-а-а... Мельчает тролль)) Может вам пора другую работу поискать? Пока возможность есть? Поучиться там чему? Вопросы, если что - риторические, чисто вам на заметку.

     
     
  • 4.196, Аноним (80), 12:56, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >И это всё? Кроме унылых попыток перейти на личности больше уже ничего не осталось?

    Как говорится
    >Talk is cheap. Show me the code.

    Вы свой код уже показали, ваш уровень не дотягивает даже до студента.

     
     
  • 5.207, ProfessorNavigator (ok), 13:12, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >>И это всё? Кроме унылых попыток перейти на личности больше уже ничего не осталось?
    > Как говорится
    >>Talk is cheap. Show me the code.
    > Вы свой код уже показали, ваш уровень не дотягивает даже до студента.

    Да без проблем)) Только при чём здесь я? Речь то пров вас идёт, господа. В общем, попытка съехать с темы не засчитана ;)

     
  • 5.254, Аноним (254), 17:10, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы свой код уже показали, ваш уровень не дотягивает даже до студента.

    Свой код покажешь, тогда и оценки будешь раздавать. А пока не дотягиваешь, чтобы мнение иметь.

     
  • 2.140, Аноним (-), 10:07, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > производители процессоров

    Так в АРМ такая проверка уже давно есть.
    Но раст в Андроид внедряют.

    Если проверка такая крутая, то почему она не помогает))?

     
     
  • 3.170, ProfessorNavigator (ok), 12:01, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Так в АРМ такая проверка уже давно есть.
    > Но раст в Андроид внедряют.
    > Если проверка такая крутая, то почему она не помогает))?

    Так это вы в Google спрашивайте, кого они там нанимают и как обучают, что им уже ничего не помогает.

    Да, ребята, людей нужно нормально учить, других вариантов нет. Бесплатно учить. Ни "волшебные" ЯП, ни искусственный интеллект (который искусственный - да, но вот интеллект - нет) вам не помогут. Придётся прибылью делиться со всеми.  


     

  • 1.31, Аноним (-), 00:04, 22/10/2025 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –3 +/
     

  • 1.55, Аноним (55), 00:37, 22/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Сишникам совсем уже делать нечего. Нашли микроскопическую ошибку и раздули из этого целую "уязвимость".
    Удалите новость, опеннет, не позорьтесь.
     
     
  • 2.58, Аноним (52), 00:39, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Нееет, выделите новость 20-м шрифтом.
     
     
  • 3.60, Аноним (15), 00:43, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Чтобы все оценили "кекспертизу" обсуждающих её сишников
     
  • 2.282, Аноним (282), 23:30, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >Удалите новость, опеннет

    Они и сайтам указывают.

     

  • 1.61, Аноним (92), 00:44, 22/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Почему программисты на Rust не могут <буквально> переписать логику с реализацией на C, а придумывают собственные дырявые велосипеды? Вообще, тот факт, что на Rust без ИИ программировать не получается по признанию его фанатов наводит на некоторые размышления...
     
     
  • 2.78, Аноним (80), 02:11, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Почему программисты на Rust не могут <буквально> переписать логику с реализацией на C

    Потому, что тогда у них будут буквально те же самые дыры, что и на си. Ибо на си нет афинных типов данных.

     
     
  • 3.91, Аноним (92), 04:36, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    И что, без аффинных типов в безопасном коде на Rust будут дыры? Вот это новость!
     
  • 3.106, Фрол (?), 07:51, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    скиньте кто-нить этому умнику линк на словарь Ожегова

    а то от его "афинных" типов у меня скоро глаз дергаться начнет

    услышал где-то умное слово и носится с ним, как дурень с писаной торбой

     
     
  • 4.132, Аноним (80), 09:43, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >услышал где-то умное слово

    Так я хочу, чтобы вы тоже услышали, а вы уши затыкаете. Ну и узнали что это такое.

     
     
  • 5.148, Фрол (?), 10:30, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    если б ты его еще писал правильно цены б тебе не было

    все эти "афинные" типы много помогли, когда прошлым летом выяснилось, что много лет назад в std::process::Command налажали с эскейпингом аргументов и все эти годы имели выполнение в шелле произвольной программы. как первокурсник-башпортянщик.

    SUCH SAFE. MUCH SECURITY.

     
     
  • 6.279, morphe (?), 23:05, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А теперь скажи: какие это "правила эскейпинга" существуют на винде, где аргументы идут одной сплошной строкой
    Ведь именно на винде этот баг и был, на Unix всегда всё хорошо с этим было
     
  • 4.139, Медведь (ok), 10:03, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Большинство растеров сами не понимают, что это такое -- афинные типы. Но как звучит! Афинные! Греция, оливки, голые рабы на аренах... Они и бегут, пуская слюни и oбляпaвшись смyзи.
     
     
  • 5.147, Аноним (80), 10:29, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >Большинство растеров сами не понимают, что это такое -- афинные типы

    Так я не на расте пишу, а вот сишников троллить - одно удовольствие.

     
  • 5.209, Аноним (-), 13:21, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >голые рабы на аренах

    В Древней Греции рабов на арену не пускали. На арене были атлеты, свободные граждане. Ну да в голом виде, без трусов. Просто нижнего белья как трусы тогда не знали.

     
  • 2.79, Медведь (ok), 02:12, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Почему программисты на Rust не могут <буквально> переписать логику с реализацией на C, а придумывают собственные дырявые велосипеды? Вообще, тот факт, что на Rust без ИИ программировать не получается по признанию его фанатов наводит на некоторые размышления...

    В основном они этим и занимаются, но специфика концепции владения в расте такова, что это не всегда возможно, боровчекер не велит. Ну и код они читать не особо привыкли, "компилируется --- значит, работает", вот их девиз.

     
  • 2.121, Аноним (121), 09:21, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Кампания популяризации Rust от корпораций как раз нужна им, чтобы набить кодовую базу для "ИИ", а потом "ИИ" всё будет писать сам. Им для "ИИ" нужен был язык, где нет "утечек" по умолчанию. (хотя это спорно). В итоге в будущем много софта будет AI slop написанным на Rust
     
  • 2.146, Аноним (6), 10:27, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Почему программисты на Rust не могут <буквально> переписать логику с реализацией на C, а придумывают собственные дырявые велосипеды? Вообще, тот факт, что на Rust без ИИ программировать не получается по признанию его фанатов наводит на некоторые размышления...

    Ну так да, язык рассчитан на то, что человек не может сам нормальный код написать. ВОт только какие-то ошибки он может и отловит, а дальше беда

     

  • 1.77, Аноним (77), 02:04, 22/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Не ошибается тот, кто ничего не делает. Давайте зароем топор войны Rust и C!
     
     
  • 2.107, Аноним (6), 07:56, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Вместе с ростом xd
     
  • 2.150, 1 (??), 10:47, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Rust вообще как язык ничего. Растодрочерство бесит, как любая секта.
    Ну или проще, хвали свое, но не надо хаять чужое.
     
  • 2.181, Аноним (55), 12:27, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Кек.

    >найден баг в софте на си

    растеры: ахаха, фуу, диды, шерето, дырявое, закопать!

    >найден баг в софте на расте

    растеры: не надо судить так строго, и вообще давайте забудем старую вражду, какое мы вам плохое зло сделали, да и вообще это не баг а фича

     

  • 1.88, Аноним (88), 04:05, 22/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Очередные неосиляторы юнит тестов. Попросили бы ИИ написать, даже самим не надо париться.
     
     
     
    Часть нити удалена модератором

  • 3.109, Аноним (109), 08:05, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    V in vibrant community means CVE
     
  • 2.120, Аноним (121), 09:18, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Сама суть unit тестов в том, что ты их сам пишешь осознанно, и не доверяешь "ИИ" с его галлюцинациями.
     

  • 1.116, Тфьу (?), 08:56, 22/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Обычная логическая ошибка. Сам Rust не причём.
     
     
  • 2.143, Ann (??), 10:16, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну, в языке C выход за границы массива и "use after free" -  это тоже обычные логические ошибки. Сам C не причем.
     
     
  • 3.153, Аноним (-), 11:07, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Ну, в языке C выход за границы массива и "use after free" -  это тоже обычные логические ошибки.

    Это когда приводят int к uint, получают переполнение с UB?
    Что-то логикой тут не пахнет))


     
     
  • 4.230, Аноним (230), 15:28, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > int к uint

    ЯП в котором этого нельзя сделать (ао многих вообще unsigned типов нет) - низкоскоростные помойки, т.к. например так можно хакнуть приведение числа в диапазон 0..X, если исходный int мог быть отрицательным - unsigned достаточно проверить только на < X, проверка > 0 уже не нужна. В компутор вижн такое полезно.

     
     
  • 5.236, Аноним (236), 15:40, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Угу, а у нас высокоскоростная помойка И получить выстрел в ногу Уязвимости из-... большой текст свёрнут, показать
     
     
  • 6.239, Аноним (230), 15:48, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Какой-то ге(й)ний решил использовать для size переменную signed.

    Во многих языках unsigned вообще нет, жабка, питон, и т.д.

    > как в недоязычках ... Уязвимости в библиотеке libxml2

    Ну так пускай прекрасные питон эльфы напишут свою безопасную либу для парсинга, подумаешь, всего-то в 100 раз медленнее будет работать.

     
     
  • 7.242, Аноним (-), 16:07, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Во многих языках unsigned вообще нет, жабка, питон, и т.д.

    Так это норм. Есть известные ограничения, которые определяют сферу применения.
    Не норм когда один и тот же код начинает работать непредсказуем.

    > Ну так пускай прекрасные питон эльфы напишут свою безопасную либу для парсинга, подумаешь, всего-то в 100 раз медленнее будет работать.

    Так тебе важнее скорость или отсутствие подобных сюрпризов)?

    Может у гугла или амазона дойдут руки и они наймут растовиков.
    Вон Биндер переписали - получилось надежнее чем на СИ и скорость не пострадала.


     
     
  • 8.248, Аноним (230), 16:28, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Мне незачем трястись над безопасностью, практически везде где я работал - софт и... текст свёрнут, показать
     
     
  • 9.252, Аноним (252), 17:01, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Браузер там был Критическая 0-day уязвимость в Chrome и libwebp, эксплуатируем... большой текст свёрнут, показать
     
  • 3.154, Тфьу (?), 11:11, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Ну, в языке C выход за границы массива и "use after free"
    > -  это тоже обычные логические ошибки. Сам C не причем.

    Нет. Это неопределённое поведение.

     
     
  • 4.168, Ann (??), 11:56, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Неопределенное поведение - это уже результат таких ошибок.
     
     
  • 5.234, Тфьу (?), 15:38, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Неопределенное поведение - это уже результат таких ошибок.

    Ага. Поэтому C плох.

     

  • 1.124, ИмяХ (ok), 09:28, 22/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >>вызвана некорректным выбором позиции в потоке

    Нужно срочно изобрести язык, который защищает от некорректношо выбора позиции в потоке и всё ПО переписать на него.

     
  • 1.136, Соль земли2 (?), 09:53, 22/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Может проблема вообще в tar? С какого перепугу архив внутри архива воспринимается как продолжение одного?
     
     
  • 2.158, Медведь (ok), 11:22, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Может проблема вообще в tar? С какого перепугу архив внутри архива воспринимается как продолжение одного?

    Чего уж там, если мир не подходит для раст -- нафиг такой мир. Всё должно быть таким, чтобы если скомпилировалось на раст -- значит работает. Эврика, я придумал, как писать абсолютно безглючные программы!

     
  • 2.174, Аноним (80), 12:05, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У тара куча проблем, например невозможность быстрого просмотра индекса, но к новости они отношения не имеют.
     

  • 1.142, bOOster (ok), 10:14, 22/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    То-то еще будет. Когда helloworld ваять на расте - там особых и мозгов то не надо. За 3 недели в любом рекламирующемся "factory".. до недопрограммиста!
     
  • 1.149, Аноним (80), 10:33, 22/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Господа сишники, объясните мне, зачем вам нужна возможность разыменновывать null, и зачем вам нужны негигиенические макросы?
     
     
  • 2.151, bOOster (ok), 10:58, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Сначала попробуй на низком уровне поработать с памятью, а потом глупости будешь спрашивать.
    Хотя разыменовывать null - это тоже глупость. У дурачков зачастую функция возвращает указатель на данные и в какой-нибудь очень "плохой день", когда вдруг памяти не хватило (зачем это предусматривать - любой современный комп имеет ее вагон и маленькую тележку), или еще что-нибудь вдруг возвращает null. Дурачек есстественно не проверяет  сам указатель, а пытается его содержимое проверить на что-нибудь if(*lp .... ). Вот тебе и разыменовывание. Это недостаток мозгов. Так как в данном случае нужны 2 проверки, но дурачек об этом не знает.
     
     
  • 3.167, Аноним (80), 11:55, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Хотя разыменовывать null - это тоже глупость.

    Удивительно, вы это признаёте.
    >Так как в данном случае нужны 2 проверки, но дурачек об этом не знает.

    То есть разделить указатели на два типа - точно не null и возможно null - и запретить разыменновывать те, которые возможно null - слишком сложно для сишников? Почему даже такая простая вещь до сих пор не встроена в компилятор?

     
     
  • 4.179, bOOster (ok), 12:21, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >>Хотя разыменовывать null - это тоже глупость.
    > Удивительно, вы это признаёте.
    >>Так как в данном случае нужны 2 проверки, но дурачек об этом не знает.
    > То есть разделить указатели на два типа - точно не null и
    > возможно null - и запретить разыменновывать те, которые возможно null -
    > слишком сложно для сишников? Почему даже такая простая вещь до сих
    > пор не встроена в компилятор?

    Эти сишники такие-же как и растовики. 3 месяца тупого образования. Правда за растовиками обычно компилятор гамно прибирает.
    Сишники которые проблему знают и представляют - таких ошибок не делают.

     
     
  • 5.180, Аноним (-), 12:25, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Эти сишники такие-же как и растовики. 3 месяца тупого образования. Правда за растовиками обычно компилятор гамно прибирает.

    Т.е автоматизация, как любят программисты.

    > Сишники которые проблему знают и представляют - таких ошибок не делают.

    А ж где таких взять? Чтобы клонировать)

    Но судя по тому, что ты написал, выходит "если взять рандомных сишников и растовиков, то от последних овна будет меньше, тк компилятор поубирал".

     
     
  • 6.187, bOOster (ok), 12:33, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Эти сишники такие-же как и растовики. 3 месяца тупого образования. Правда за растовиками обычно компилятор гамно прибирает.
    > Но судя по тому, что ты написал, выходит "если взять рандомных сишников
    > и растовиков, то от последних овна будет меньше, тк компилятор поубирал".

    Толку от них будет напорядок меньше. Так как если человек с Си связывается - он хотя-бы математический класс закончил. И базовые алгоритмы программирования знает, хотя и опыта ему не хватает. Но через определенное время он натренируется.
    Rust же - это залетные -"Ой, в IT платят хорошо". толку от них не будет даже в дальней перспективе, так как rust сдохнет в угоду еще чему нибудь.  


     
     
  • 7.191, Аноним (-), 12:44, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Хм чего тогда в соседней теме сложную и важную штуку в ядре заменяют Звучит к... большой текст свёрнут, показать
     
     
  • 8.193, bOOster (ok), 12:47, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ТОлько во влажных мечтах недопрограммистов там важную штуку в ядре заменяют ... текст свёрнут, показать
     
     
  • 9.195, Аноним (-), 12:55, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Хочешь сказать что биндер-драйвер для миллионов андроид устройств, это так, мело... текст свёрнут, показать
     
     
  • 10.198, bOOster (ok), 12:59, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Биндер-Драйвер Мдеее поржал ... текст свёрнут, показать
     
     
  • 11.202, Аноним (-), 13:04, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Смех без причины признак Просто открываем репозиторий ядра git kernel org pub... текст свёрнут, показать
     
     
  • 12.213, bOOster (ok), 13:32, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ну да, в ядро в целом Растовиков не пустили, поджопник выписали, так они полезли... текст свёрнут, показать
     
     
  • 13.222, Аноним (-), 13:48, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Что значит не пустили Они наоборот получили полный картбланш от Торвальдса и Гр... текст свёрнут, показать
     
  • 9.245, Медведь (ok), 16:13, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Рукоплещу стоя Полностью согласен Дополню BeOS 124 Haiku целиком на плюсах -... текст свёрнут, показать
     
     
  • 10.247, Аноним (-), 16:23, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ого, да тут сход анонимных критиков Торвальдса Бедняга наверное икает Что то ... текст свёрнут, показать
     
     
  • 11.251, Пыщь (?), 17:00, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Распространнёность уже отражает надёжность, производительность x86 вон тоже кос... текст свёрнут, показать
     
     
  • 12.253, Аноним (252), 17:05, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Производительность - да и нет Тесты и бенчи понятно покажут кто круче, а вот о... текст свёрнут, показать
     
  • 8.194, bOOster (ok), 12:52, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Откровенный бред нести не надо Никто с С, а тем более с плюсов на Rust не пойде... текст свёрнут, показать
     
     
  • 9.200, Аноним (-), 13:00, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Бред это ты сам выдумал ТОРом пользуешься Ну так вот создатели ТОР-клиента с... текст свёрнут, показать
     
  • 9.201, Аноним (80), 13:01, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Прямо рядом соседняя новость В ядро Linux 6 18 принята реализация Binder IPC для... текст свёрнут, показать
     
     
  • 10.210, bOOster (ok), 13:28, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Я же тебя предупреждал - не делай из себя клоуна IPC это InterProcessCommunica... текст свёрнут, показать
     
  • 9.246, Facemaker (?), 16:20, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Выбирать Rust первым языком для вката в IT никто не будет, там, думаю, питонисты... текст свёрнут, показать
     
  • 5.199, Аноним (80), 12:59, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Сишники которые проблему знают и представляют - таких ошибок не делают.

    Эти мифические сишники, пишущие код без багов. А вот открываешь список изменений в новой версии, и там всё как всегда. Потому, что недостаточно об этом помнить, нужно проверять каждый указатель и крайне желательно делать это автоматически.

     
  • 4.216, anonymous (??), 13:36, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что указатель это не некая магическая сущность, а просто целое число, содержащее адрес байта в памяти (виртуальной а бывает и физической). Осознай это и многое станет понятнее.
     
  • 2.152, Аноним (109), 11:05, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Потому что ассемблер так умеет, почему бы и сишке не уметь? А зачем тебе нужна возможность молотком себе по яйцам бить?
     
  • 2.161, Аноним (55), 11:45, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >зачем вам нужна возможность разыменновывать null

    Потому что в железе нет никакого специального значения null, это как правило адрес 0x0. И это совершенно валидный адрес. На некоторых платформах (DOS, например) его нужно рызыменовывать, там начало таблицы ISR.
    Никто не мешает тебе написать ОС, у которой по адресу 0x0 будут находиться какие-то вполне легальные данные.

     
     
  • 3.182, bOOster (ok), 12:27, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>зачем вам нужна возможность разыменновывать null
    > Потому что в железе нет никакого специального значения null, это как правило
    > адрес 0x0. И это совершенно валидный адрес. На некоторых платформах (DOS,
    > например) его нужно рызыменовывать, там начало таблицы ISR.
    > Никто не мешает тебе написать ОС, у которой по адресу 0x0 будут
    > находиться какие-то вполне легальные данные.

    Осью это обычно не ограничивается. RESET традиционно начинает с 0го адреса, если принудительно не задано иное. И там будет код jmp или реально исполнимый код. А эту область памяти - код, трогать очень нежелательно. Ну и да, таблицы прерываний - хотя они так-же могут быть перенесены куда-то. Но это не делают. Всем проще считать адрес прерывания 0+

     
     
  • 4.203, Аноним (80), 13:05, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >Осью это обычно не ограничивается. RESET традиционно начинает с 0го адреса, если принудительно не задано иное.

    Отлично, у нас есть уже какой-то проблеск сознания. А теперь расскажите мне, зачем это нужно в любом более менее прикладном софте? И почему в си это UB, как же тогда прерывания считывать?

    ЗЫ я так понимаю, про негигиенические макросы ответа можно уже и не ждать?

     
     
  • 5.219, anonymous (??), 13:40, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Не UB, а implementation defined поскольку архитектуры (сюрприз) бывают разные.
     
     
  • 6.257, Аноним (256), 17:47, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> И почему в си это UB, как же тогда прерывания считывать?
    > Не UB, а implementation defined поскольку архитектуры (сюрприз) бывают разные.

    Согласно стандарту С разыменование нулевого указателя - это именно UB.

     
  • 5.229, Аноним (55), 14:18, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >почему в си это UB

    А почему в си это UB?

    >негигиенические макросы

    Это фича, никто ее менять не будет. Видно, что вы не пишете на С, раз задаете такие вопросы.
    Если добавлять гигиенические макросы, то они должны быть отдельной сущностью, не те которые #define.
    Хотите такие макросы и запрет разыменования null - сделайте прототип нового С. Судя по тому что вы пишете, вам это будет несложно. Если это будет интересно сообществу - вас на руках будут носить.

     
     
  • 6.263, Аноним (263), 19:15, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >>почему в си это UB
    > А почему в си это UB?

    Потому, что это черным по белому написано в стандарте.

    > запрет разыменования null - сделайте прототип нового С

    А зачем новый, если и в старом это изначально запрещено стандартом?

     
  • 4.217, anonymous (??), 13:38, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    По крайней мере на x86 RESET НЕ НАЧИНАЕТСЯ с адреса 0, это вас кто-то обманул.
     

     ....большая нить свёрнута, показать (32)

  • 1.215, Аноним (215), 13:36, 22/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Любопытная новость, спасибо. Хороший пример ошибки, которую может совершить программист независимо от используемого языка.

    Полагаю, если Rust продолжат форсить по прежнему, мы увидим ещё не один и не два подобных примера.

     
     
  • 2.238, Вася Пупкин (?), 15:44, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да, это скорее внешний признак, который говорит о том, что раст получает все большее распространение.
     
     
  • 3.243, Facemaker (?), 16:10, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Обратите внимание на этот проект: https://github.com/nushell/nushell

    Скоро на всех экранах мира, как говорится.

     
     
  • 4.259, _ (??), 18:12, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да брось! Ни малейшего шанса! :)

    Такого уже было ... и так же пугали мол вот ОНО! Да хоть fish тоД-же :)


    Будет установлен у 1% ... у тех, которые из 4% ;-DDDDD

     
  • 4.264, Кошкажена (?), 19:18, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Толку от него, если он будет только у тебя на локахосте?
     

  • 1.249, Аноним (249), 16:48, 22/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    А так было ясно изначально, природа не терпит пустоты. Уйдут ошибки работы с памятью на их место придут логические ошибки, и общее число ошибок будет прежним.
    И вот уже на безопасном языке, небезопасная библиотека.
     
     
  • 2.250, Аноним (-), 16:53, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > А так было ясно изначально, природа не терпит пустоты.

    Когда фраза начинается с "сразу было понятно", то сдается меня хотят обмануть.

    > Уйдут ошибки работы с памятью на их место придут логические ошибки, и общее число ошибок будет прежним.

    А вот это просто пальцем в лужу.
    Никаких доказательств.

     
  • 2.277, Аноним (277), 22:41, 22/10/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > природа не терпит пустоты. Уйдут ошибки работы с памятью на их место придут логические ошибки, и общее число ошибок будет прежним

    Л - логика... Или это (не очень) тонкая ирония? "Щютка юмара"?

    Кексперты всерьёз утверждают, что в их сишном коде _только_ ошибки работы с памятью, а "логических" нет? Первый тип ошибок исключает второй? А вот как только избавятся от первых, так сразу откуда-то польются вторые, заполнять пустоту? Сишные сумрачные гении не могут без ошибок? Если у них отберут первые ошибки, они что, специально начнут плодить вторые?

     

  • 1.270, Аноним (267), 20:06, 22/10/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    посмотрел исправление async-tar.patch. да, разработчики реализовали неправильную логику обработки заголовка. Но может Rust, всё-таки, виноват в этом? Может Rust настолько сложен, что даже сами разработчики не заметили в этом буреломе кода ошибку? А в простых языках ошибки сразу бросаются в глаза?  simpler! ... make it simpler! ... encore un fois!
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2025 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру