| 1.2, Аноним (2), 18:01, 22/07/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –21 +/– |
> Устранены уязвимости:
> - CVE-2024-2961 - переполнение буфера ...
> - CVE-2024-33599 - переполнение буфера ...
> - CVE-2024-33600 - разыменование нулевого указателя ...
> - CVE-2024-33601 - ошибка при работке с кэшем ... из-за сбоя при выделении памяти
> - CVE-2024-33602 - повреждение памяти при работе с кэшем ...
Срочно писать письмо разрабам с требованием переписать Glibc на Rust!
| | |
| |
| 2.7, Аноним (-), 18:18, 22/07/2024 [^] [^^] [^^^] [ответить]
| +28 +/– | |
> Срочно писать письмо разрабам с требованием переписать Glibc на Rust!
Вот ты и попался любитель Раста!
СИшка это лучшее что изобрело человечество!
Эти все ошибки только потому, что уровень программистов опустился на дно.
Настоящий СИ программист всегда проверяет входные данные, выделяет столько памяти сколько нужно и правильно ее освобождает.
| | |
| |
| 3.24, Аноним (24), 19:59, 22/07/2024 [^] [^^] [^^^] [ответить]
| +6 +/– |
Тонко, тонко... Но одного единственного на всю планету настоящего си-программиста Дэниэла Бернштейна на все программы мира не хватит
| | |
| |
| 4.53, BeLord (ok), 09:45, 23/07/2024 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Достаточно нормальных С программистов, проблема в том, что эти ребята привыкли делом заниматься, а не свистоперделки ваять и менеджерский идиотизм переваривают с трудом, потому, что привыкли думать о результатах, а так как лохотронщики от псевдомаркетинга победили, то пользователь будет довольствоваться хламом от вебмартышек.
И просто пример, софт для системы навигации написан на С/аsm в 2008, железо, где этот софт крутится летает на орбите уже больше 15 лет и память не течет, сбоев не зафиксировано.
| | |
| |
| 5.62, Телеметрия (?), 12:34, 23/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
Будто программисты на Си много пишут,дописывают и исправляют уж лучше сказать.Хрустеры вот не могут так.Некуда свои закорючки дописывать.Такая же элита как и сишники и вообще программисты в целом. Давно кончились советские инженеры и примазываться к ним вам всем дружно плохая идея.Бгг.
| | |
| |
| 6.90, Аноним (90), 14:10, 24/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
а код туда чтоли запаян? насколько знаю вояджеры перепрограммируют под реалии по ходу полета, и таки там были ошибки в коде
| | |
|
|
|
| 3.87, Аноним (-), 08:37, 24/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Настоящий СИ программист всегда проверяет входные данные, выделяет столько
> памяти сколько нужно и правильно ее освобождает.
А что за клизмы тогда код Xorg писали? Это подделки были? Ведь такая хренота в коде 1988 года выпуска?!
| | |
| |
| 4.89, Аноним (-), 13:24, 24/07/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> А что за клизмы тогда код Xorg писали? Это подделки были? Ведь такая хренота в коде 1988 года выпуска?!
Значит это были Не Настоящие Сишники, все просто.
Может их подбросили в проект, чтобы они плохо писали и дисредитировали Идеальный Язык Программирования!
Надо проверить, вдруг они в свободное время на паскале пописывали.
| | |
| |
| |
| 6.94, Аноним (-), 12:28, 02/08/2024 [^] [^^] [^^^] [ответить]
| +/– |
> not a true Scotsman: https://en.wikipedia.org/wiki/No_true_Scotsman
> Чеснслова уже в зубах завяз этот аргумент. Можно включить креативность и придумать что-нибудь новенькое для обеления C?
Один из вариантов Закона По гласит что "Любой достаточно развитый тролль неотличим от подлинно помешанного на какой-либо идее."
Так вот ты троллинг не распознал)
| | |
|
|
|
|
| 2.19, Аноним (19), 19:18, 22/07/2024 [^] [^^] [^^^] [ответить]
| +/– | |
>Срочно писать письмо разрабам с требованием переписать Glibc на Rust!
Вот тут-то точно случится Stable and unstable ABI is nonsence.
| | |
| 2.20, Аноним (20), 19:18, 22/07/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
Не проверяли, что из этого написано "дидами" четаерть века назад, а что новой порослью?
| | |
|
| 1.4, Аноним (4), 18:09, 22/07/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Единственное с чем ассоциируется у меня libc это с отсутствием обратной совместимости...
| | |
| |
| 2.8, Аноним (-), 18:28, 22/07/2024 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Единственное с чем ассоциируется у меня libc это с отсутствием обратной
> совместимости...
Потому что как завещал Самый Главный - stable api is nonsense.
Ну и усе остальное стабль тоже нонсенс.
Ведь пользователи как радостно прыгают, когда версия приложения работает только с определеннной версией ядра.
| | |
| |
| 3.16, Аноним (19), 19:04, 22/07/2024 [^] [^^] [^^^] [ответить]
| +6 +/– |
Главный про ядро говорил. Также говорил, что поломки юзерспейса не допустит.
| | |
| 3.21, Аноним (21), 19:25, 22/07/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> stable api is nonsense
у тебя есть конкретные возражения к тому документу?
| | |
| 3.29, Аноним (29), 22:04, 22/07/2024 [^] [^^] [^^^] [ответить]
| +2 +/– |
Но ведь обратное утверждение. Это поддерживать Легаси тысячилетиями. Из двух зол Легаси или отсутствие стабильности нормальный человек выберет второе.
| | |
| |
| 4.30, Аноним (30), 22:09, 22/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
Нормальный человек, конечно, выберет первое, а вот ленивый разработчик — второе.
| | |
| 4.32, Анонин (-), 22:53, 22/07/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Но ведь обратное утверждение. Это поддерживать Легаси тысячилетиями.
Nope. Это две разные, но связанные вещи.
Можно поддерживать море всякого древнего омна и некроплафторм.
При этом умудряясь ломать обратную совместимость везде.
А потом героически всё чинить. Вот линукс это практически оно.
Только ты не всегда даже знаешь что какая-то платформа сломалась уже несколько лет назад, потом что все ее пользователи уже в доме престарелых. А потом появляется какой-то какир с купленной не гаражной распродаже железкой, который начинает вопить "аааа! вся сламалася!"
| | |
|
| 3.35, Аноним (35), 00:37, 23/07/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Блин, stable-api-nonsense всё-таки великая статья. Подрывает ламеров уже почти третий десяток лет. Опустим, что ее написал не самый главный, а Грег К-Х и что там речь идёт о внутри ядерных интерфейсах)
| | |
| |
| 4.40, User (??), 05:19, 23/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
Не, ну если цель была в "подрывании ламеров", то да - "великая цель великой статьи достигнута" - правда работать целеполагателю надо не в it, а в стендапе - цель так же достигнется, а вреда окружающим меньше.
А так - да, в "манифесте agile" тоже вот не написано "забейте на документацию" - но норот читает дупой и эгегей! Впрочем, даже если бы норот читал написанное головой - количество проблем с теми же драйверами от "нонсенса" ничуть бы не уменьшилось...
| | |
| 4.64, Аноним (-), 13:09, 23/07/2024 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> и что там речь идёт о внутри ядерных интерфейсах)
Речь могла идти про что угодно.
Но по факту оно более чем применимо к ядру целиком, иначе у нас не было бы столько проблем с драйверами, прибитыми ржавыми гвоздями к конкретной версии ядра.
| | |
| |
| 5.70, Аноним (70), 14:47, 23/07/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Они прибиты из-за того, что люди, вроде автора высказывания, нарушают совместимость и осознанно ломают сборку сторонних модулей в районе версии x.y.255, вместо того, чтобы оставить такие изменения для новой ветки, только потому, что у них стоит цель нагадить в тапки конкурирующим (и куда более успешным) корпорациям.
| | |
|
|
|
| 2.18, Аноним (18), 19:15, 22/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
А можно десяток примеров, когда libc ломает обратную совместимость?
| | |
| |
| 3.44, Аноним (44), 08:31, 23/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
Десяток подавай... Десятка нет. А есть один, зато мощный. Клиент 1С работает под Astra двухлетней давности, но не работает под новой (обновление тоже ломает, поэтому обновлять систему нельзя со всеми вытекающими последствиями). Причину мы установили - как раз сабж. Версию клиента, привязанную к серверу, сменить нельзя. Выход нашли - переходим на Windows.
| | |
| |
| 4.47, yet another anonymous (?), 08:52, 23/07/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ну вы даёте. Там и 1С, и Астра (которая "подправляет" и libc тоже), а виновата glibc. Впрочем, выход верный --- BSOD, с чистой совестью идём пить кофе и трындеть в курилке.
| | |
| 4.55, Аноним (55), 10:07, 23/07/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Типичные импортозмещатели. Вопрос только зачем за это взялись если все равно готовить не умеете.
| | |
| 4.79, fi (ok), 18:01, 23/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
 вангую - прога грузит две libc - через nss
