В Rust Coreutils выявлено 113 уязвимостей. В Ubuntu 26.04 возвращены cp, mv и rm из GNU Coreutils

то есть Rust в 21 веке намеренно сделали столь неудобным, чтобы потом его было труднее выпиливать?

Типа write only, а потому новый человек предпочтёт не дышать, чем разбираться?

Ага, ну, примерно так я и думал.

Например, ты сначала обращаешься по указателю, а затем проверяешь его на NULL.

А что мне делать, если у меня записаны данные по нулевому адресу? Ни стандарты Си, ни стандарты C++ не определяют NULL как некорректный адрес. Стандарт Си только упоминает о возможности некорректных аргументов библиотечных функций, которые довольно контекстозависимы:

7.1.4. If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined

Всё, никаких общей правильности-неправильности нет, стандарт требует только особую обработку в плане «NULL = NULL» и «object != NULL»:

6.3.2.3
An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.55) If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.
Conversion of a null pointer to another pointer type yields a null pointer of that type.
Any two null pointers shall compare equal.

Дальше уже шизы из состава разрабов GCC как всегда творчески подошли к вопросу и добавили оптимизацию проверки на NULL в четвёрке. Clang аж до десятки этой оптимизации не делал, MSVC и ICC не делают её до сих пор ни с какими флагами.

Тут выше писали про какие-то «стандарты» — о чём вы, их никто не читает, разрабы GCC просто творят ту херню, которая им вздумается. Вот GNU расширения в GCC — это тоже стандарты? Нет, просто ребятам так захотелось. Слава богу хоть сделали их отключаемыми.

то есть Rust в 21 веке намеренно сделали столь неудобным, чтобы потом его было труднее выпиливать?

Его сделали неудобным, потому что его разрабатывали крестовики, а крестовики на уровне подсознания привыкли к тому, что ЯП должен быть сложным и неудобным.

Типа write only, а потому новый человек предпочтёт не дышать, чем разбираться?

Давно читал код какой-нить библиотеки на Rust? Чужой код коллеги по проекту?

Mac OS X все-таки свой огород, но так и быть, аргумент принят :).

А от того что где-то внутри playstation есть юникс ни холодно, ни жарко, так как не подразумевает владение своим собственным устройством.

На Azure крутится линукс, линукс стал готов для таких задач как раз потому что копилефт.

В принципе, да, есть много юниксоподобных систем, всяких RTOS в микроконтроллерах. Но с ними как с playstation.

Это что-то совсем спорное. Особенно учитывая то, что есть реализация компилятора Си с безопасным управлением памятью (побезопасней Раст). Ничего не мешает сделать реализацию компилятора Си без УБ (ну флаги в gcc потыкать некоторые для начала, например).

Си с безопасным управлением памятью (побезопасней Раст)

Это уже не Си

Ничего не мешает сделать реализацию компилятора Си без УБ

UB это не свойство компилятора, это свойство языка

ну флаги в gcc потыкать некоторые для начала, например

Существует ли в gcc диалект Си, совсем лишенный UB? Если да, то хотелось бы ссылку на документацию gcc, где было бы прямым текстом заявлено об отсутствии всякого UB. Если нет, то почему так вышло? Авторы gcc - просто глупые и не разбираются в том, каким должен быть Си?

Это уже не Си

Это компиляторы C, да. Там же написано... ;) :)

Ни стандарты Си, ни стандарты C++ не определяют NULL как некорректный адрес.

Держи:

6.5.3.2 Address and indirection operators
....
If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined.
....
Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, an address inappropriately aligned for the type of object pointed to, and the address of an object after the end of its lifetime

https://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf

Тебя не смутила формулировка «Among the invalid values» и факт того, что оно написано мелким шрифтом в сносках, а не в самом стандарте? Это магия сишных стандартов — мы говорим, что «invalid value» нельзя использовать, но какое именно «invalid value» — это вы придумывайте сами.

