The OpenNET Project / Index page

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

Выпуск системной библиотеки Glibc 2.33

02.02.2021 11:20

После шести месяцев разработки опубликован релиз системной библиотеки GNU C Library (glibc) 2.33, которая полностью следует требованиям стандартов ISO C11 и POSIX.1-2017. В состав нового выпуска включены исправления от 72 разработчиков.

Из реализованных в Glibc 2.33 улучшений можно отметить:

  • В компоновщике (dynamic linker), отвечающем за динамическую загрузку и связывание разделяемых библиотек при запуске программы, реализована поддержка загрузки оптимизированных реализаций разделяемых объектов из подкаталогов glibc-hwcaps, созданных в областях ФС, просматриваемых при поиске библиотек. В настоящий момент реализованы подкаталоги "x86-64-v2", "x86-64-v3" и "x86-64-v4" для архитектуры x86_64-linux-gnu, "power9" и "power10" для архитектуры powerpc64le-linux-gnu, "z13", "z14" и "z15" для s390x-linux-gnu. В случае архитектуры x86_64-linux-gnu имя подкаталога выбирается в зависимости от версии psABI.
  • В компоновщик также добавлены флаги: "--list-tunables" для вывода всех поддерживаемых внутренних настроек поведения Glibc, "--argv0" для изменения строки argv[0], в которой содержится название текущего исполняемого файла, и "--help" для вывода подсказки и информации о проверяемых файловых путях.
  • Добавлена функция mallinfo2, которая также как mallinfo выводит статистику о распределении памяти, но с большим размером полей, позволяющим выводить значения, не умещающиеся в тип integer.
  • Добавлен заголовочный файл <sys/platform/x86.h> с макросами для проверки функциональных возможностей x86 CPU.
  • Добавлена поддержка 32-разрядных систем на базе архитектуры набора команд RISC-V (ISA rv32imac, rv32imafdc и rv32imafdc). Для работы 32-разрядного порта RISC-V требуется как минимум ядро Linux 5.4, GCC 7.1 и binutils 2.28. 64-разрядный порт RISC-V поддерживается начиная с Glibc 2.27.
  • Добавлен новый режим защиты "_FORTIFY_SOURCE=3", предназначенный для определения во время компиляции и во время работы возможных переполнений буфера при выполнении строковых функций, определённых в заголовочном файле string.h. Отличие от режима "_FORTIFY_SOURCE=2" сводится к дополнительным проверкам, которые потенциально могут приводить к снижению производительности. На стороне компилятора режим пока поддерживается только в LLVM 9 (в GCC ещё не реализован).
  • Объявлена устаревшей функция mallinfo. Удалена функция vtimes (оставлена заглушка для сохранения совместимости) и заголовочный файл <sys/vtimes.h>.
  • При вызове dlopen из программ со статическим связыванием прекращена загрузка альтернативных библиотек из подкаталогов HWCAP. В будущих выпусках glibc решено прекратить загрузку разделяемых объектов из подкаталогов tls. Приложениям следует перейти на новый механизм glibc-hwcaps.
  • В Linux прекращена корректировка прав доступа к устройствам терминала силами Glibc. Администраторам теперь нужно следить за режимом доступа к /dev/pts самостоятельно, но изменение во многом формальность, так как в большинстве систем давно выставляются необходимые значения (группа tty, право чтения/записи для пользователя и право записи для группы).
  • Функции posix_openpt и getpt больше не пытаются использовать устаревшие псевдотерминалы в Linux и при наличии /dev/ptmx считают псевдо-ФС devpts примонтированной к /dev/pts.
  • Устранены уязвимости:
    • CVE-2019-25013 - переполнение буфера при обработке в функции iconv строки в кодировке EUC-KR, включающей некорректные многобайтовые последовательности (например, echo -en "\x00\xfe" | iconv -c -f EUC-KR -t "UTF-8"). По мнению инженеров из Red Hat эффект от уязвимости ограничивается крахом, а проблема проявляется только при явном использовании кодировки EUC-KR.
    • CVE-2021-3326 - крах из-за срабатывания assert-проверки при преобразовании символов ISO-20022-JP-3 при помощи функции iconv из-за выхода результирующей строки за конец буфера на два символа.
    • CVE-2020-27618 - зацикливание при обработке в iconv определённых последовательностей символов в кодировках IBM1364, IBM1371, IBM1388, IBM1390 и IBM1399.
    • CVE-2020-29562 - крах из-за срабатывания assert-проверки при обработке в функции iconv некорректных символов в кодировке UCS4.


  1. Главная ссылка к новости (https://sourceware.org/piperma...)
  2. OpenNews: Выпуск системной библиотеки Glibc 2.32
  3. OpenNews: Выпуск стандартной Си-библиотеки PicoLibc 1.5
  4. OpenNews: Разработчики из Google предложили разработать свою libc для LLVM
  5. OpenNews: Представлена стандартная Си-библиотека Musl 1.0.0, развиваемая в качестве альтернативы Glibc
  6. OpenNews: Cosmopolitan - стандартная Си-библиотека и формат кроссплатформенных исполняемых файлов
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/54508-glibc
Ключевые слова: glibc, libc, gcc, llvm
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (79) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:59, 02/02/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Список уязвимостей намекает на правоту доводов тех, кто остаётся на простых 8-битных кодировках. 20 лет уже прошло с повального перехода на Unicode, а всё те же детские проблемы продолжают всплывать и конца этому не видно.
     
     
  • 2.4, Аноним (4), 12:05, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    CVE-2019-25013 очень нехорошие впечатления производит, как бы не всплыл эксплоит, позволяющий атаковать любые приложения, вызывающие iconv. Год в CVE тоже напрягает. Они два года не исправляли баг или держали в секрете информацию о дыре?
     
     
  • 3.7, Аноним (7), 12:10, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    О чем ты через юникод символы даже айфоны атаковали, вплоть до перезагрузки при получении символа. А Эплу прям не все равно на такие уязвимости. А тем кто делает iconv им то точно пофиг.
     
  • 3.57, Аноним (57), 19:35, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Очевидно, на EUC-KR всем более-менее класть.
     
  • 2.5, Аноним (7), 12:07, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Вместо программистов деньги надо платить тестировщикам. Программисты не нужны. Нужны тестировщики, которые будут тестировать выход из нейросетей.
     
     
  • 3.10, КО (?), 12:16, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +5 +/
    А исправит всё это дед Михалыч.
     
     
  • 4.14, Аноним (14), 12:59, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Нейросеть пусть исправляет за что ей деньги платять... ой, то есть электричество тратят.
     
     
  • 5.30, Аноним (30), 13:41, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Скайнет получится, но потом. А пока посмотрите фильм, сценарий для которого написала нейросеть. Бессмысленная бессмыслица.
     
     
  • 6.34, Dr. Polito (?), 14:28, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Скайнет получится, но потом. А пока посмотрите фильм, сценарий для которого написала нейросеть. Бессмысленная бессмыслица.

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

     
  • 6.37, Аноним (37), 14:39, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ты так пишешь как будто скайнет это что-то плохое.
     
     
  • 7.42, cvbxcbvxcvbxcvb (?), 15:09, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    слава роботам!!!!
     
     
  • 8.48, 1 (??), 16:33, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    УВЧ ... текст свёрнут, показать
     
  • 5.71, Аноним (-), 22:38, 03/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Неизбежны только сметь и налоги (на роботов ;) !
     
  • 3.49, DildoZilla (?), 17:01, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Чем тупее программисты, тем нужнее тестировщики.
     
     
  • 4.77, антон (??), 00:24, 02/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Не верно. Тупой прогер будеи больше времени фиксить баги. Умный - больше пилить фичи, производя новые баги.
     
  • 2.8, Аноним (8), 12:15, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Пару лет назад десяточка сразу улетала в бсод при открытии текстового файла с utf-8 в notepad++ и некоторых других программах. Этот utf-8 был корректный на линуксе, но некорректный на венде и макос. Такие вот детские проблемы у неё, 30 лет уже тащат.
     
     
  • 3.15, Аноним (15), 13:02, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А что, в Винде преобразования кодировок выполняются в ядре, что от их проблем в BSOD?
     
     
  • 4.20, Аноним (8), 13:16, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > А что, в Винде преобразования кодировок выполняются в ядре, что от их
    > проблем в BSOD?

    Надо было создать такой файл ещё, но мне к тому времени уже надоело перезагружаться и я сохранил тот файл в utf-16 -- с ней проблем не возникло. А потом и вовсе выкинул венду из процесса.

     
  • 3.66, Аноним (66), 10:11, 03/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Зказошник, однако
     
     
  • 4.69, Аноним (8), 10:51, 03/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Зказошник, однако

    Я сам был в шоке от такого бага, но это в целом типичный уровень венды.

     
  • 2.12, Аноним (12), 12:44, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Интероперабельность ваших 100500 простых 8-битных кодировок где-то у плинтуса. Не пойдёт.
     
  • 2.60, Ordu (ok), 23:05, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ещё лучше выкинуть компьютеры. Тогда точно никаких уязвимостей не будет.
     

  • 1.2, InuYasha (??), 11:59, 02/02/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    >реализована поддержка загрузки оптимизированных реализаций

    о-о-о-о. о-о-о-о! теперь можно забыть про VectorAngles_SSE, VectorAngles_3DNOW, VectorAngles_AVX и выбор VectorAngles = кому-то из них? Ну, круто, чо. Джвадцать лет ждал.

     
  • 1.3, Аноним (3), 12:00, 02/02/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    >В Linux прекращена корректировка прав доступа к устройствам терминала силами Glibc. Администраторам теперь нужно следить за режимом доступа к /dev/pts самостоятельно

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

     
     
  • 2.13, Анонимомоним (?), 12:46, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем системе делать двойную работу?
     
     
  • 3.16, Аноним (14), 13:04, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Зачем тогда нужна система, если у неё даже банального резервирования функционала нет?
     
     
  • 4.17, Кхекхе (?), 13:10, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    [анекдот про три билета и проездной]
     
  • 4.67, YetAnotherOnanym (ok), 10:41, 03/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Затем, чтобы каждая её составная часть занималась своим делом.
     

  • 1.6, Аноним (6), 12:08, 02/02/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Чем оно лучше musl и uClibc?
     
     
  • 2.9, Таненбаум (?), 12:15, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    тем, что классика
     
     
  • 3.18, Аноним (18), 13:16, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Так понимаю даже если доплатить, ничего не будет?
     
     
  • 4.52, ХрюХрю (?), 17:12, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну все, ждет glibc на расте!
     
  • 2.11, Аноним (30), 12:41, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Сравнение: http://www.etalabs.net/compare_libcs.html
     
     
  • 3.23, flkghdfgklh (?), 13:21, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Сравнение от разрабов musl? Ню-ню
     
     
  • 4.27, Аноним (30), 13:30, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ну хоть какое-то. Давай другое.
     
  • 3.26, Аноним (14), 13:26, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Т.е. для операция c UTF надо использовать musl, а для всего остального достаточно Glibc? Звучит как мегавелосипед, надо попробовать.
     
  • 2.28, омоним (?), 13:30, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    https git musl-libc org cgit libc-bench CFLAGS -O3 -march native -mtune nat... большой текст свёрнут, показать
     
  • 2.31, Аноним (31), 13:48, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Тем, что оно работает, в отличие от?
     
     
  • 3.35, Аноним (30), 14:30, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Это утверждение или вопрос?
     

  • 1.19, Аноним (19), 13:16, 02/02/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А как лучше всего засанитайзить юникод ? Ну чтоб и набор стандартных буковок был для языков не затронут.
     
     
  • 2.25, flkghdfgklh (?), 13:22, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > набор стандартных буковок

    Это каких? Что такое «стандартные буковки»? Ты в курсе, что бывает не только латиница и русская кириллица, но еще с десяток кириллиц, два десятка латиниц, а так же греческий, грузинский, армянский и прочие алфавиты, которые в разы старше той же кириллицы и вполне живы и используются?

     
     
  • 3.44, Аноним (-), 15:22, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Потому и спрашиваю о наличии готового решения.
     
  • 2.61, Ordu (ok), 23:28, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Что ты имеешь в виду под "засанитайзить"? Простейшая валидация сводится к тому, чтобы разбить поток байт на char'ы таким образом, чтобы:

    а. если старший первого байта 0, то это однобайтовый чар
    б. если старшие биты первого байта 10, то это двухбайтовый чар, и следующий байт должен иметь 10 в старших двух битах
    в. если старшие биты первого байта 110, то это трёхбайтовый чар, и следующие 2 байта должны иметь 10 в старших двух битах
    г. если старшие биты первого байта 1110, то это четырёхбайтовый чар, и следующие 3 байта должны иметь 10 в старших двух битах.
    д. если мы добрались до сюда, значит пора запускать процесс обработки ошибки InvalidUTF8.

    Все "стандартные буковки" попадают в пункт (а), и они не будут затронуты, потому как старший бит у них 0.

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

    Если же тебе хочется справляться с ошибками, то заменяй все байты, которые не удалось декодировать на '?', и всё. Будет по-уродски, но тут всё просто: нефиг инвалидный utf8 пихать в программу, и не будет уродства.

     
     
  • 3.63, Аноним (63), 05:54, 03/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Что ты имеешь в виду под "засанитайзить"

    Опасные диапазоны для всяких имен и неожиданные кавычки с прочими неожиданно "поддерживаемыми" ништяками для фс, баз, жысоноф и всей такой фигни

     
     
  • 4.65, Ordu (ok), 09:45, 03/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >> Что ты имеешь в виду под "засанитайзить"
    > Опасные диапазоны для всяких имен и неожиданные кавычки с прочими неожиданно "поддерживаемыми"
    > ништяками для фс, баз, жысоноф и всей такой фигни

    Анрил. Обезопасить строку от всего-всего-всего -- это анрил. Либо поумерить хотелки и широту покрываемых санитайзером кейсов, либо ограничивать допустимые чары предикатом is_ascii_alphanumeric. Под любое послабление этого предиката можно придумать кейс, когда это приведёт к беде. Хотя даже так плохо -- если оно иногда alpha, а иногда numeric, то какой-нибудь библиотеке в программе может сорвать крышу, когда она, скажем, напорется на 0xfffffffffffffffffffffffffffffffffff, ей переполнит 128 битный целочисленный тип, и хрен её знает, что она сделает дальше. Начнёт читать последующие буквы как хекскод, чтобы записать его на стек, включить исполняемость стека и сделать call %esp? От программистов и их программ никогда не знаешь чего ожидать.

     
     
  • 5.70, Аноним (-), 11:11, 03/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Что-то такое и "Ну чтоб и набор стандартных буковок был для языков не затронут.". У меня вот с лингвистрисизмусомством полная беда, может быть есть готовые решения какбы.
     
  • 3.72, adolfus (ok), 04:52, 06/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Это вы про utf8, но кроме нее есть еще четыре -- utf{16|32}{b|l}
    И в довесок к этому каждая может имет, а может и не иметь сигнатуру в начале файла. Итого 10 вариантов.
    Мало того, вдобавок к этим десяти есть овердофига разных 8-байтных кодировок. Попробуй сразу разберись, что перед тобой.
     
     
  • 4.73, Ordu (ok), 05:22, 06/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Это вы про utf8, но кроме нее есть еще четыре -- utf{16|32}{b|l}
    > И в довесок к этому каждая может имет, а может и не
    > иметь сигнатуру в начале файла. Итого 10 вариантов.
    > Мало того, вдобавок к этим десяти есть овердофига разных 8-байтных кодировок. Попробуй
    > сразу разберись, что перед тобой.

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

     
  • 3.78, антон (??), 00:29, 02/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Грамотно!
     
     
  • 4.79, Ordu (ok), 02:37, 02/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Неа, неграмотно. Я там напутал с первыми байтами, там должны быть значения 110..., 1110..., 11110...,  чтобы взяв произвольный байт из потока можно было бы определить, является ли он первым байтом чара или байтом-продолжением (байт-продолжение выглядит как 10...). Я не люблю править уже написанные сообщения, считая что сказанное должно оставаться сказанным, и поэтому ждал когда мне укажут на косяк, чтобы довести до завершения, но никто не указал. И я забыл об этом.
     

  • 1.21, ryoken (ok), 13:18, 02/02/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Во, хоть кто-то не гонится, высунув язык, за нумерацией вида 100500.
     
     
  • 2.32, Аноним (15), 14:14, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ну всё же, к нумерациям вида 3.x уже перейти можно.
     

  • 1.22, Fracta1L (ok), 13:19, 02/02/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Вот это криворукие у glibc программисты, если на прекрасном Си допускают переполнение буфера. Это же банальнейшая вещь, с которой справится любой джун из комментов Опеннета.
     
     
  • 2.24, Аноним (14), 13:22, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Язык тебя никак не защитить от кривых рук. Так зачем использовать другой язык если дело в руках?
     
     
  • 3.29, Fracta1L (ok), 13:31, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Вот я и говорю - даже в glibc не нашлось кодеров с прямыми руками. Потому что все они в комментах Опеннета обитают.
     
     
  • 4.36, Аноним (37), 14:38, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Просто чтобы ты понял Раст не нужен. А ты обычный фанбой, который скоро закончит школу и забудет про это всё.
     
  • 4.56, Fracta2L (?), 19:11, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • –3 +/
    А у тебя прямые руки?
     
     
  • 5.62, FractaL (ok), 00:17, 03/02/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А у тебя прямые руки?

    Нет, и растут из нижних полушарий мозга.

     
  • 3.33, Аноним (33), 14:25, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Зачем добавлять синхронизатор в кп авто, нужны просто прямые руки. Зачем изолировать провода, только рукожоп может дотронуться до оголенного. Зачем закрывать шестерни станка щитком, только криворукий сможет туда сунуть свои рученки.

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

     
     
  • 4.38, Сишник (?), 14:47, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Так оно что с проверкой крашнулось бы, что без - в обоих случая это баг и надо исправлять.
     
     
  • 5.41, Аноним (33), 15:03, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    При крэше вы хоть узнаете что что-то пошло не так.
    А если мы выходили за пределы массива (строка напр.) и там по счастливой случайности всего был \0, то об этом узнают только когда там окажется что-то другое.
     
     
  • 6.43, Сишник (?), 15:18, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Да, можно санитайзер включить, погонять прогу и отловить краши. Даже на сях без проверок. Нужно ли чтобы санитайзер был встроен в язык и не отключался - спорный вопрос. Свобода выбора средств есть и это хорошо.
     
  • 4.39, Сишник (?), 14:49, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Зачем закрывать шестерни станка щитком, только криворукий сможет туда сунуть свои рученки.

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

     
  • 4.40, Аноним (33), 15:00, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Не обязательно бросать исключение. Можно вернуть ошибку (хотя бы int или bool, если язык не дает ничего более вменяемого типа optional или tuple).
    Плюс в некоторых случаях намного лучше чтобы программа просто упала, чем выдала неверный результат.

    Главное чтобы нужно было проверять ограниченное количество мест внутри объекта чтобы минимизировать (не полностью исключить, а уменьшить шанс на пару порядков) вероятность ошибки. И покрыть тестами один объект существенно легче чем кучу кода.

     
     
  • 5.47, Сишник (?), 16:05, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Не обязательно бросать исключение. Можно вернуть ошибку (хотя бы int или bool,
    > если язык не дает ничего более вменяемого типа optional или tuple).

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

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

    да

    > Главное чтобы нужно было проверять ограниченное количество мест внутри объекта чтобы минимизировать
    > (не полностью исключить, а уменьшить шанс на пару порядков) вероятность ошибки.
    > И покрыть тестами один объект существенно легче чем кучу кода.

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


     
  • 4.45, Аноним (-), 15:25, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Зачем писать нормальные структуры данных,

    Вот и не надо , если тебе надо - сделай но только для себя. А лучше иди вон раст учи.

     
  • 3.50, DildoZilla (?), 17:03, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Кривая и косая дрель рано или поздно запорет высверливание правильной и ровной дырки. Так что си -- кривой инструмент, для использования которого приходится искривлять мозги и руки прогерам. Отсюда и кривопопие, конца которому не видать.
     
     
  • 4.64, Аноним (-), 08:56, 03/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Си просто повторяет архитектуру компьютера. Ты лучше, скажи инженерам Интела и АМД что у них компьютеры кривые.

    Си такой, потому-что компьютеры такие. Ну, что дошло?

     

  • 1.46, Аноним (46), 15:58, 02/02/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Жду, когда арчик пересоберут хотя бы под x86-64-v2. Нужно больше оптимизаций под современные процессоры.
     
     
  • 2.51, Аноним (51), 17:11, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Лучше будет если сразу для x86-64-v4. Для Арчевода ты какой-то консервативный.
     
  • 2.54, омоним (?), 17:54, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Есть Garuda Linux с кучей ядер, скомпилированных под определённый процессор.
     
     
  • 3.55, омоним (?), 17:59, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    У меня, например, Artix с подключенными репами chaotic-aur.
    Чего и всем арчеводам желаю.
     

  • 1.53, solardiz (ok), 17:47, 02/02/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Кстати, из ожидания подобных уязвимостей, мы в blists, когда добавляли туда поддержку iconv, разрешили только реально сколько-нибудь распространенные кодировки. Их список оказался не таким уж маленьким, но пока пересечения с перечисленными в новости нет:
    https://github.com/openwall/blists/blob/99ca31b9ac49429c114a166d7801662ecaad05
     
     
  • 2.58, Аноним (8), 20:47, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ой, китайские это очень зря. Японские я бы тоже запретил. И хинди с ивритской вязью (чисто на всякий случай). Просто из-за того как они устроены и потому, что в юникоде они имеют платформозависимые символы (ты декодируешь на линуксе и у тебя всё нормально, а потом оказывается, что все приложения на венде крашатся, да и сама она в бсод улетает).
     
     
  • 3.59, solardiz (ok), 21:10, 02/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Может и зря, но они реально встречались в недавних сообщениях в списках рассылки по Linux и Open Source, и после их разрешения корректно отображались в браузере (в utf-8, под Linux). Не хотелось искусственно ломать то что иначе просто работает.
     

  • 1.68, YetAnotherOnanym (ok), 10:45, 03/02/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > при наличии /dev/ptmx считают псевдо-ФС devpts примонтированной к /dev/pts

    Ээээ... это "считают" вызывает у меня тревожные мысли. Когда код "считает", вместо того, чтобы честно вывалиться в ошибку - это чревато, ящетаю.

     
  • 1.74, Аноним (74), 18:03, 06/02/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ну ОК, а как собрать его с оптимизацией для конкретного железа?
    Сейчас сыпит ошибками "ISA not compatible" и т.д.
     
  • 1.75, Аноним (75), 10:22, 14/02/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Добавить libc_cv_include_x86_isa_level=no
     
  • 1.76, Аноним (76), 10:34, 19/02/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Добавлен новый режим защиты "_FORTIFY_SOURCE=3", предназначенный для определения во время компиляции и во время работы возможных переполнений буфера

    Ждем поддержки в gcc и добавляем в make.conf
    CFLAGS= .... -D_FORTIFY_SOURCE=3

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



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

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