как говорить - танцору всё мешает :DDDDDDD
| | |
|
|
| 2.33, Аноним (33), 00:19, 23/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
А у меня ассоциируется с тем, что относительно скоро или переставлять успевший устареть выпуск дистра или собирать эту жлибс стопервый раз и обновлять, так как прикладной софт будет требовать
| | |
| |
| 3.56, Аноним (55), 10:08, 23/07/2024 [^] [^^] [^^^] [ответить]
| –2 +/– |
Прикладной софт должен быть в контейнерах со всеми своими либами.
| | |
| |
| 4.57, Аноним (57), 10:20, 23/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
Твоими устами мёд бы пить.. Но грубая реальность такова что через полгодика ктонить соберет ключевую софтину под новую glibc...
Как пример можно привести Blender, они одно время в версиях 2.8x увлекались слишком новыми glibc, народ начал жаловаться, в следующем выпуске откатили обратно и это стало происходить более умеренно
| | |
| 4.58, Аноним (70), 11:03, 23/07/2024 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Прикладной софт должен быть в контейнерах со всеми своими либами.
Если память некуда девать, то конечно. А если есть лишняя, то ты просто бездельник.
| | |
|
|
|
| 1.11, Аноним (11), 18:48, 22/07/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Функциональность для выявления возможных переполнений буфера и связанных с безопасностью ошибок во время выполнения функций работы со строками и управления памятью ("_FORTIFY_SOURCE") адаптирована для сборки Glibc при помощи компилятора Clang.
Давно собираю с _FORTIFY_SOURCE=3 clangом, проблем не видел.
| | |
| 1.14, Аноним (-), 18:53, 22/07/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
> На системах x86 для ускорения записи больших наборов данных в функции memset предоставлена возможность отключения использования временных буферов. Оптимизация активируется при помощи настройки "x86_memset_non_temporal_threshold".
Пугающее улучшение.
В СИшке с одним бушером разобраться за 40 лет не могут, а тут еще будут временные.
Это же сколько возможностей выйти за пределы открывается.
| | |
| |
| 2.36, Аноним (36), 01:05, 23/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
Просто переводил надмозг. Речь про размер буфера для заливки, после которого будет использоваться реализация с non-temporal stores. (Адекватного перевода этого термина я не знаю.)
| | |
|
| 1.25, Аноним (-), 20:03, 22/07/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Смотрите, есть такая замечательная штука, как libstdc++_nonshared. Как она работает? Вот установлен у тебя в системе GCC 4.8. Рядышком стоит GCC 9. Ты собираешь проги при помощи GCC 9... И готовые бинари требуют GCC 4.8, а не GCC 9!
Я не знаю, как ред хат его готовит, однако эта библиотека есть только в репозитории devtoolset.
А теперь внимание, вопрос! Как собрать бинарник в системе, в которой установлен Glibc 2.32, таким образом, чтобы бинарник хотел Glibc 2.17? Чтобы было аналогично случаю выше, только не с C++, а с обычным C.
| | |
| |
| |
| 3.27, Аноним (27), 21:31, 22/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
И это будет работать? Может все таки надо собирать компилятор для старой glibc?
| | |
| |
| |
| 5.43, Аноним (42), 08:21, 23/07/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>у плюсов нет abi
Задумайся, что написал.
Если ABI официально не стандартизирован, то это не значит, что его нет. А так-то у большинства языков, которые символы маглят, ABI официально не стандартизированы: D, Nim, ...
| | |
| |
| 6.54, Аноним (70), 10:00, 23/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
По этой причине эти языки никогда не будут востребованы. Главное, что при обновлении половина программ гарантированно разлетается (до сих пор!), а тот же wxwidgets надо сразу пересобирать под целевой компилятор. В этом отношении не намного лучше раста.
| | |
|
| 5.78, n00by (ok), 17:47, 23/07/2024 [^] [^^] [^^^] [ответить]
| –2 +/– |
 System V Application Binary Interface
