| 1.1, Аноним (1), 11:12, 22/11/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Обещали же в файрфоксе все эти парсеры в васм скомпилровать. RLBox.
| | |
| |
| 2.79, Аноним (-), 16:27, 22/11/2025 [^] [^^] [^^^] [ответить]
| –4 +/– | |
> Обещали же в файрфоксе все эти парсеры в васм скомпилровать.
Чтобы тормозило и жрало память еще и это? Файрфокс и так после открытия нескольких вкладок начинает дико якорить уже.
| | |
| |
| 3.111, Аноним (111), 01:51, 23/11/2025 [^] [^^] [^^^] [ответить]
| –3 +/– |
Да, тут писали. Вейланд так течёт, что там не только Фаерфокс, а даже курсор через некоторое время якорить начинает.
| | |
|
| 2.93, morphe (?), 19:59, 22/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
RLBox сложнее
Код сначала компилируют в WASM, а затем WASM превращают в C код с сохранением гарантий безопасности, проверок и изоляции WASM рантайма
| | |
| |
| 3.128, Смузихлеб забывший пароль (?), 14:06, 23/11/2025 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Васм в сишку не превращают ибо сие глупость. Вот наоборот - вполне
> Механизм работы RLBox сводится к компиляции C/C++ кода изолируемой библиотеки
> в низкоуровневый промежуточный код WebAssembly, который затем оформляется
> в виде WebAssembly-модуля, полномочия которого задаются в привязке
> только к этому модулю
> Преобразование кода C/C++ в WebAssembly осуществляется при помощи wasi-sdk.
> Для непосредственного выполнения WebAssembly-модуль компилируется в машинный код
> при помощи компилятора Lucet и выполняется в отдельном "нанопроцессе",
> изолированном от остальной памяти приложения.
> Компилятор Lucet основан на том же коде, что и JIT-движок Cranelift,
> применяемый в Firefox для выполнения WebAssembly.
https://www.opennet.dev/opennews/art.shtml?num=52440
| | |
| |
| |
| 5.144, Смузихлеб забывший пароль (?), 07:07, 24/11/2025 [^] [^^] [^^^] [ответить]
| +1 +/– | |
т.е они преобразуют Си в васм, потом преобразуют васм в Си и потом... потом компилируют ?)
Хоспаде, как же хорошо, что свалил с лисы. У них столько всего недоделано или могло бы быть сделано, вместо этого - они, при сильно ограниченных ресурсах, занимаются "вот этим вот"
Хотя, покопаться на досуге в сабже было бы интересно
| | |
| |
| 6.146, morphe (?), 10:56, 24/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
> т.е они преобразуют Си в васм, потом преобразуют васм в Си и
> потом... потом компилируют ?)
И это получается намного надёжнее всех имеющихся санитайзеров, да.
Сам такое применяю в Rust проекте использующем xmlsec. Производительность затрагивает незначительно, однако больше не нужно доверять коду этой библиотеки, который далеко не лучшего качества и плохо документирован
После перевода в rlbox даже обнаружил что я неправильно понял работу пары методов и получал use after free, с которыми сишная версия чудесным образом продолжала работать, а rlbox ловил ошибку
| | |
|
|
| 4.140, morphe (?), 21:32, 23/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> при помощи компилятора Lucet и выполняется в отдельном "нанопроцессе",
С момента публикации новости прошло 5 лет, никакой lucet в rlbox давно не применяется, да и вообще он мёртвый
> Lucet has reached end-of-life, and maintence has ceased. All Lucet users should transition to Wasmtime. | | |
|
|
|
| 1.6, Аноним (6), 11:41, 22/11/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –14 +/– |
Эти ошибки - результат эры PC. До PC все писали на басике и паскале и не парились. Потом пришли ребята, которые сказали, надоело системые проги на асме катать. Давайте изобретем си. Вот и изобрели себе на голову. А писали бы на басике, проблем бы не знали.
| | |
| |
| |
| 3.165, Аноним (165), 01:00, 26/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
чувак, не позорился бы...
JS -- не без изъянов, но прекрасный язык, писать на нём одно удовольствие.
судя по твоему высеру, твой скудный ум не смог освоить JS.
| | |
|
| 2.35, Аноним (35), 13:57, 22/11/2025 [^] [^^] [^^^] [ответить]
| –3 +/– |
Историческая безграмотность это настоящая беда современной молодежи!
Керниган и Ритчи (K&R) опубликовали «Язык программирования Си» в 1978 году. Ни каких РС, бэйсиков и паскалей еще даже в проекте не было.
| | |
| |
| 3.43, Аноним (43), 14:28, 22/11/2025 [^] [^^] [^^^] [ответить]
| +11 +/– | |
> Керниган и Ритчи (K&R) опубликовали «Язык программирования Си» в 1978 году. Ни каких РС, бэйсиков и паскалей еще даже в проекте не было.
Тем временем в нашей вселенной: язык программирования Pascal был создан в 1970.
| | |
| 3.102, 1 (??), 21:52, 22/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
ну если под PC понимать IBM PC -- то это 1981 года, а если более широкое толкование
The personal computer (PC) era began in the mid-1970s with the invention of the microprocessor, leading to the first commercially successful personal computers like the Altair 8800 in 1974. Mass production of pre-assembled PCs started in 1977 with the introduction of the Apple II, Tandy TRS-80, and Commodore PET. The industry then flourished in the 1980s with the launch of machines like the IBM PC and Apple Macintosh, making computers accessible to individuals and businesses.
| | |
|
| 2.107, Аноним (107), 23:31, 22/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
Так разве проблема не возникнет и при написании на ассемблере? Так же возникнет.
Проблему тут решит язык в котором работа к буфером возможна только по средствам
API, который проверяет границы. На сколько я знаю только два языка такое могут
и не поддерживают в чистом виде указатели.
| | |
|
| 1.19, Аноним (-), 12:51, 22/11/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +8 +/– | |
Шикарная новость!
С одной стороны ничего нового, типиkaл си код.
Но один пикантный момент в новости упустили - этой dыpeни уже почти десять лет :)
Была добавлена в январе 2016 в коммите Simplified API: write-to-memory, overflow handling [1], в котором исправляли ДРУГИЕ проблемы с переполнениями при обработке изображений.
/* Now check for overflow of the image buffer calculation; this
* limits the whole image size to 32 bits for API compatibility with
* the current, 32-bit, PNG_IMAGE_BUFFER_SIZE macro.
*/
Pathetic))
И почти десять лет выполнения стороннего кода при обработке специально оформленных файлов в огромном количестве пакетов! Все это время проблема оставалась незамеченной. Тыщща глаз смотрела куда-то не туда.
Добавил это в уточнение в новость, но не уверен что пропустят.
Поэтому продублирую тут чтобы порадовать всех))
[1] github.com/pnggroup/libpng/commit/175a126a1a9ecb8ffb26882f5fc0b509fecc656a
| | |
| 1.22, Аноним (22), 13:04, 22/11/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Странная ошибка. Попытка заюзать такую в реале должна быть винда на экране: либо будет специально-скрафченный корявый ввод при просмотре 16-RGB, либо получится корявый вывод 8-RGBA. Ну или забыли только про это одно место, а вывод трансформируется где-то ещё (и тогда вопрос - а было ли переполнение)
| | |
| |
| 2.67, Анонимусс (-), 15:38, 22/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
> либо будет специально-скрафченный корявый ввод при просмотре 16-RGB,
> либо получится корявый вывод 8-RGBA.
А уже не важно что будет на экране - подумаешь, битое изображение - главное что сторонний код уже успеет выполниться.
И выполнится он с правами процесса запустившего либу. Рута там надеюсь не будет, но прошерстить и отправить все что нужно куда нужно оно вполне сможет.
| | |
| |
| 3.121, Аноним (121), 06:39, 23/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
>сторонний код уже успеет выполниться.
Ничего там не выполнится, просто данные запортятся.
| | |
| |
| 4.162, Аноним (162), 13:06, 25/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
там heap overflow, так что можно и выполнить, если точно знать, что там за билд и на какой архитектуре
| | |
|
|
|
| 1.23, бсдшник (-), 13:12, 22/11/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Кстати забавно, если открыть страничку FreeBSD из новости (vuxml.org/freebsd/pkg-png.html), то там есть очень классная табличка
2015-11-15 libpng buffer overflow in png_set_PLTE
2015-01-05 png -- heap overflow for 32-bit builds
2012-04-08 png -- memory corruption/possible remote code execution
2010-06-28 png -- libpng decompression buffer overflow
2010-04-20 png -- libpng decompression denial of service
2008-04-25 png -- unknown chunk processing uninitialized memory access
2007-10-11 png -- multiple vulnerabilities
2007-05-16 png -- DoS crash vulnerability
2004-08-04 libpng stack-based buffer overflow and other code concerns
2004-05-02 libpng denial-of-service
Что какбЭ в полной мере характеризует качество кода этой либы и йазычка, на которой она написана.
| | |
| |
| |
| 3.45, Аноним (43), 14:32, 22/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
В любой более-менее популярной софтине на Си постоянно находят десятки CVE из-за ошибок с памятью, что как бы намекает на качество языка.
| | |
| |
| 4.115, Аноним (115), 04:42, 23/11/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Как наличие ошибок в коде влияет на качество языка? Где ты здесь нашел прямую зависимость?
| | |
| |
| 5.136, Аноним (132), 18:32, 23/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
>Как наличие ошибок в коде влияет на качество языка? Где ты здесь нашел прямую зависимость?
Зависимость строго обратная: качество языка влияет на количество ошибок.
| | |
| |
| 6.161, Аноним (162), 13:05, 25/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Качество языка влияет прежде всего на объем написанного на нём полезного кода, и тут С лидирует. А если сравнивать не объем кода, а объем его использования, так вообще с огромным отрывом.
Ни одного языка, способного на практике массово заменить С во всех областях его применения, за это время так и не появилось. Rust - единственный претендент.
| | |
|
|
| |
| |
| 6.166, Соль земли2 (?), 11:17, 27/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
Нормальный язык. Просто планка поднялась. А уязвимости можно и аппаратно блокировать. Так примерно и было раньше, но программистам свободы хотелось.
| | |
|
|
|
| 3.52, Аноним (-), 14:49, 22/11/2025 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Никак язык это не характеризует.
Ещё как! Идеальный инструмент для сокрытия бэкдоров. И, как показывает коммит, бэкдор из новости добавили, когда прятали предыдущий бэкдор. Цирк, да и только. А те, кто защищает этот макроассемблер - или сознательные саботажники, или полезные иди от ы.
| | |
| |
| |
| 5.103, Аноним (103), 22:27, 22/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
В расте и медленно компилироваться будет, и память жрать, и бэкдор из cargo прилетит. Если бы было по-другому, то закопали бы не просто язык, а его авторов живьём.
| | |
| |
| 6.116, Аноним (115), 04:44, 23/11/2025 [^] [^^] [^^^] [ответить]
| +2 +/– |
Забыл написать про человеческий фактор, что большинство растеров постоянно расчитывают на волшебный компилятор, который должен за них ошибки ловить, ибо своей головы, как правило, у растеров нет.
| | |
| |
| 7.123, Аноним (-), 08:08, 23/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> большинство растеров постоянно расчитывают на волшебный компилятор, который должен за них ошибки ловить, ибо своей головы, как правило, у растеров нет.
Почему вы пользуетесь транспортом - своих ног у вас нет?
Почему вы пользуетесь вилкой и ложкой - у вас нет рук?
А ногти как укорачиваете - зубами грызёте или используете ножницы/книпсеры?
Может у растохейтеров и есть голова, но такое впечатление, что логике вас обучало стадо бабуинов.
| | |
| 7.131, Аноним (-), 17:13, 23/11/2025 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> ибо своей головы, как правило, у растеров нет.
Ну так выкинь компьютер и считай в уме.
А тексты пиши ручками на бумажке, принтер "не нужон".
Подозреваю что подобные в 80х так же бухтели "зачем вам СИ?! настоящий программист пишет на ассемблере".
| | |
|
| 6.119, Аноним (119), 06:13, 23/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> В расте и медленно компилироваться будет, и память жрать, и бэкдор из cargo прилетит.
Ложь по каждому пункту.
> Если бы было по-другому, то закопали бы не просто язык, а его авторов живьём.
Уууу, какой ты грозный закапыватель.
| | |
|
|
| 4.149, Bottle (?), 14:23, 24/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
Самое смешное, что этот макроассемблер обладает неопределённым поведением, то есть он не является по-настоящему низкоуровневым. Никакое действие не гарантирует точный результат, в отличие от машинных кодов.
| | |
|
|
| 2.97, Аноним (97), 21:24, 22/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
В других либах на Си такой фигни нет, просто libpng пишут индусы.
| | |
| |
| 3.99, Аноним (132), 21:33, 22/11/2025 [^] [^^] [^^^] [ответить]
| –2 +/– |
Главное в новости про libpng не вспоминать про xorg, в новости про xrog не вспоминать про линукс, и так далее.
| | |
| 3.105, Аноним (-), 23:25, 22/11/2025 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> В других либах на Си такой фигни нет
Ну да, ну да, "это просто неправильная либа попалась" (с)
А потом куда не ткни - одни и те же дыpы)))
И примера правильной никто упорно предоставить не хочет. Или не может?
| | |
| 3.124, Аноним (-), 10:10, 23/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Есть и массово. Даже на opennet большинство новостей о уязвимостях - проблемы с памятью связанные с си.
Корпорации не просто так переходят массово на rust.
| | |
|
| 2.117, Аноним (115), 04:46, 23/11/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
А ты не знал, что исправление одной ошибки может привести к другим ошибкам?
| | |
|
| |
| 2.55, Анонимусс (-), 14:56, 22/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> В разработке этой библиотеки используются статические анализаторы
Используют.
"A Coverity project for libpng is at scan.coverity.com/projects/4061. The project is set up to scan the head of each of the libpng10 through libpng17 branches" [1]
И текущая libpng16 в него включена.
Но что-то не сильно помогает)))
> и санитайзеры
Как минимум часть багов нашли с из помощь [2]. Но используются ли они на постоянку при разработке на офф сайте и в README не сказано.
Скорее всего нет, патамушта диды и так пишут код на отлично!
[1] libpng.sourceforge.io
[2] github.com/pnggroup/libpng/issues/275
| | |
| |
| 3.83, Аноним (132), 16:43, 22/11/2025 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Но что-то не сильно помогает)))
Я задавал вопрос, а как в сишке проверить отсутствие разыменноывания нулевого указателя. Мне дали аж целых два флага для gcc, и ни один из них не заработал.
>Но используются ли они на постоянку при разработке на офф сайте и в README не сказано.
Если статический анализатор не включён в обязательные сборочные зависимости - значит не используют.
| | |
| |
| 4.88, Медведь (ok), 17:49, 22/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
 > Если статический анализатор не включён в обязательные сборочные зависимости - значит не используют.