Со strict aliasing там аналогичная история, к слову, то есть, в стандарте определены соотношения между понятиями, но сами понятия не определены.

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

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

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

Но степень фильтрации выше чем у раста

Толку-то, возьмём те же GNU coreutils (те самые, по заверениям коментаторов в этом треде, проверенные временем!) и самую простую утилиту - pwd. Отгадайте, была ли в ней в 2026 году найдена ошибка переполнения буфера?

В релизной ветке - не была. Во временных не знаю.

https://savannah.gnu.org/news/?id=10884

‘pwd’ on ancient systems will no longer overflow a buffer when operating in deep paths longer than twice the system PATH_MAX.

[bug introduced in coreutils-9.6]

В растовских coreutils за всё время 0 таких ошибок.

Может я конечно и не прав, но всегда считал UB платформо-специфичной вещью.

Undefined Behavior, или неопределённое поведение, про него вообще ничего нельзя сказать. Т.е. такой код может генерироваться во что угодно. Например в невозможную инструкцию машинного кода. Или вообще в ничего.

Т.е. компилятор предполагает, что такого случиться не может никогда. И можно делать что угодно. С точки зрения оптимизатора лучше всего вообще ничего не генерировать. Отсутствующий код работает быстрей всего.

Ещё интересный пример это вечный цикл. В одной из версий clang С++ код while (true) {} компилировался в ничего. Более того - весь код, включая эпилог функции, тоже выкидывался. Т.е. при вызове функции, содержащей этот код, управление переходило просто на следующую функцию, которой посчастливилось находиться в бинарнике после текущей функции.

Это было очень прикольно, не скрою. Например там могла бы быть функция, форматирующая диск.

Переполнение int это тоже undefined behavior.

Поэтому - нет, это не платформо-специфичная вещь. Платформо-специфичная вещь это, например, значение sizeof(int). Это называется implementation-specific behavior. Т.е. вызывать sizeof(int) абсолютно легально, и у этого выражения есть какое-то значение. Какое - стандарт не указывает. Если почитать документацию к gcc, то там это где-то должно быть указано. На разных компиляторах и разных платформах значение может отличаться, но форматирование диска вместо значения 4 компилятор не вставит.

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

Да, меня тоже такой подход к компиляторостроению раньше удивлял. Но, как говорится, маемо шо маемо.

Короче, года через 3 какой нить важный чел из Гугл или Клаудфларе заявит, что Раст не подходит для очень низкоуровневых утилит, а показал себя хорошо, только в тестах, но не практике - что писанина сводится к созданию постоянных обёрток над крестами и си и ОНИ УСТАЛИ! Компания приняла решение не использовать раст в проектах. Хаха

Ну-ну, посмотрим, какая из тебя Ванга.

А не вредит ли использование ансейф блоков? Я человек, мне надо делать ревью и стараться оценить все изменения. Часть изменений помечена Сейф, часть Ансейф. Подразумевается только работа с памятью, но я же человек. И буду меньше внимания уделять блокам, которые вызывают меньше тревог. Понапропускаю ошибков. Могу?

Используй абстракции из std

А сколько ждать сборку? А сколько ждать вызовы new на каждый чих?

А иишка даже неструктурированный код за секунду разберет и увидит что у тебя где. Что в чужом коде где. Если показать ему чужой код, он объяснит тебе - какие технологии использовались, какие тут плюсы и минус, какие технологии вообще есть. Какие логческие цепочки итд итп.

Это отличает программиста от непрограммиста. Непрограммист верит, что современные ллм понимают в коде больше, чем программисты этого кода.

При чем тут вера или мера понимания? Я вообще об этом где то писал?

Ему не надо понимать в коде больше создателя. Надо просто показать где в коде нужное и дальше по цепочкам.

В растовских coreutils за всё время 0 таких ошибок.

https://rustsec.org/advisories/RUSTSEC-2021-0119.html

Out-of-bounds write in nix::unistd::getgrouplist