AMD64 Architecture Processor Supplement
(With LP64 and ILP32 Programming Models)
Version 1.0
...
Chapter 9
Conventions
9.1 C++
For the C++ ABI we will use the IA-64 C++ ABI and instantiate it appropriately.
The current draft of that ABI is available at:
http://mentorembedded.github.io/cxx-abi/
| | |
|
| 4.48, yet another anonymous (?), 09:03, 23/07/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Нет, не будет.
Предпочтительнее --- да (получится заведомо консистентная конструкция). Но вполне может быть жизнеспособным и в других комбинациях (сильно зависит от того, как этим пользоваться).
Статическими плюсовыми библиотеками не увлекались бы --- есть существенные тонкости в использовании.
| | |
|
|
| 2.34, нах. (?), 00:20, 23/07/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А теперь внимание, вопрос! Как собрать бинарник в системе, в которой установлен Glibc 2.32, таким
> образом, чтобы бинарник хотел Glibc 2.17?
короткий ответ: никак.
Длинный: теоретически ты бы мог это собрать если бы имел полный набор (не одну лишь libc.so.6!) абсолютно всех системных библиотек где-то в стороне от реально действующих системных, И одновременно - полный набор для замены /usr/include (потому что таки stable nonsense), тоже где-то в стороне.
Дальше тебе предстоит освоить ключик -nostdinc и -nostdlib а потом вручную скармливать компилятору пути к его собственным внутренним инклудам и библиотекам (потому что они тоже отрубятся этими ключами) помимо, очевидных, системных.
Практически - ничего кроме хеловрота ты так не соберешь, потому что будет практически невозможно объяснить модным-современным сборочным системам что ты такое хочешь.
Учитывая что для тебя даже -static-libstdc++ какая-то магия непонятная, требующая каких-то загадочных штуковин - ты точно не сможешь.
| | |
| |
| 3.67, Аноним (67), 14:06, 23/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
Практически - берется докер с нужной средой и собирается там...
| | |
| |
| 4.68, нах. (?), 14:10, 23/07/2024 [^] [^^] [^^^] [ответить]
| +/– | |
спрашивали-то как в другой системе собрать, а не в "нужной".
| | |
|
| 3.82, yet another anonymous (?), 22:05, 23/07/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> короткий ответ: никак.
...
Это совершенно не так. Если debian (включая производные) этого по большому счёту не умеет, то из этого не следует, что не умеет никто. Вот я умею, например. (Тезис про helloword --- это тоже не так).
Интересно то, что три четверти проектов, которым я покидывал двух-трёхсторчные патчи по этому поводу уходили на бесконечность со словами "нууу... мы как-то сомневаемся... надо бы подумать...".
| | |
|
| 2.38, Аноним (36), 01:12, 23/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
Зависит от того, что именно из libc ты используешь. Если что-то, что не менялось с 2.17, то ничего делать не придется - собранный бинарник и так будет требовать 2.17. Если ты используешь что-то более свежее, то извини, в 2.17 этого нет, и с ним твой бинарник будет несовместим.
| | |
| 2.41, DontTreadOnMe (?), 07:09, 23/07/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
1. Самый простой вариант - кросскомпиляция. Берёшь старый дистр с нужной версией libc, ставишь его в отдельную папочку (sysroot), дальше зависит от системы сборки. Для cmake, например, пишешь toolchain.cmake, где задаёшь всё, что касается нового sysroot. Для большинства других систем сборки есть аналоги. Руками тоже можно, но нужно будет указывать '-sysroot', '-isystem', '-L' и ещё что-нибудь.
2. Есть компилятор C от zig, который из коробки умеет задавать максимальную требуемую версию glibc, но это не gcc.
3. Как предлагали выше отключать все стандартные библиотеки и линковаться с ними вручную. Но в таком случае нужно будет rpath править руками и граблей там, на мой взгляд, будет больше чем с кросскомпиляцией.
| | |
| |
| 3.45, Аноним (44), 08:38, 23/07/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> 1. Самый простой вариант -
и самый действенный - окончательно собирать приложение в системе с самой старой версией, если, как заметили выше, не используются новые функции (еще помним и о deprecated). Так одно время и делал, имея для этого отдельный компьютер с Ubuntu 18.04, а разрабатываю на Ubuntu 22.04. Потом отказался, правда. Надоело.
| | |
| 3.46, нах. (?), 08:45, 23/07/2024 [^] [^^] [^^^] [ответить]
| +/– | |
для кросскомпиляции ему нужен - кросскомпилятор. Т.е. не надо путать твой опыт, я так подозреваю - пользования готовыми сборками, и попытки сделать самому из подручных средств.
Проблема в том что кросскомпилятор собран специальным образом, -isystem ты вряд ли отделаешься (потому что он не для этого был придуман, он добавляет пути поиска а не заменяет полностью)
Теоретически, можно еще попробовать самому собрать кросс-gcc+toolchain под такое дерево, а не использовать копию из старой системы, но я не уверен что это тоже будет легко (я напрочь не помню как оно собирается, да и двадцать раз могло поменяться с тех пор как мне такое бывало надо - боюсь что там не отключить сравнение target и текущей архитектуры). Но попробовать стоит - это хотя бы тривиально и недолго. Если получится - то проблема внезапно решилась.
rpath (в ручной схеме) руками править как раз не нужно - когда он не задан, при _сборке_ библиотека ищется по -L, но пути к ней в собранное не прописываются, предполагая что о них позаботится ld.so при старте, что в данном случае и требуется. Более того - собранное будет запускаться в современной системе (все же обратная совместимость в glibc - в основном сохраняется) но в нем не окажется прекрасных символов @GLIBC_2.40.0
| | |
| |
| 4.52, DontTreadOnMe (?), 09:13, 23/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
1. Ты можешь взять самый обычный компилятор из своего дистрибутива и кросс-компилировать им без всяких пересборок компилятора и подобного. Я так регулярно делаю. Абсолютно штатным x86_64 gcc или клангом из федоры. С g++ начиная где-то с 12-ой версии возникают проблемы, т.к. они безбожно ломают совместимость с собственной libstdc++. С клангом всё впорядке и с плюсами, и с сишкой.
Ключевую роль тут играет '-sysroot', именно он переопределяет основные пути поиска и т.п. Возможно, если в sysroot какой-то очень хитрый дистрибутив, то придётся что-то пересобирать или много всего прописывать. С более-менее нормальным линуксом всё ок либо решается парой симлинков.
2. Руками я пробовал только в рамках потыкать, так что вполне возможно, что я где-то накосячил и у меня появились пляски с rpath. Если без этого всё работает, то отлично.
| | |
| |
| 5.60, нах. (?), 11:26, 23/07/2024 [^] [^^] [^^^] [ответить]
| +/– | |
>> Ключевую роль тут играет '-sysroot', именно он переопределяет основные пути поиска и
а, наверное --sysroot ? Это не -isysroot, это может даже и работает.
Но он же переопределит заодно и пути к всяким crtbeginS.o и прочей бжне - а этого-то как раз делать и не стоило. Может оно такое и работает, но авторы компилятора этого не предусматривали.
| | |
| |
| |
| |
| 8.88, n00by (ok), 12:36, 24/07/2024 [^] [^^] [^^^] [ответить] | +/– | Писать самому диспетчер исключений не придётся Всё в исходниках есть, и их можн... текст свёрнут, показать | | |
|
| 7.86, нах. (?), 01:21, 24/07/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Авторы компилятора предусмотрели, что пути можно посмотреть
я в свое время (для совсем других целей) просто подменял collect2
- заодно получая полный список невидимых запчастей, линкующихся по умолчанию.
> может оно такое и работает. :)
оно такое работает, но тут тебе приносют какую-нибудь поделку от гугля - и чорта с два ты объяснишь это их билдсистеме на нескучном йезычке.
А хеловроты да, можно так собирать.
| | |
|
|
|
|
|
|
| 1.84, Аноним (84), 00:28, 24/07/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Хеловорлд под 2 мегабайта жрет оперативки слинкованный с глибц, не многовато ли?
На мюслях ~350кб
| | |
| |
| 2.91, Аноним (70), 14:54, 24/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
Приветмир (слип и зависимости), у глибц 143кб и 1.9мб шаред, у мюслей 584кб (328/318кб с 2 копиями в памяти) + 512кб шаред, но мюсли ощутимо тормознее и проблемнее. Если линковать статически, у мюслей 64кб + 0 шаред, у глибц 692кб + 640кб шаред. Зачем ты загоняешь себя в угол мюслями и даже не используешь их по назначению, линкуя статически?
| | |
|
|
