| 1.1, Анонин (?), 09:29, 01/08/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Добавлена поддержка работы в окружении операционной системы Hurd
Ничего себе, оно еще подергивается!
> Реализация функций перенесена из OpenBSD
Была сложна и сами ниасилили
> вывод 1,234,567 приведёт к переполнению на 2 байта
Мда... может они еще что-то с bsd стырят?
| | |
| |
| 2.3, Аноним (3), 09:33, 01/08/2023 [^] [^^] [^^^] [ответить]
| +9 +/– | |
> Мда... может они еще что-то с bsd стырят?
Главное, чтобы почтовик не тырили. А то, похоже, разрабы OpenSMTPD путают почтовик с remote shell.
| | |
| 2.5, Аноним (5), 09:36, 01/08/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> Мда... может они еще что-то с bsd стырят?
Пожалуйста, пускай стырят jemalloc. Это позор какой-то, а не штатный malloc в glibc.
| | |
| |
| 3.29, Аноним (3), 11:46, 01/08/2023 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Пожалуйста, пускай стырят jemalloc. Это позор какой-то, а не штатный malloc в glibc.
Штатный мейнстримный malloc вполне хорош. В отличие от тормозного в мюслях.
На практике как раз наблюдаю использование jemalloc там, где из коробки стоят порезанные аналоги glibc, то бишь в alpine и прочих "минималистичных" дистрах.
| | |
| |
| 4.32, Аноним (5), 12:01, 01/08/2023 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Штатный мейнстримный malloc вполне хорош.
Для локалхоста - да, для серьезной нагрузки - нет (привет фрагментации кучи).
> В отличие от тормозного в мюслях.
С этим никто и не спорит, зачем ты его вспомнил?
> На практике как раз наблюдаю использование jemalloc там
где нужно эффективное выделение памяти, а не безумная фрагментация от glibc malloc.
| | |
| |
| 5.44, Аноним (-), 14:19, 01/08/2023 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Для локалхоста - да, для серьезной нагрузки - нет
Вы адепт секты "Серъёзная нагрузка"?
>(привет фрагментации кучи).
И что в этом такого? Операционная система решает, где и как, в конкретное время, будут распологаться данные.
| | |
| |
| 6.47, Аноним (5), 14:39, 01/08/2023 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Вы адепт секты "Серъёзная нагрузка"?
Нет, просто у меня сервера под той самой нагрузкой.
> И что в этом такого? Операционная система решает, где и как, в конкретное время, будут распологаться данные.
Ну да, жаль процесс падает из-за невозможности выделить большой блок памяти, хотя ее на самом деле завались.
| | |
|
| 5.71, вымя (?), 18:11, 03/08/2023 [^] [^^] [^^^] [ответить]
| +/– | |
jemalloc давно сдулся:
> Using jemalloc as Ruby's default is a bit problematic. There was a heated discussion in the Ruby bug tracker about this, but in the end no decision was made. The main issue raised is the fact that memory usage only reduces when using jemalloc 3; memory usage is still high when using jemalloc 5. Nobody knows why, so that makes the choice of defaulting to jemalloc very dodgy.
(https://www.joyfulbikeshedding.com/blog/2019-03-29-the-status-of-ruby-memory-t)
Да и Firefox продолжает пользоваться своим форком.
| | |
|
|
|
| 2.6, Аноним (6), 09:40, 01/08/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> вывод 1,234,567 приведёт к переполнению на 2 байта
Вот это блин вообще неожиданность. Я таким, конечно, не пользуюсь, но... glibc??? Там тоже не могут размер буфера посчитать? Ладно всякие мудрёные ядра, где это случайно, или новомодные поделки от разработчиков на яваскрипте. Но glibc и функция, которая ПРЕДНАЗНАЧЕНА для того, чтоб переполнений буфера не было?
| | |
| |
| 3.7, Анонин (?), 10:04, 01/08/2023 [^] [^^] [^^^] [ответить]
| +3 +/– |
Конечно неожиданность! Glibc пишут практически лучшие погромисты современности, более крутые пишут ядро)
Но кто ж могу подумать, что две запятые в выводе займут дополнительно целых два байта??
| | |
| 3.11, Аноним (11), 10:15, 01/08/2023 [^] [^^] [^^^] [ответить]
| +/– |
Расскажи сказку что придёт добрый язык программирования и всё это исправит.
| | |
| |
| 4.25, Аноним (25), 11:02, 01/08/2023 [^] [^^] [^^^] [ответить]
| +1 +/– | |
чего вдруг сказку? Конечно исправит - нет glibc, нет проблемы!
| | |
| 4.52, Аноним (6), 17:41, 01/08/2023 [^] [^^] [^^^] [ответить]
| +/– | |
Не могу, я расто-хейтер :(
Просто вот вообще не ожидал увидеть такую банальную проблему в glibc.
| | |
|
|
| 2.43, Аноним (-), 14:12, 01/08/2023 [^] [^^] [^^^] [ответить]
| +/– | |
>Была сложна и сами ниасилили
Разработчики языков программирования и библиотек должны поддерживать ISO (международный стандарт). Высер БЗДунов - это отсебятина.
| | |
| |
| 3.45, Анонин (?), 14:23, 01/08/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
О ужас, получается гнутики не только не осилили, но еще и нарушают международный стандарт ISO??
Вообще не в какие ворота не лезет!
| | |
|
| 2.48, Серб (ok), 15:15, 01/08/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Мда... может они еще что-то с bsd стырят?
Может и стырят. А вот в обратную сторону - не судьба...
| | |
|
| 1.2, Аноним (2), 09:30, 01/08/2023 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
> Добавлена поддержка работы в окружении операционной системы Hurd на системах x86_64
Я работал в окружении Hurd на x86_64 и до этого. Ничего не понял
| | |
| |
| 2.35, Аноним (35), 12:15, 01/08/2023 [^] [^^] [^^^] [ответить]
| +/– |
Ну бинарный код для i386 работал и работает на x86_64. А вот за 2023-й Hurd нативно на x86_64 портанули. Не знаю, насколько полно только.
| | |
|
| 1.4, Аноним (5), 09:33, 01/08/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Риторический вопрос: когда они уже перепишут свой жрущий аллокатор, неужели сложно посмотреть как сделано в jemalloc.
| | |
| |
| 2.15, Аноним (15), 10:25, 01/08/2023 [^] [^^] [^^^] [ответить]
| +/– |
Твой васянский jemalloc менее универсален. Кто мешает использовать его, если так хочется?
| | |
| |
| 3.20, Аноним (11), 10:29, 01/08/2023 [^] [^^] [^^^] [ответить]
| –3 +/– |
Мешает то что весь софт собирается под glibc, а все остальное остаётся на периферии и не работает?
| | |
| |
| 4.23, Павел (??), 10:40, 01/08/2023 [^] [^^] [^^^] [ответить]
| +1 +/– | |
LD_PRELOAD=./my_malloc.so.1 programm
Мешает разве что размер твоего черепа.
| | |
|
| |
| 4.24, Аноним (15), 10:45, 01/08/2023 [^] [^^] [^^^] [ответить]
| +/– |
Что изучать, васянское дерьмище? Если гулаг продвигает свой вендорлок любыми методами, то это ничего не значит.
| | |
| |
| 5.27, Аноним (5), 11:27, 01/08/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> Если гулаг продвигает свой
Обожаю уровень компетентности анонимов опеннета! Они даже jemalloc от tcmalloc не отличают, но мнение имеют!
| | |
| |
| 6.28, Аноним (15), 11:29, 01/08/2023 [^] [^^] [^^^] [ответить]
| +/– |
Я говорил про v8, и о том, что у гулага цель побольше багов при работе с копилефтным юзерспейсом, но ты не понял.
| | |
| |
| |
| 8.34, Аноним (15), 12:15, 01/08/2023 [^] [^^] [^^^] [ответить] | +1 +/– | Libvips стрёмное никому не нужное поделие, утечки в ней меня бы не удивили Зато... текст свёрнут, показать | | |
| |
| 9.39, Аноним (5), 13:03, 01/08/2023 [^] [^^] [^^^] [ответить] | –2 +/– | Причем тут го, если фрагментирует malloc при использовании libvips сишная либа ... текст свёрнут, показать | | |
|
| 8.70, Вирт (?), 16:53, 03/08/2023 [^] [^^] [^^^] [ответить] | +/– | Здесь просто free не вызывался для malloc из-за кривого go кода Сюрприз, ... текст свёрнут, показать | | |
|
|
|
|
|
|
| 2.30, Аноним (3), 11:47, 01/08/2023 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Риторический вопрос: когда они уже перепишут свой жрущий аллокатор, неужели сложно посмотреть как сделано в jemalloc.
Чтобы так же тормозить? Нет, спасибо.
| | |
| 2.50, n00by (ok), 16:13, 01/08/2023 [^] [^^] [^^^] [ответить]
| +/– |
 Интереснее, почему не реализовали пару-тройку вариантов, оставив пользователю выбор.
| | |
| |
| |
| 4.58, n00by (ok), 08:34, 02/08/2023 [^] [^^] [^^^] [ответить]
| +/– |
Есть. Три раза присесть и сказать "Кю!", или использовать единственный.
| | |
| |
| 5.67, Аноним (57), 18:21, 02/08/2023 [^] [^^] [^^^] [ответить]
| +/– | |
Ну если слинковаться с нужной либой или, на худой конец, прописать LD_PRELOAD - это непосильная задача, то эта ваша "пара-тройка вариантов" - это вообще за гранью разумного.
А вообще, разрабам больше делать нечего, кроме как переписывать пару-тройку раз одну из самых сложных частей либы.
| | |
| |
| 6.69, n00by (ok), 16:35, 03/08/2023 [^] [^^] [^^^] [ответить]
| +/– |
Так варианты реализуют (гипотетически) создатели библиотеки, а не пользователи. Последние же не хеккеры, что бы уметь писать нубский руткит. Они скажут "это некросплатформенно" и пойдут пить кофе.)
| | |
|
|
|
|
|
| 1.8, Аноним (5), 10:05, 01/08/2023 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
> приводящая к переполнению буфера в функциях семейства printf при записи в буфер строковых представлений чисел с разделителями тысячных диапазонов
Опять диды налефтпадили. СИ-смузер никогда не научатся программировать.
| | |
| |
| 2.10, Аноним (11), 10:13, 01/08/2023 [^] [^^] [^^^] [ответить]
| +/– |
Ты даже не понимаешь смысл проблемы с лефтпадом, но продолжаешь повторять глупость как попугай невпопад.
| | |
| |
| 3.12, Аноним (12), 10:22, 01/08/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Проблема с лефтпадом была политической, личной, персональной, психологической, зигмундфрейдовской -- какой угодно, но не технической. Нет ничего плохого в том, что используются чьи-от уже готовые функции. Но сишникам кажется, что в каждом новом проекте нужно заново описывать, как добывать огонь. Это уже давно решенная проблема, алло!
| | |
| |
| 4.17, Аноним (5), 10:26, 01/08/2023 [^] [^^] [^^^] [ответить]
| +3 +/– |
Сколько бы сишник не добывал огонь, все равно выйдет за границу буфера...
| | |
| |
| 5.37, Аноним (11), 12:39, 01/08/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Сколько бы смузики не добывали огонь всё равно получится лефтпад.
| | |
|
|
| 3.14, Аноним (5), 10:24, 01/08/2023 [^] [^^] [^^^] [ответить]
| +/– |
"Помнити leftpad"™ это местный мем. Нужно было прикрепить табличку Сарказм, как для Шелдона Купера?
| | |
|
|
| 1.33, Аноним (35), 12:11, 01/08/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Добавлена поддержка работы в окружении операционной системы Hurd на системах x86_64.
Ну вот, а то тут про Hurd говрили, что жёстко приколочен к 32-м битам. Хоронили, а он оказался фениксом.
| | |
| |
| |
| |
| 4.66, Аноним (66), 12:02, 02/08/2023 [^] [^^] [^^^] [ответить]
| +/– |
А на него нужно много портировать? У него тоже Glibc, а прикладной софт через неё с ядром взаимодействует.
| | |
|
|
|
| 1.41, Аноним (-), 14:07, 01/08/2023 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
А России нет человека, который может писать на Gnu assembler. Все русские ассемблерщики являются вантузниками tasm и nasm.
| | |
| |
| 2.49, n00by (ok), 15:45, 01/08/2023 [^] [^^] [^^^] [ответить]
| +/– |
О, живой эксперт по ассемблерам. И не знает про flat assembler.
| | |
| |
| 3.56, Аноним (56), 22:12, 01/08/2023 [^] [^^] [^^^] [ответить]
| +/– |
 > О, живой эксперт по ассемблерам. И не знает про flat assembler.