Ой, что такое, но в Rust же не бывает повреждений памяти?

Короче, года через 3 какой нить важный чел из Гугл или Клаудфларе заявит, что Раст не подходит для очень низкоуровневых утилит, а показал себя хорошо, только в тестах, но не практике

Я пока не вижу причин так говорить. Как раз коротенькие програмки/функции на нём писать норм, а вот цельное приложение на нём не напишешь.

А не вредит ли использование ансейф блоков? Я человек, мне надо делать ревью и стараться оценить все изменения. Часть изменений помечена Сейф, часть Ансейф.

В safe блоках ты просто проверяешь логику, в unsafe блоках ты проверяешь логику и работу с памятью. В C/C++ ты вынужден каждую строку проверять на скрытое поведение.

Проблема Rust не в этом, а в том, что safe код в среднем по палате раза в два больше, чем в C++. А если ты начнешь динамические ссылки делать, асинхронщину, и прочее, то там все пять раз будет. Ну то есть в какой-то степени это будет оправдано, потому что код на C++ нужно будет тщательно проверять глазами — и всё равно после этого останутся ошибки. В Rust тоже останутся ошибки, но меньше, и большая их часть будет в логике, а не работе с памятью.

В Rust тоже останутся ошибки, но меньше, и большая их часть будет в логике, а не работе с памятью.

Проблема в том, что уследить за логикой становится сложнее, т.к. код многословный - состоит преимущественно из описания деталей, которые к высокоуровневой логике отношения не имеют: замусорен подробным описанием типов (как и в c++), замусорен разбором ошибок при каждом телодвижении (исключений-то нет), замусорен подробным описанием лайфтаймов (прогресс, фигле).

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

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

Подумай:

>>> a = "wtf_walrus"
>>> a
'wtf_walrus'

>>> a := "wtf_walrus"
File "<stdin>", line 1
    a := "wtf_walrus"
      ^
SyntaxError: invalid syntax

>>> (a := "wtf_walrus") # This works though
'wtf_walrus'
>>> a
'wtf_walrus'

>>> 1 > 0 < 1
True
>>> (1 > 0) < 1
False
>>> 1 > (0 < 1)
False

# Let's initialize a row
row = [""] * 3 #row i['', '', '']
# Let's make a board
board = [row] * 3

>>> board
[['', '', ''], ['', '', ''], ['', '', '']]
>>> board[0]
['', '', '']
>>> board[0][0]
''
>>> board[0][0] = "X"
>>> board
[['X', '', ''], ['X', '', ''], ['X', '', '']]

Что тебе не нравится в первых двух примерах?

Я тебе про хороший код, а ты мне про корнер-кейсы.

Я тебе про хороший код, а ты мне про корнер-кейсы.

Это язык-помойка, даже после линтеров там останется целый мешок «корнер-кейсов».

Например, есть целый ряд языков для JS, которые выкинули из JS классы. Например, Rescript. Но вот беда — во-первых, ряд механизмов (например, операторы) в питоне наглухо завязаны на классы, потому выкинуть их из ЯП не получится. Во-вторых, в питоне ублюдочные лямбды и даже банальный захват глобальных переменных до недавних пор был всратым:

>>> powers_of_x = [lambda x: x**i for i in range(10)]
>>> [f(2) for f in powers_of_x]
[512, 512, 512, 512, 512, 512, 512, 512, 512, 512]

a = 1
def some_func():
    return a

def another_func():
    a += 1
    return a
    
>>> some_func()
1
>>> another_func()
UnboundLocalError: local variable 'a' referenced before assignment

Про оператор += вообще можно песни слагать так-то — по этой причине я сторонник того, что нужно писать «a = a + 1» в питоне, если ты не уверен совершенно точно, что тебе нужна именно семантика «+=» для какой-то там оптимизации или хитрого поведения.

В растовских coreutils за всё время 0 таких ошибок.

https://rustsec.org/advisories/RUSTSEC-2021-0119.html

