В стандартной Си-библиотеки Musl выявлена уязвимость (CVE-2024-2961), приводящая к переполнению буфера при преобразовании специально оформленного текста из кодировки EUC-KR в UTF-8 при помощи функции iconv(). Уязвимость проявляется начиная с версии musl 0.9.13 и будет исправлена в готовящемся к публикации выпуске 1.2.6 (до публикации обновления следует использовать патч)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62719
В glibc такого нет!
https://opennet.ru/54508 CVE-2019-25013 - переполнение буфера при обработке в функции iconv строки в кодировке EUC-KR, включающей некорректные многобайтовые последовательности (например, echo -en "\x00\xfe" | iconv -c -f EUC-KR -t "UTF-8").https://opennet.ru/61033 CVE-2024-2961 - переполнение буфера при преобразовании специально оформленных строк в кодировке ISO-2022-CN-EXT функцией iconv().
https://opennet.ru/49059 CVE-2016-6261, CVE-2016-6263, CVE-2017-14062 - серия уязвимостей во встроенной реализации функций для разбора интернационализированных имён доменов.
Ну вот!
Он все правльно сказал: в glibc такого (уже) нет!
А то что было, это не считается.
EUC-KR никак диверсия кетайцев!
Корейцев же. Северных.
Серверных.
Так-с, понятно откуда уязвимый код функции, под GPLv3 между прочим, был скопирован.
Как эта либа читается? Мус-ел, -ыл, -ли...?
насколько я помню "U" читается как "А".на выходе получаем "МАСЛ"
Масло.
Как muzzle. Или как конец слова "шлимазл".
"конец шлимазла" ... вона оно как ... 8-D
Только это никакое не масло. Звучит как muscle (мускулы).
>Звучит как muscleMySQL?
>на выходе получаем "МАСЛ"Садись, пять!
муслим
Маслоу. Пирамида. Нижний уровень.
По-русски читается как [масл]. В английском омоним слова muscle - мускула.
Мюсл
Мюсли - это жаргон. Как Silverlight - сервелат.
Вот почему стоит сосредоточиться на улучшении инструментов для C/C++, таких как статический и динамический анализ кода, Address Space Layout Randomization и Data Execution Prevention, вместо того чтобы развивать Rust.
С/С++ очень сложны для современных программистов и любой знакомый с ними автоматом записывается в диды
> С/С++ очень сложны для современных программистов и
> любой знакомый с ними автоматом записывается в дидыНет такого языка С/С++.
Есть древний C, на котором пишут диды.
А есть прекрасный современный C++, на котором крутые парни пишут весь современный софт!Проблема только в том, что некоторые сишники берут плюсы... но получается все равно программа на си. И этим портят репутацию нормальным плюсовикам.
Что, разыменновывание нулевого указателя в крестах больше не UB? А может ещё и за границу массива нельзя вылезти? И двойных освобождений там нет?
> Что, разыменновывание нулевого указателя в крестах больше не UB?Все еще UB. К сожалению, это тяжелое наследие сишки.
> А может ещё и за границу массива нельзя вылезти?
Используй итераторы.
> И двойных освобождений там нет?
Используй smart pointer'ы.
В с++ намного больше современных инструментов чтобы не выстрелить себе в ногу.
Другое дело что ими не все пользуются - вот как раз люди с си головного мозга.
А вот нормальные разрабы пишут на с++ на порядок более надежный софт.Иначе как объяснить, что сишка сейчас осталась только в легаси, а все нормальные проекты не на си, не на расте, не на фортране или аде, а на плюсах?
>Другое дело что ими не все пользуются - вот как раз люди с си головного мозга.Это - и есть проблема крестов. Если я вижу файл с расширением cpp, то не вчитываясь в код, я не могу быть уверенным в том, что там нет таких серьёзных проблем.
>А вот нормальные разрабы пишут на с++ на порядок более надежный софт.Как бы не так. https://www.opennet.dev/opennews/art.shtml?num=61748
>Задействован новый парсер формата JSON, переписанный с C++ на язык Rust, и обеспечивающий более высокую защищённость за счёт снижения вероятности появления ошибок при работе с памятью. Отмечается, что переход на новый парсер может привести к прекращению разбора некоторого некорректно оформленного контента в формате JSON, но при этом он также решает проблемы при работе с некорректным JSON, который раньше вызывал аварийное завершение, а теперь приводит к возврату кода ошибкиВот что-что, а парсер json, это что-то вроде hello world от мира парсеров, но даже такой формат плюсовики обработать не могут.
> Если я вижу файл с расширением cpp, ... я не могу быть уверенным в томВот я о том же! Если бы все писали в файлах cpp на с++, а не на си, то мир бы стал намного лучше.
ЗЫ: а если c расширением "с", то можешь быть уверенным? А если можешь, то в чем?))
> Как бы не так.
Речь идет не о rust vs с++, а c++ vs c.
Понятно что раст дает больше гарантий чем плюсы (цена этих гарантий выходит за рамки обсуждения)
Но плюсы дают больше гарантий чем чистый си. И даже не понимаю о чем тут спорить.
> Если я вижу файл с расширением cpp, то не вчитываясь в код, я не могу быть уверенным в том, что там нет таких серьёзных проблемЕсли я вижу файл с расширением rs, то не могу быть уверен в том, что там не используются unsafe конструкции, а соответственно нет уверенности, что там нет проблем.
> >Задействован новый парсер формата JSON, переписанный с C++ на язык Rust, и обеспечивающий более высокую защищённость
Это только время может показать
>Если я вижу файл с расширением rs, то не могу быть уверен в том, что там не используются unsafe конструкцииНаличие unsafe проверятеся обычным grep, кроме того есть #![forbid(unsafe_code)]
>Это только время может показатьВремя это уже показало. Плюсовики неасилили json парсер, хотя это буквально учебный пример https://dev.realworldocaml.org/parsing-with-ocamllex-and-men...
>> А может ещё и за границу массива нельзя вылезти?
>Используй итераторы.А на запись?
Запись придумали трусы. Динамические массивы - лентяи.
Реальные пацаны ничего и ни на кого не пишут. И никогда не леняться.
Реальные пацаны творят.
Фу быть не пацаном.
>Все еще UB. К сожалению, это тяжелое наследие сишки.C++ не является продолжением языка Си. Сишка не говорила плюсам, скопируй меня. Когда разрабатывали C++ cишка никак не навязывала себя. Так что не надо говорить, по какое-то там "наследие". Все проблемы C++ это проблемы самой C++.
Язык Си на 90% совершенный и завершённый продукт.
Очень интересное мнение, к сожалению автор С++ с вами не согласен: https://www.youtube.com/watch?v=86xWVb4XIyE&t=700sКак это сишка не навязывала себя, когда C++ изначально вообще был реализован трансляцией того, что было добавлено относительно C в код на C последующей компиляцией C-компилятором (https://en.wikipedia.org/wiki/Cfront) ?
> Очень интересное мнение, к сожалению автор С++ с вами не согласен: https://www.youtube.com/watch?v=86xWVb4XIyE&t=700sНу ты сравнил какого-то автора С++ и целого анона с форума.
Естественно анон лучше расскажет, как было на самом деле и что именл в виду автор))
>Очень интересное мнениеЭто не мнение это факт. Страуструпа ни Томпсон, ни Ритчи не уговаривали, взять за основу C++, язык Си. Страуструп не умел писать компилятор, его первый компилятор С++ это надстройка над компилятором Си. Что умел то и налабал. Для Страуструпа важен был концепт ООП, а не то как он реализовал свой первый компилятор. И тем более в то время его не интересовали проблемы "неопределённого поведения".
Да ну чушь же вы пишете. Интересовал бы концепт ООП и правильные идеи - разивавал бы Smalltalk.А его интересовало именно как имея все преимущества C, получить еще и ООП с сохранением всего этого.
>И этим портят репутацию нормальным плюсовикам.Смех в аудитории переходяший в откровенный ржач и LoL-ище :)
А я то думал а в чём проблема С++ - а вот оно как! :)
> Смех в аудитории переходяший в откровенный ржачСмех без причины - ну ты понял))
> А я то думал а в чём проблема С++
Причин может быть много, не?
Я озвучил только одну из них, как раз в контексте абсолютно безграмотного наброса про некий язык "с/с++". Если хочешь обсудить проблемы современного с++, то можем сделать это в другой теме.
Ну да, а Rust простой и понятный, даёт легкочитаемый код.
У него безопасТная работа в пямятью!(С)
(TM)
Ну да. Вполне себе. Можно сравнить что-то даже. Например вектор из стандартной библиотеки.https://github.com/gcc-mirror/gcc/blob/master/libstdc%2...
https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#397В плюсовой версии происходит непонятная хтонь. В версии на расте есть свои нюансы, но там есть столько документации и комментариев, что не разберётся только тот, кто не умеет читать.
Замечу, что стандартная библиотека - витрина языка.
Как раз наоборот, они слишком примитивны и требуют писать слишком много кода чтобы добиться довольно скромных по нынешним временам результатов за приемлимое время. С — замечательный язык, если вас зовут Денис и вам нужно скрафтить «трёхнедельный юникс». Однако, глядя на гигантский проект Linux Kernel, мы можем видеть собственными глазами, насколько плохо С подходит для командной разработке в большой распределённой команде. Странным образом Танненбаум оказался прав, а Линус нет, но совершенно не в той плоскости в какой они спорили в своё время. Многих _организационных_ проблем проекта можно было бы избежать, отодвинь Линус эго в сторону и выбери микроядерную архитектуру. Но история не знает про сослагательное наклонение, и через тридцать с гаком лет проект страдает от того решения. Как именно страдает можно почитать в том числе и здесь.
> Как раз наоборот, они слишком примитивны и требуют писать слишком много кода чтобы добиться довольно скромных по нынешним временам результатов за приемлимое время.А если зарплата почасовая ;)
Но думаю вы правы оба - язык примитивны по возможностям, но сложный по всяким неочивидным какахам типа UB для сложения двух чисел.
> С — замечательный язык, если вас зовут Денис и вам нужно скрафтить «трёхнедельный юникс».Или написать ядро на 10к строк)
> Однако, глядя на гигантский проект Linux Kernel, мы можем видеть собственными глазами, насколько плохо С подходит для командной разработке в большой распределённой команде.
Думаю тут дело не только в языке, но и в подходах.
В современной разработке никому не придет в голову принимать и мерджить патч присланный по почте (слава богу машине, не голубиной)). А потом осознавать что код тупо не компиляется.
Тут будет куча CI, тестов, может линтер и тд> Странным образом Танненбаум оказался прав, а Линус нет, но совершенно не в той плоскости в какой они спорили в своё время. Многих _организационных_ проблем проекта можно было бы избежать, отодвинь Линус эго в сторону и выбери микроядерную архитектуру.
Утверждение сомнительное, не уверен, что тогда бы линукс взлетел.
Когда все начиналось было очень удобно наваливать код в огромную кучу.
Я слабо представляю, как в почтовой рассылке обсуждать контракты для модулей, в перерывах отвлекаясь на срочное исправление color на colour.
>В современной разработке никому не придет в голову принимать и мерджить патч присланный по почте (слава богу машине, не голубиной))Ядро до сих пор примерно так и пишут
>Тут будет куча CI, тестов, может линтер и тдНа всех линтеров не напасёшься.
https://www.opennet.dev/opennews/art.shtml?num=56449
>Опубликован набор патчей, ускоряющих сборку ядра Linux на 50-80%Сколько ещё разных проблем, не пойманных анализаторами - неизвестно
>Утверждение сомнительное, не уверен, что тогда бы линукс взлетел.Популярности линукса способствовали: свободная лицензия, возвращающая наработки в апстрим, нежелание Таненбаума принимать патчи в миникс, позволяющие им нормально пользоваться, долгострой Hurd, который постоянно переписывался и не был пригоден для реального применения.
> Популярности линукса способствовалиСуд между BSDI и USL, а также тонны денег, которые были влиты в линукс, пока эти суды шли.
Это была самая существенная причина. Все остальное мелочи. Особенно смешно про Hurd.
>а также тонны денег, которые были влиты в линукс, пока эти суды шли.Деньги начали вливаться гораздо позже, чем была опубликована самая первая версия ядра, для начала ядру нужно было показать свою жизнеспособность.
>Это была самая существенная причина. Все остальное мелочиТам было очень маленькое окно, условно в пару лет, в которое можно было запрыгнуть. Поторопись GNU, и деньги полились бы в Hurd. Или если бы кто-то написал свой аналог Minix-а.
А куда тогда записывать тех, кто лабает на ассемблере?
В восставших из мертвых?
> А куда тогда записывать тех, кто лабает на ассемблере?Исключительно на ассемблере?
> В восставших из мертвых?
Тогда в красную книгу. С охранным статусом CR "Находящиеся на грани полного исчезновения"
Где-то рядом с коболистами))
> Где-то рядом с коболистами))Кобольдами же
А что, на rust уже стало принято писать код без unsafe, и по этой причине ему стали не нужны все те же меры, что нужны коду на сишке?
> А что, на rust уже стало принято писать код без unsafeВообще-то так всегда было.
У них принято использовать unsafe только тогда, когда иначе написать невозможно.
Собственно за это накидали в панамку истеричке-аффтору Actix - он пытался игнорировать правила использования unsafe (тут подробнее opennet.ru/opennews/art.shtml?num=52208)Многие либы используют атрибут #![forbid(unsafe_code)], который просто запрещает использование unsafe во всем крейте. А для карго есть cargo geiger, который проверяет все зависимости на наличие или отсутствие unsafe_code.
Как результат - на середину 2024 года 80% пакетов не используют unsafe.
opennet.ru/opennews/art.shtml?num=61251Но есть ситуации когда ты его не имеешь права не использовать.
Напр. при взаимодействии с чужим кодом через FFI.
Прикол с Растом в том, что если писать на нём прошивки, драйвера и прочие низкоуровневые вещи, то без unsafe блоков обойтить нельзя. И все преимущества безопасного языка улетучиваются. Тогда может возникнуть вопрос. А не проще ли сразу взять чистый Си.
> то без unsafe блоков обойтить нельзяДа. И это абсолютно нормально.
> И все преимущества безопасного языка улетучиваются.
Нет, не улетучивается. У тебя unsafe код лежит отдельными кучками с большими предупредительными знаками, а не размазан равномерным слое по полу, стенам и так далее.
Ну а то что кучек много... ну так это предметная область такая, ничего тут поделать нельзя.> А не проще ли сразу взять чистый Си.
Проще. А потом имеем что имеем))
Раст же это не столько safe и unsafe.
Тот же боровинг и лайфтаймы проверяются и для unsafe code, если это не pointer'ы (которые по умолчанию unsafe). В расте есть нормальные типы, которые позволяют писать более строгий код.
В rust unsafe инкапсулирует разрушительный код. В си - любой код разрушительный, даже printf.
>Как результат - на середину 2024 года 80% пакетов не используют unsafe.А то что вседи них нет _ни_одного_ системного, это ты скромно умолчал?
А так то я согласен: JSON-ы с левой руки в правую можно в расте безопасТно перекладывать :)
>А так то я согласен: JSON-ы с левой руки в правую можно в расте безопасТно перекладывать :)А вот на си - нельзя. Избавьте нас хотя-бы от ошибок в перекладывании json-ов и смены кодировки
Если мне кто то предложит бизнес логику на Си писать - я его сам до мусоропровода провожу :)
Впрочем системных ржавчиков - тоже, туда же :)(голосом генерала Михалыча) Ну! За консенсус!
>Если мне кто то предложит бизнес логику на Си писать - я его сам до мусоропровода провожу :)Ага, только вот почему-то пишут. Тот же lxc, например.
> он пытался игнорировать правила использования unsafeего проект, его правила. Его просто затравила толпа неспособных "правильных" фанатиков и троллей.
Прям то достижение, которым надо гордиться
> Его просто затравила толпа неспособных "правильных" фанатиков и троллей."Фанатики" и "тролли" ему присылали патчи с исправлением проблем, но он их не принял потому что они "были слишком скучные"
> Прям то достижение, которым надо гордиться
Да, это достижение.
Сообщество показало, что ̶т̶е̶б̶е̶ ̶с̶ ̶н̶а̶м̶и̶ ̶н̶е̶ ̶п̶о̶ ̶д̶о̶р̶о̶г̶е̶,̶ ̶г̶р̶я̶з̶н̶ы̶й̶ ̶о̶в̶ц̶е̶е̶б̶!̶ такие быдлокодеры ему не нужны. Пусть катится писать на сишке, там таких любят.
> ему присылали патчи с исправлением проблем, но он их не принял потому что они "были слишком скучные"это его проект, его право. Пусть хоть настроения не было
> Сообщество показало, что
оно, мягко говоря, не совсем здорово
> стоит сосредоточиться на улучшении инструментов для C...языку шел шестой десяток.
>> стоит сосредоточиться на улучшении инструментов для C
>...языку шел шестой десяток.Вечные ценности(С)
Ваш то <куль_ЯП_наме> уже все забывать начали небось? :)
Так сишники теорию не знают. Они до сих пор не знают ни про аффиные типы, ни про зависимые, ни про кучу других вещей.
А те кто про них знает - программировать не умеют :) Вот так и живём :)
> Вот почему стоит сосредоточиться на улучшении инструментов для C/C++, таких как статический и динамический анализ кода, Address Space Layout Randomization и Data Execution Prevention,Напомни когда СИ был представлен? Или хотя бы стандартизирован?
Почему это не было сделано раньше, а шевелиться начали только когда появились какие-то смузихлебы с новым модным языком?Фигня в том, что им было пофигу. На ошибки, на постоянные CVE.
Они просто говорили "мы так привыкли, идите отсюдова".
И люди шли, на джаву, сишарп, котлин и прочие языки которые заменили СИшку практически во всех областях.С С++ ситуация немного лучше - там добавили smartpointer'ы и прочие блага цивилизации.
Надеюсь они смогут внедрить модули и хотя бы часть из планов по Safe-C++
>Надеюсь они смогут внедрить модули и хотя бы часть из планов по Safe-C++Зачем нам модули? Модули это чисто Паскалевская тема.
Си, кресты и ржавчину давным давно пора закопать. В системном языке программирования обязаны присутствовать не только афинные типы, но и зависимые.
> В системном языке программирования обязаны присутствовать
> не только афинные типы, но и зависимые.Ты шутишь? Типикал сишники даже аффинные типы не осилили, в расте линейных нет (хотя есть крейты), а ты зависимые предлагаешь!
Хотя я только за. Еще бы и формальную верификацию для всех mission critical приложений.
Ваша проблема в том, что вы только трепаться горазды :)
Возьми и сделай! Нарду понравится - дольше сами наперегонки побегут.
Но вы не про сделать, вы про по-скулить... :)
> Возьми и сделай!Так мы уже сделали. И народу понравилось.
А в ответ получаем "вы не заставите меня учить раст!", "мне не нужен второй мейнтейнер" и прочее от дидов.
>Так мы уже сделали. И народу понравилось.У вас повреждение моска? Если бы понравилось народу то:
> А в ответ получаем "вы не заставите меня учить раст!",
Ух как понравилось! Люто! Вот не помню чтоб кто то орал Вы не заставите меня учить Си! :)
> "мне не нужен второй мейнтейнер" и прочее от дидов.
Правильно, он один в одиночку тянет больше чем все ржавчики на планете ... ну вот нах вы ему? Подгузники менять? Ну такое ...
>>Так мы уже сделали. И народу понравилось.
>У вас повреждение моска?Rust - один из самых любимых языков программирования согласно опросам на Stackoverflow.
>Ух как понравилось! Люто! Вот не помню чтоб кто то орал Вы не заставите меня учить Си! :)
Есть и такие. Например, те, кто пишет ПО для бизнеса. Там долгое время Java с C# рулили. Как сейчас - не знаю.
У вас, как не одна крайность, так другая. То вам кажется, что абсолютно все не любят Rust (вы судите исключительно по мнению нескольких людей), то вам кажется, что все любят C.
>Правильно, он один в одиночку тянет больше чем все ржавчики на планете
Как выясняется, не тянет уже. Период максимальной продуктивности давно пройден. Осталось только тёплое местечко, которое в любой момент могут выбить из-под ожиревшей задницы. Вот человек и истерит, вместо того, чтобы просто освоить более совершенный язык программирования.
Возможно.
Но - ты не сможешь! :)
+ /* This failure condition should be unreachable, but
+ * is included to prevent decoder bugs from translating
+ * into advancement outside the output buffer range. */
+ if (k>4) goto ilseq;
Это failure condition должно было быть unreachable, но что-то пошло не так (опять)...
- if (c >= 93 || c>=0xc6-0x81 && d>0x52)
+ if (c > 0xc6-0x81 || c==0xc6-0x81 && d>0x52)
goto ilseq;
В этом коде прекрасно все!
Просто иллюстрация мема "Damn Bitch, You Live Like This?" в жизни))
Думаешь, что так было бы лучше?const int THRESHOLD_C = 0x45; // 0xc6 - 0x81
const int THRESHOLD_D = 0x52;if (c > THRESHOLD_C || (c == THRESHOLD_C && d > THRESHOLD_D))
> Думаешь, что так было бы лучше?Немного, но не слишком.
Там должно быть не THRESHOLD_C, а нормальный неминг что это за plane или символы и пояснение почем от сих и до сих оно не конвертируется.
А так получается куча magic numbers.
Думаю да.
Как минимум все магически константы именованы.
И избавились от 0xc6 - 0x81.
Ошибиться и написать 0xc7 - 0x83 стало сложнее.
Но я верю в способности пограммистов))
Сложно пишете, непонятно!
Вот так надо:
&НаКлиенте
Процедура ПрибавитьМесяц(Команда)
ПрибавитьМесяцНаСервере();
КонецПроцедуры&НаСервере
Процедура ПрибавитьМесяцНаСервере()Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ДОБАВИТЬКДАТЕ(ДАТАВРЕМЯ(2020, 3, 30), МЕСЯЦ, 1) КАК СледующийМесяц";
РезультатЗапроса = Запрос.Выполнить();
ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать();Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
Дата = ВыборкаДетальныеЗаписи.СледующийМесяц;
КонецЦикла;Сообщить(Дата);
КонецПроцедуры
Ужас русского программиста.
> Это failure condition должно было быть unreachable, но что-то пошло не так (опять)...Одна из фишек раста -- это макрос unreachable!(), который говорит компилятору, что код unreachable, но в дебаге компилятор всё же выполняет проверку и втыкает панику. Ты не представляешь, как познавательно ловить паники вида reached unreachable код. Такого рода паника позволяет видеть, как думал программист, который вписал unreachable, а git bitsect позволяет понять, как думал программист, который сломал недостижимость кода. В большинстве случаев, второй просто не думал о недостижимости, он в каком-то совершенно другом месте программы что-то правил, а недостижимость сломалась здесь. Собственно баг выше как раз такую ситуацию и демонстрирует.
Без unreachable!() всё не так интересно. Во-первых, паника не случается, и ошибка может оставаться незамеченной годами, во-вторых, когда ошибка замечена и даже локализована, непонятно чем думал программист, когда оставил какое-то условие непроверенным. Исправить баг это не мешает, но нисколько не учит тому, где лежат грабли, и как бы так на них не наступить.
> В этом коде прекрасно все!
Это работа с чарами и их диапазонами. Если тебе эти числа ничего не говорят, то зачем ты смотришь в код?
>> Это failure condition должно было быть unreachable, но что-то пошло не так (опять)...
> Одна из фишек раста -- это макрос unreachable!(),Хм.. на раст код не похож. Так что твое замечание познавательно, но не более.
Наверное твой макрос нужен только неопытным програмистам, а вот настоящие СИшники могут и без него)> Это работа с чарами и их диапазонами. Если тебе эти числа ничего не говорят, то зачем ты смотришь в код?
В том то и дело что значат.
И я бы это кон не писал тяп ляп.
Я бы сделал константные переменные и добавил комментарий почему и зачем.
> Хм.. на раст код не похож. Так что твое замечание познавательно, но не более.Это ты верно подметил, я чисто для познавательных целей и писал это. Более того, он коммент о познавательности использования unreachable!().
> Наверное твой макрос нужен только неопытным програмистам, а вот настоящие СИшники могут и без него)
Может быть, но проблема в том, что опытный программист отличается от неопытного только тем, что он громче падает. У сишников просто голова дубовая, им не страшно по лбу граблями получать.
> Я бы сделал константные переменные и добавил комментарий почему и зачем.
Если кому-то нужны комментарии почему и зачем, значит им эти числа ни о чём не говорят, а значит прежде чем лезть своими грязными ручками в код, им следует сделать RTFM.
Я тоже был большим фанатом комментариев, но последнее время я начинаю подозревать, что комментарии нужны только документационные и только для тех, кто использует код извне через внешний API. Вот этот API должен быть документирован. А всё остальное комментировать противопоказано, потому что комменты создают иллюзию понимания кода, и потом человек с ложной самоуверенностью начинает менять его, не понимая всех нюансов, а страдают от этого все.
Специально запутывать код не стоит и стоит стремиться к простоте кода, но в ситуациях типа этой, когда от сложных условий никуда не деться, комментарии вредны. Человеку следует как следует курить этот код и документацию, до тех пор пока код не станет кристально ясным без комментариев, и только после этого ему можно приступать к правкам.
Комменты могут быть полезны если ты описываешь там инварианты или ещё какие-то базовые положения, поверх которых код построен. Можно между делом упомянуть название используемого алгоритма и его автора, чтобы легко можно было бы найти статью и почитать, если очень нужно. Стоит тогда уж упомянуть и модификации алгоритма, которые ты привнёс. Но писать комментарии, типа "тут мы сравниваем с константой объявленной в <как там дока на стандарт utf8 называется?>" -- излишне совершенно.
> А всё остальное комментировать противопоказано, потому что комменты создают иллюзию
> понимания кода, и потом человек с ложной самоуверенностью начинает менять его,
> не понимая всех нюансов, а страдают от этого все.С одной стороны это так. С другой - комментарии как раз могут указывать на неочевидные нюансы. Потому что в своей практике очень часто встречал код, в котором абсолютно понятно "что" он делает, но не понятно "зачем". Обычно это какая-то бизнес-логика, и найти причины принятия решения по тому или иному поведению тот еще челлендж.
> Но писать комментарии, типа "тут мы сравниваем с константой
> объявленной в <как там дока на стандарт utf8 называется?>" -- излишне совершенно.Но как минимум будет название стандарта (можно еще № страницы указать или параграфа).
И при баге в таком коде первое что сделают - пойдут в стандарт и сверят константы.
> Потому что в своей практике очень часто встречал код, в котором абсолютно понятно "что" он делает, но не понятно "зачем". Обычно это какая-то бизнес-логика, и найти причины принятия решения по тому или иному поведению тот еще челлендж.Для этого есть git blame и история git в целом. Комменты редко в таких случаях помогают, потому что они имеют тенденцию устаревать и не соответствовать действительности. История же изменений кода часто позволяет понять предназначение кода даже в тех случаях, когда комменты к коммитам абсолютно неадекватны. Если же всё не так плохо, то ты найдёшь все ответы в сообщениях к коммитам, и много чего ещё найдёшь, о чём даже не задумывался. Мало того, иногда есть возможность связаться с автором изменений и потрясти его, чтобы узнать что именно он думал, когда писал код, и может даже получить консультацию на тему того, как лучше внести в этот код те модификации, которые ты хочешь внести.
> И при баге в таком коде первое что сделают - пойдут в стандарт и сверят константы.
Если им надо сверять константы, то им нечего делать в этом коде. Не, ну вот например, в досе часто попадалась команда int 21h. Если человек не понимает, что это вызов прерывания доса, то ему следует отправляться читать документацию, причём не какую-то страницу или параграф, а начиная с заголовка и заканчивая указанием типографии, где эта документация печаталась.
Константам нужны символические имена тогда, когда есть хотя бы малейший шанс на то, что константа может измениться. Им нужны символические имена тогда, когда эти константы были придуманы программистом. Им нужны имена тогда, когда эти имена короче, чем константа (M_PI, например, короче чем перечисление всех десятичных знаков). Возможны всякие другие ситуации, но эта не подпадает ни под одну из них. Константы фиксированы стандартом, более того, здесь используются не они, а производные от них, в стандарте указаны 32-х битные значения, здесь же 8-битные. Создание констант под каждое значение байта займёт больше места, чем сам кодер/декодер utf8. Использование же этих констант в коде кодера/декодера, раздует его размер в разы. Сомнительное повышение читабельности кода, не так ли?
>Для этого есть git blame и история git в целом. Комменты редко в таких случаях помогают, потому что они имеют тенденцию устаревать и не соответствовать действительности.Что проще: прочитать один комментарий или перелопачивать историю комитов? А комменты надо просто поддерживать в актуальном состоянии.
>Мало того, иногда есть возможность связаться с автором изменений и потрясти его, чтобы узнать что именно он думал, когда писал код, и может даже получить консультацию на тему того, как лучше внести в этот код те модификации, которые ты хочешь внести.
Иногда автор сам не помнит, зачем он это сделал. И только адекватные комментарии помогают.
>это макрос unreachable!(), который говорит компилятору, что код unreachableЗависимые типы не изобретены, а компилятор сам не догадается.
musl-0.9.13 Вышла 30 августа 2013 года
То есть внедрённый бекдор заметили лишь спустя 12 лет. Вот вам и безопасный опенсорс. Вот вам и тысячи глаз.
Щас набигут фанаты и ответят:
0. Это не бекдор, все ошибаются!
1. Зато же нашли! Значит 100500 глаз работают.
2. А что в вашей проприетаре лучше?
3. .....
Вот видишь даже сам понимаешь что все в порядке.
Неа, это не нормально.
Я это взял из книжки "100500 отмазок почему овнякод это хорошо", написанное 'настоящими программистами'))
> musl-0.9.13 Вышла 30 августа 2013 года
> То есть внедрённый бекдор заметили лишь спустя 12 лет. Вот вам и
> безопасный опенсорс. Вот вам и тысячи глаз.Ага, уязвимость в кодировке лохматого года для корейского языка, которой на 2013 год уже не пользовались сами корейцы -- это мега-опасная дыра, поставившая под угрозу существование человечества. Нужно срочно спасать галактику! :-)))))
Ага, ведь северокорейских хакеров не существует!
Это все придумки капиталистических южан.
И вообще наш Ын няшка и его народ любит!!
Ну предположим существуют
Но кого они ЭТИМ будут ломать?
Кодировка мертвая, да еще и «уязвимость» в мюслях
Страшно представить как долго они будут искать кого бы так сломать
Неужели столмановский libc лутше этого? libc же сильно луддитный, как говорит молодежь!
Дыра, нацеленная на корейцев?
> Дыра, нацеленная на корейцев?146%!
Не пробегал ли там Jin Tan?
Надо бы проверить))
Тут даже далеко ходить не надо все ясно. Северные корейцы внедрили против южных.
Если начнут рассылать письма куда угодно с указанной в заголовке с MIME-типом (например, "text/plain; charset=EUC-KR"), то всем прилетит.
> Если начнут рассылать письма куда угодно с указанной в заголовке с MIME-типом
> (например, "text/plain; charset=EUC-KR"), то всем прилетит.У 99% не-корейцев такое сразу попадёт в спам, откуда будет удалено без открытия. У тех, кто всё же попытается открыть, если там вообще муслик в качестве системной библиотеки будет вместо глибцы, максимум вылетит браузер или почтовый клиент.
Никому не прилетит!
Ибо xpен ты в живой природе встретишь какой нить MUA и musl в одном флаконе :)Так что накидывайте тщательнее спасатели галактоГо! ;-)
Alpine, PostmarketOS, да и в OpenWRT, вдруг, найдётся какой-нибудь mutt.
>EUC-KRЧо за кодировка такая? Какой негодяй в 2025 году не перешёл на Unicode?
зачем далеко ходить, opennet:
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=koi8-r"> (рукалицо.jpg)
Сишники вместе с плюсовиками не умеют работать не только с форматами данных типа json и xml, но и с кодировками.
шел 2025 год, сишники всё еще продолжали скакать по граблям xDхотя бы уже на zig переходили, позорище какое-то
Для языка, не привносящего ничего нового в плане типов у него слишком долго нет стабильной версии
я помню много проектов, которые начинались как musl, типа деды переусложняли код, понять невозможно.Так начинался MySQL, wayland и даже гуглохром. В итоге эти проекты неизменно становятся тем, против кого выступаали.
> я помню много проектов, которые начинались как musl, типа деды переусложняли код, понять невозможно.А это была не правда)?
> Так начинался MySQL, wayland и даже гуглохром. В итоге эти проекты неизменно становятся тем, против кого выступаали.
Э...? Может они и стали сложными, но дают гораздо больше возможностей.
MySQL стал фактически стандартом, до появления новых БД.
Wayland это отличный пример как надо делать: выкинули все, добавляем только необходимое (а не всякую чушь типа сетевой прозрачности)
Хром - это наверное один из самых успешных проектов в мире, по кол-ву пользователей.