Ну, он и про MASM не знает, который, как бы не в разы, был популярнее тазмо-назмов.
| | |
|
| 2.51, Аноним (51), 16:59, 01/08/2023 [^] [^^] [^^^] [ответить]
| +/– |
И правильно делают, Intel syntax для людей потому что, в отличие от AT&T syntax (который вы почему-то назвали GNU, хотя gas поддерживает и то, и другое).
| | |
| 2.68, Аноним (68), 15:29, 03/08/2023 [^] [^^] [^^^] [ответить]
| +/– |
Нахрен вообще "писать" на ассемблере под ОС GNU? Читать понятно зачем, чтобы отлаживать. Но писать по собственной воле на асме? Зачем, если вы не делаете кряк? А под GNU кряки не нужны ни для чего.
| | |
| |
| 3.72, Аноним (-), 12:53, 04/08/2023 [^] [^^] [^^^] [ответить]
| +/– | |
>Но писать по собственной воле на асме? Зачем, если вы не делаете кряк? А под GNU кряки не нужны ни для чего.
Ты прав, тебе этого знать не надо.
| | |
| 3.73, n00by (ok), 13:44, 04/08/2023 [^] [^^] [^^^] [ответить]
| +/– |
Например, в учебных целях. У AMD64 много регистров, в Linux удобно вызывать ядро и плоская модель памяти. Можно сосредоточиться непосредственно на программировании, а не на приседаниях с сегментами, импортом из системных библиотек и прочей лишней сложности, что отпугивает новичков.
| | |
| |
| 4.76, Neon (??), 04:40, 07/08/2023 [^] [^^] [^^^] [ответить]
| +/– |
Какие сегменты в Win64 ? Импорт системных библиотек нужно делать в любой ОС
| | |
| |
| 5.79, n00by (ok), 10:49, 26/11/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> Какие сегменты в Win64 ?
Например, стековый. Но если ты не понял, то я написал, что приседать с ним не требуется. И вообще про Linux.
> Импорт системных библиотек нужно делать в любой ОС
Тебе нужно, ты и делай, но других ереси не учи.
| | |
|
|
|
|
| 1.74, Аноним (74), 07:46, 05/08/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> прекращена сборка библиотеки libcrypt, которая в будущем вероятно будет удалена из состава Glibc
АНБ прижала с выполнением экспортного законодательства по запрету вывоза технологий с криптухой за рубеж.
А какие страны в мире сегодня имеют незыблемое законодательство в сфере разработки и распространения технологий ИТ безопасности и криптографии?
Швейцария, как известно, с позором обо*ралась: ЦРУ и БНД удалось выкупить акции, сменить руководство, нанять на работу своих спецагентов и протроянить не взламываемую Швейцарскую криптуху.
| | |
| 1.78, txgk (ok), 23:31, 07/08/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 > Добавлены новые функции strlcpy и strlcat - альтернативы функциям strncpy и strncat, содержащие защиту от переполнения буфера и обязательно выставляющие замыкающий строку нулевой байт. Реализация функций перенесена из OpenBSD. Ожидается, что в будущем данные функции будут включены в стандарт POSIX.
Очень хочется видеть эти функции в стандарте. Реализации strncpy и strncat это большая ошибка, потому что префикс "str" в названиях функций подразумевает работу со строками, которые по стандартному определению являются последовательностью символов с нулевым байтом на конце; однако в результате вызова этих функций может получиться уже совсем не строка, что и является источником некоторых уязвимостей время от времени.
| | |
|