Обращаю внимание на слова «в растовских coreutils». Они не пользовались этой функцией. Вообще крейт nix был зависимостью зависимости rustyline, которая использовалась для интерактивного ввода в командной строке и обработки сигналов. Ошибочная функция из этого крейта не использовалась. Так что мимо.

Ой, что такое, но в Rust же не бывает повреждений памяти?

В safe-подмножестве не бывает.

Ой, что такое, но в Rust же не бывает повреждений памяти?

В safe-подмножестве не бывает.

Только не стоит забывать, что даже hello world использует unsafe функции.

Использует, и что дальше? Все функции для хелловордов проверены и вероятность наличия в них ошибки крайне низка. Что этому могут противопоставить языки, в которых вся программа один сплошной unsafe?

А разв в питоне есть не глобальные переменные? (шучу)

А мне больше последний пример кажется нормальным.

Все функции для хелловордов проверены и вероятность наличия в них ошибки крайне низка.

https://www.opennet.ru/opennews/art.shtml?num=62286

«в настоящее время стандартная библиотека Rust насчитывает около 35 тысяч функций, из которых в 7500 встречаются блоки кода, выполняемые в контексте «unsafe». За последние три года в библиотеке было выявлено 57 проблем с корректностью работы, из которых 20 были помечены как уязвимости» (текст из конца 2024 года)

Если «крайне низкая вероятность» реализуется на практике 57 раз, то это говорит о том, что вероятность была оценена неверно, и «крайне низкой» она не является.

Использует, и что дальше? Все функции для хелловордов проверены и вероятность наличия в них ошибки крайне низка.

Ну так можно и на C++ писать hello world.

Что этому могут противопоставить языки, в которых вся программа один сплошной unsafe?

Проблема в том, что ты сравниваешь сорта говна, и далее выбираешь, какое из них более или менее вонючее. Unsafe unsafe-у рознь, это не бинарное свойство. Например, тот же Go решает большинство проблем с безопасностью, при этом оставляя ряд проблем и не нагружает при этом программиста работой. Rust же слабо решает проблему непредсказуемых невоспроизводимых ошибок логики — он просто автоматически распознаёт примерно половину из них, и делает это за счёт усложнения кода. Вторая половина ошибок, которые повреждают данные без нарушения правил доступа к памяти, вообще никак не решена в Rust — о чём и большинство срачей в интернетах.

Корень проблемы прежде всего в том, что начиная с 8086 все процессоры оптимизированы под язык Си и небезопасны как этот самый Си. Прежде всего в плане логики — небезопасность памяти просто является частным случаем. Сишность раста очень хорошо видна по тому факту, что бекенд у Rust — это LLVM, и спортировать его на другие беки не получается. Задача «выстроить безопасную программу на сишном исполнителе» — это что-то класса «отсосать сотне спидозных негров, не заразившись при этом», то есть, изначально грустная задача. «Безопасные» языки оборачиваются в три слоя латекса, что, естественно, даёт не ту скорость исполнения.

«Но ведь может быть максимальная скорость с безопасностью» — нет, не может. Максимальная скорость подразумевает lock-free програмирование, которая в Rust представляет собой сплошной unsafe. И это опять же вина исполнителя, у которого нет никаких примитивов для безопасной многопоточности.

В общем, safe-unsafe никогда не был самоцелью ни у кого, кроме отдельных наркоманов из бигтеха. Бигтех счастлив, потому что memory safety у сишного кода — это очень трудоёмко, то есть, никто кроме корпораций этим заниматся не будет, монопольное положение будет углубляться, и альтернатив никто не будет развивать, потому что «всё внимание сообщества сосредоточено на Rust».

Я просто ещё раз напомню, что в Rust deadlock является memory safe сценарием выполнения. По это мало кто вспоминает.

Поздравляю с пятью звёздами.

Это не те звёзды, не настоящие, соевые. Настоящие должны быть не такими - ★, а вот такими - ☆.

