1.1, Аноним (1), 08:07, 27/07/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –8 +/– |
> без должного анализа возвращённого ранее кода ошибки
Виноват си, потому что не дает sum types. То, что разраб забыл проверить -- простительно, потому что мозг -- это мясо. Мы не можем от мяса требовать 100%-ного анализа кода. К счастью, есть язык, который автоматизирует проверки. Он бы это выявил на этапе компиляции и подсказал мясу: "тут может вернуться ошибка". Мясо бы кивнуло и поблагодарило чудо-язык за техническую помощь.
| |
|
2.3, onanim (?), 08:55, 27/07/2025 [^] [^^] [^^^] [ответить]
| +2 +/– |
а gcc разве не выдаёт такие варнинги при компиляции?
и использование статических анализаторов разве не является обязательным при разработке критически важного софта?
| |
|
3.10, Аноним (10), 10:01, 27/07/2025 [^] [^^] [^^^] [ответить]
| –3 +/– |
Использование костылей разве не является обязательным при ходьбе?
| |
3.11, вымя (?), 10:24, 27/07/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если вы откроете патч (https://github.com/sudo-project/sudo/commit/fb208d383af27a07abe9cb277a620ea34c), то обнаружите, что pgrp приезжает из ec->cmnd_pid, который устанавливается вообще в другом месте, кем попало, как попало, аж в трёх си-файлах, да и там либо явно (= -1), либо очень косвенно (= cstat.val, = sudo_debug_fork()), а не из результата выполнения стандартной библиотечной функции. Компиляторный угадав тут явно бесполезен, потому что ему никто никогда не подскажет, используется ли потом это поле структуры в другом месте без проверки или просто авторы с привычками времён 80486 опять экономят байты исполняемого кода, удачно переиспользуя -1 по своему усмотрению.
И, да, Result/Either type тут действительно сэкономил бы время всем, потому что компилятор бы гавкнул на попытку использовать этот тип как аргумент kill(), и сделал бы это быстро и надёжно, в отличие от статических анализаторов, которым нужно проверить миллион инвариантов среди сотен функций из десятков файлов, не запутаться в них и не вылететь по исчерпанию памяти. Если, конечно, какой-то анализатор вообще надоумили проверить, что в kill() передаётся -1 (в чём я сомневаюсь, потому что отрицательные аргументы у kill легитимны и используются гораздо чаще, чем может показаться), потому что анализировать коды возвратов тут, похоже, бесполезно (см. выше).
| |
|
2.8, Anonimm (?), 09:34, 27/07/2025 [^] [^^] [^^^] [ответить]
| –2 +/– |
А где же "миллионы глаз", которые пропустили эту ошибку ещё на этапе сборки?
| |
|
3.14, Аноним (14), 11:57, 27/07/2025 [^] [^^] [^^^] [ответить]
| +/– |
у sudo настолько огромная кодовая база что отдельному программисту практически невозможно проверить все
| |
|
|
1.16, Карлос Сношайтилис (ok), 12:31, 27/07/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> При передаче отрицательного значения группы поведение не определен
Сишное мышление.
Когда привык, что UB это неотъемлемая часть системы и переносишься это на уровень пользователя.
| |
1.19, Аноним (18), 13:55, 27/07/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Ни когда не понимал, зачем такую косую утилиту пихают почти во все дистры линукса
| |
|
2.24, Аноним (25), 14:58, 27/07/2025 [^] [^^] [^^^] [ответить]
| +/– |
Потому что пользователей GUI пугают терминалы? )
Потому что он не в курсе привилегий и считает себя богом своей машинки, при этом ничего не понимая в плане безопасности надо принудительно разграничивать? )
| |
|
1.23, Аноним (25), 14:52, 27/07/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>При передаче отрицательного значения группы поведение не определено
Косяк killpg(). Они скажут, что тот кто использует killpg() должен контролировать что передает её. Но killpg() - часть системы, и приумножать хаос своей неопределенность не должна. Тем более проверка на входе для неё не критичная в плане производительности. Это все, может быть оставлено для костылей? Но ведь поведение кода не определено при таком фактическом значение!
| |
|