Если хлеб в магазине не прикручен скотчем к колбасе, бутерброд ты никогда не сделаешь. Инфа сотка!
| | |
| |
| 5.89, Аноним (132), 18:16, 22/11/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ну вот покажите мне, где в libpng используется этот самый анализатор. И да, почему сишные проверки ломаются от рефакторинга?
| | |
| 5.104, Аноним (-), 23:04, 22/11/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> Если статический анализатор не включён в обязательные сборочные зависимости - значит не используют.
> Если хлеб в магазине не прикручен скотчем к колбасе, бутерброд ты никогда не сделаешь.
Отличная анал-огия! Почти такая же крутая как котенок с дверцей.
Еще раз по буквам "если статический анализатор не включён в обязательные сборочные зависимости" значит:
- его использование не обязательно и какой-то процент программеров просто не будет заморачиваться
- каждый будет лепить свой анализатор с уникальными настройками
- спрашивать "а проходить ли CI перед коммитов" думаю бесполезно))
| | |
|
|
|
| 2.108, Медведь (ok), 23:37, 22/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
Очень непохоже, чтоб использовали. CppCheck нашел вот такой забавный код, к примеру (pngimage.c:787):
static void
display_cache_file(struct display *dp, const char *filename)
/* Does the initial cache of the file. */
{
FILE *fp;
int ret;
dp->filename = filename;
if (filename != NULL)
{
fp = fopen(filename, "rb");
if (fp == NULL)
display_log(dp, USER_ERROR, "open failed: %s", strerror(errno));
}
else
fp = stdin;
ret = buffer_from_file(&dp->original_file, fp);
fclose(fp);
if (ret != 0)
display_log(dp, APP_ERROR, "read failed: %s", strerror(ret));
}
Тут сразу несколько явных глюков, имхо, и я в шоке от качества кода, будто школьник писал %)
| | |
| |
| 3.109, Аноним (109), 00:59, 23/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> CppCheck нашел
А что говорит? fclose(stdin)? В display_log там longjmp.
| | |
| |
| 4.114, Медведь (ok), 02:11, 23/11/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
Куда конкретно ткнул cppcheck, я честно говоря, пребывая в восторге от кода, не запомнил :)
Я не рыл display_log, но подозревал нечто этакое, хотя такой способ аварийного выхода, мягко говоря, неочевиден, деятель хотя бы функцию назвал подобающе. Но да, fclose(stdin) -- отличный косяк! Да и засовывание filename в dp->filename вызывает вопросы...
P.S. Да, ткнул вот сюда:
else
fp = stdin;
ret = buffer_from_file(&dp->original_file, fp);
fclose(fp);
| | |
| |
| 5.133, Аноним (132), 18:26, 23/11/2025 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Куда конкретно ткнул cppcheck, я честно говоря, пребывая в восторге от кода, не запомнил :)
Ну так ещё раз запусти
>но подозревал нечто этакое, хотя такой способ аварийного выхода, мягко говоря, неочевиден
Это логирование, как очевидно из названия
>Но да, fclose(stdin) -- отличный косяк!
В чём проблема?
>Да и засовывание filename в dp->filename вызывает вопросы...
А куда засовывать?
| | |
| |
| 6.152, Медведь (ok), 16:01, 24/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Это логирование, как очевидно из названия
А вот хренушки там.
> В чём проблема?
Ну, погугли хотя бы, что ли.
| | |
| |
| 7.154, Аноним (132), 17:37, 24/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
>Ну, погугли хотя бы, что ли.
Что именно? Насколько мне известно, те же демоны спокойно закрывают свои потоки ввода-вывода, для того, чтобы не зависить от терминала.
| | |
|
|
|
|
| 3.110, Аноним (132), 01:02, 23/11/2025 [^] [^^] [^^^] [ответить] | –1 +/– | Вы неправильно вставили ссылку, нужно и коммит и полный путь к файлу https git... большой текст свёрнут, показать | | |
| |
| 4.112, Медведь (ok), 01:59, 23/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Вы неправильно вставили ссылку, нужно и коммит и полный путь к файлу https://github.com/pnggroup/libpng/blob/1ebf432e85b53bf111a4...
Это в contrib, не критично
> Вам говорили, что 99.99% проектов его не используют, а вы не верили. Ну что, убедились?
Безосновательное обобщение, пока что подтвержден 1 проект )
> А вот и не факт. Вы в своё время усердно меня убеждали, что возможность разыменнования нулевого указателя - это хорошо, и что с этим ничего делать не надо.
Всё понимаю, поздно, выходные, но это галлюцинации, я такого не говорил. И там далеко не только с нулевым FILE* проблема.
> Писал настоящий сишник, сишнее не бывает.
Не знал, что говорю с экспертом по сишникам )) А вдруг он поддельный?
| | |
| |
| 5.134, Аноним (132), 18:30, 23/11/2025 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Безосновательное обобщение, пока что подтвержден 1 проект )
Продолжайте наблюдение, будут дальнейшие подтверждения
>И там далеко не только с нулевым FILE* проблема.
Постойте, но ведь алгебраические типы же нинужны, ровно как и ненулевые указатели! И потом, в сишке же исключений нет, и если fread не спровоцирует UB, то всё будет работать.
>А вдруг он поддельный?
Любой, кто пишет на си - настоящий сишник. Только вот тех, кто пишет на си без багов как-то подозрительно мало.
| | |
|
|
|
|
| 1.71, Аноним (132), 16:08, 22/11/2025 [ответить] [﹢﹢﹢] [ · · · ] | –1 +/– | Дыроделы, ваше оправдание Почему заведомо уязвимый код скомпилировался Я конеч... большой текст свёрнут, показать | | |
| |
| 2.85, Анонимусс (-), 16:47, 22/11/2025 [^] [^^] [^^^] [ответить] | +2 +/– | А вы знаете сколько времени и денег потратили на эту верификацию Скорее всего н... большой текст свёрнут, показать | | |
| |
| 3.86, Аноним (132), 16:55, 22/11/2025 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>При этом оценка доказательства аналогичного ядра по такой же методологии - 6-8 человеко-лет.
А куда спешим? Выше приводили, небольшой срез из freebsd
>2004-05-02
Я думаю, что за более чем двадцать лет как-то бы уже успели. Особенно, если местные експерты бы вместо того, чтобы здесь строчить комметарии о ненужно раста взяли бы и все вместе принялись писать.
| | |
| |
| 4.91, Анонимусс (?), 19:00, 22/11/2025 [^] [^^] [^^^] [ответить] | +1 +/– | В libpng v1 6 37 около 20K строк кода Это больше чем в два раза чем SLOC в SE4L... большой текст свёрнут, показать | | |
| |
| 5.137, Кошкажена (?), 18:51, 23/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> В libpng v1.6.37 около 20K строк кода. Это больше чем в два раза чем SLOC в SE4L.
Зачем все верифицировать? Достаточно верифицировать алгоритм, думаю там сильно меньше кода. Хотя, конечно, времени тоже много займет.
| | |
| |
| 6.141, Аноним (-), 21:57, 23/11/2025 [^] [^^] [^^^] [ответить] | –1 +/– | А почему достаточно верифицировать алгоритм Разве где-то в алгоритме сказано чт... большой текст свёрнут, показать | | |
| |
| 7.145, Кошкажена (?), 10:32, 24/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Да и не нужна такая надежность в прикладном софте.
Ну да, именно поэтому в питон добавили hacl*.
| | |
|
| 6.142, Аноним (132), 00:56, 24/11/2025 [^] [^^] [^^^] [ответить]
| –2 +/– | |
>Достаточно верифицировать алгоритм
Разрешаю, приступай.
>Зачем все верифицировать?
Всё - это что? Какую именно часть можно не верифицировать?
| | |
|
|
| 4.101, Аноним (132), 21:43, 22/11/2025 [^] [^^] [^^^] [ответить] | –2 +/– | А она там вообще хоть в каком-то виде есть Хотя-бы в виде сегодняшнего коммита ... большой текст свёрнут, показать | | |
|
|
| 2.118, Аноним (115), 04:49, 23/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
Компилятор не может знать что хочет сделать программист. С чего ты взял, что компилятор должен все это фильтровать?
| | |
| |
| 3.120, Аноним (-), 06:21, 23/11/2025 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Компилятор не может знать что хочет сделать программист.
А зачем ты пользуешься таким глупым компилятором?
Почему не взять тот, который хотя бы в 96% случаев понимает, чего хочет программист?
> С чего ты взял, что компилятор должен все это фильтровать?
С чего ты взял, что нет?
| | |
| |
| 4.126, Медведь (ok), 12:14, 23/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Почему не взять тот, который хотя бы в 96% случаев понимает, чего хочет программист?
Это какой же?
| | |
| |
| |
| 6.151, Медведь (ok), 15:49, 24/11/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Компилятор не может знать что хочет сделать программист
> Почему не взять тот, который хотя бы в 96% случаев понимает, чего хочет программист?
> Это какой же?
> copilot
Внимание, copilot внезапно стал компилятором. Ну-ну... Ещё откровения будут сегодня?
| | |
|
|
| 4.160, Аноним (160), 13:04, 25/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
- Пап, а бывает такой компилятор, который хотя бы в 96% случаев понимает, чего хочет программист?
- Нет это фантастика, сынок.
| | |
|
|
| 2.159, Аноним (160), 13:00, 25/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> Давайте подумаем, а как можно без ненжного раста превратить дырочные проекты в недырочные?
Добавить опцию компилятора -fmisra ?
| | |
|
| 1.129, Аноним (-), 16:38, 23/11/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
github.com/pnggroup/libpng/security/advisories/GHSA-7wv6-48j4-hj3g
> Attack Vector
> ...
> Application processes untrusted PNG files.
В переводе на русский, сишные библиотеки не годятся для использования в реальном мире.
github.com/pnggroup/libpng/issues/755
> Fixed in PR #757 ...
> Crediting Claude Sonnet 4.5 by Anthropic
Язычок настолько простой и понятный, что даже лучшие из сишников не могут исправить ошибку без помощи ИИ.
| | |
| |
| 2.130, Аноним (-), 16:59, 23/11/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> не могут исправить ошибку без помощи ИИ.
А сам ИИ обучили на аналогичном открытом овнокоде.
И будет он бракоделить также как и диды.
| | |
| |
| 3.163, Аноним (160), 13:11, 25/11/2025 [^] [^^] [^^^] [ответить]
| +/– |
Да обучи его хоть на Расте... Если обучал не лично ты, то овнокодить он будет как нужно тому, кто обучал и для кого нужно дыры всталять.
| | |
|
|
| 1.164, Аноним (-), 14:31, 25/11/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Уязвимость проявляется при использовании 8-битного RGBA-формата вывода (PNG_FORMAT_RGBA) для изображений с 16-битным представлением цвета на канал и чересстрочным кодированием (interlaced). Переполнение возникает из-за попытки записи данных с 16-битным представлением цвета в буфер, размер которого был вычислен из расчёта использования 8-бит на цветовой канал.
В C с целыми неустранимая проблема, они де факто ведут себя как нетипизированные, потому что все приведения вставляются компилятором молча. И даже варнингов нельзя включить, чтобы неявные преобразования мозолили бы глаза кодеру.
Чисто теоретически можно своих "целочисленных" типов наобъявлять на базе структур, и никаких неявных преобразований не будет, но тогда инфиксная запись арифметики станет недоступной.
| | |
|