И тут вдруг мне говорят - а чо такова? Ты просто делай правильно и запомни все свои концепции. Юмористы, блин. Такое ощущение, что все вокруг какие то сверхлюди, все могут, все им просто и понятно. Один я дурак.

- Шеф, говорят на вашей дороге какой-то идиот едет по встречке.
- ДА ИХ ТУТ ТЫСЯЧИ!

Во-вторых, прошло 30 лет. Сравни разрешение экрана в те времена и сейчас.

Ну, давай сравним:

28" InterView 28hd96 Color Monitor / Invar shadow mask CRT
1920x1080 @ 85Hz
2048 x 1152 @ 80Hz

3D графику на эти мониторы выдавали рабстанции от SGI (Crimson / Onyx).

Т.е. FullHD на десктопе существовал 35 лет назад.

Нихрена удивительного, что винда получила такое коммерческое распространение и в итоге выиграла десктопную гонку.

Венда выиграла "десктопную гонку" в первую очередь потому, что работала на конфигурации в $1,500 против $150,000 за оборудование из поста выше. Никакой "гонки" собственно не было.

Не надо путать язык и дефолтную библиотеку. … И второе вообще не стоит учитывать при оценке именно языка.

"Теоретически, сынок, мы с тобой миллионеры, а на практике…"

28" InterView 28hd96 Color Monitor / Invar shadow mask CRT
1920x1080 @ 85Hz
2048 x 1152 @ 80Hz

Т.е. FullHD на десктопе существовал 35 лет назад.

Это не имеет значения. Посмотри на диагональ этих мониторов - тогда все в основном сидели в нативном разрешении. Речь у нас шла про современные маленькие экраны с 2K и 4K. А ими без масштабирования большинству пользоваться невозможно.

Это одна из причин. Дорогая техника с хорошими гуями всё равно в приоритете, см. на эпл.

Дурацкая аналогия.

Например, куча софта на Си не использует stdio.h для операций с файлами (а использует POSIX-интерфейсы, WINAPI-интерфейсы или разные обёртки над нативными функциями), но от этого этот софт не перестаёт быть написанным на Си. В ядре так вообще libc в полном смысле нет и не может быть, но оно всё так же написано на Си. В эмбедах libc часто даже приблизительно не присутствует, но это всё равно Си. Можно и ещё много примеров найти.

Так что нет, что бы там в ISO не фантазировали, есть язык Си - соглашение о том как объявлять типы, переменные, функции, синтаксис операторов if/for/while/итд, препроцессор и прочее, что жёстко зафиксировано языком, и есть системная библиотека, которая часто действительно реализует те функции, которые описаны в ISO-стандарте, но может их и не реализовать, а можно её и не линковать например - это всё никак на язык не влияет.

И тут вдруг мне говорят - а чо такова? Ты просто делай правильно и запомни все свои концепции. Юмористы, блин. Такое ощущение, что все вокруг какие то сверхлюди, все могут, все им просто и понятно. Один я дурак.

Нет, просто вокруг программисты, а ты гуманитарий.

И тут вдруг мне говорят - а чо такова? Ты просто делай правильно и запомни все свои концепции. Юмористы, блин. Такое ощущение, что все вокруг какие то сверхлюди, все могут, все им просто и понятно. Один я дурак.

Нет, просто вокруг программисты, а ты гуманитарий.

Я тоже гуманитарий, получается. Для состояния «я должен помнить, что где лежит» есть вполне конкретное название:
https://upload.wikimedia.org/wikipedia/commons/thumb/8/85/James_arranging_bra...
https://upload.wikimedia.org/wikipedia/commons/0/0d/Autistic-sweetiepie-boy-w...

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

«Раньше гуманитарием называли человека, который хорошо знал историю, литературу, иностранные и древние языки, а сейчас это слово часто используют в значении «человек, который не знает математику»»

Это не ответ на мой вопрос, а смена темы.