forum.opennet.ru - "Выпуск системной библиотеки Glibc 2.38 и набора утилит GNU Binutils 2.41" (69)

"Выпуск системной библиотеки Glibc 2.38 и набора утилит GNU Binutils 2.41"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Выпуск системной библиотеки Glibc 2.38 и набора утилит GNU Binutils 2.41"	+/–
Сообщение от opennews (?), 01-Авг-23, 09:29
После шести месяцев разработки опубликован релиз системной библиотеки GNU C Library (glibc) 2.38, которая полностью следует требованиям стандартов ISO C11 и POSIX.1-2017. В состав нового выпуска включены исправления от 67 разработчиков... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59529
Ответить \| Правка \| Cообщить модератору

Оглавление

Ничего себе, оно еще подергивается Была сложна и сами ниасилилиМда может они , Анонин (?), 09:29 , 01-Авг-23, (1)

Главное, чтобы почтовик не тырили А то, похоже, разрабы OpenSMTPD путают почтов, Аноним (3), 09:33 , 01-Авг-23, (3) +9
Пожалуйста, пускай стырят jemalloc Это позор какой-то, а не штатный malloc в gl, Аноним (5), 09:36 , 01-Авг-23, (5)

Штатный мейнстримный malloc вполне хорош В отличие от тормозного в мюслях На пр, Аноним (3), 11:46 , 01-Авг-23, (29) +1

Для локалхоста - да, для серьезной нагрузки - нет привет фрагментации кучи С э, Аноним (5), 12:01 , 01-Авг-23, (32) +3

Вы адепт секты Серъёзная нагрузка И что в этом такого Операционная система ре, Аноним (-), 14:19 , 01-Авг-23, (44) –1

Нет, просто у меня сервера под той самой нагрузкой Ну да, жаль процесс падает из, Аноним (5), 14:39 , 01-Авг-23, (47) +3

jemalloc давно сдулся https www joyfulbikeshedding com blog 2019-03-29-the-st, вымя (?), 18:11 , 03-Авг-23, (71)

Вот это блин вообще неожиданность Я таким, конечно, не пользуюсь, но glibc , Аноним (6), 09:40 , 01-Авг-23, (6)

Конечно неожиданность Glibc пишут практически лучшие погромисты современности, , Анонин (?), 10:04 , 01-Авг-23, (7) +3
Расскажи сказку что придёт добрый язык программирования и всё это исправит , Аноним (11), 10:15 , 01-Авг-23, (11)

чего вдруг сказку Конечно исправит - нет glibc, нет проблемы , Аноним (25), 11:02 , 01-Авг-23, (25) +1
Не могу, я расто-хейтер Просто вот вообще не ожидал увидеть такую банальную пр, Аноним (6), 17:41 , 01-Авг-23, (52)

Разработчики языков программирования и библиотек должны поддерживать ISO междун, Аноним (-), 14:12 , 01-Авг-23, (43)

О ужас, получается гнутики не только не осилили, но еще и нарушают международный, Анонин (?), 14:23 , 01-Авг-23, (45) +1

Может и стырят А вот в обратную сторону - не судьба , Серб (ok), 15:15 , 01-Авг-23, (48) +1

Я работал в окружении Hurd на x86_64 и до этого Ничего не понял , Аноним (2), 09:30 , 01-Авг-23, (2) –1

Ну бинарный код для i386 работал и работает на x86_64 А вот за 2023-й Hurd нати, Аноним (35), 12:15 , 01-Авг-23, (35)

Риторический вопрос когда они уже перепишут свой жрущий аллокатор, неужели слож, Аноним (5), 09:33 , 01-Авг-23, (4)

Твой васянский jemalloc менее универсален Кто мешает использовать его, если так, Аноним (15), 10:25 , 01-Авг-23, (15)

Мешает то что весь софт собирается под glibc, а все остальное остаётся на перифе, Аноним (11), 10:29 , 01-Авг-23, (20) –3

LD_PRELOAD my_malloc so 1 programmМешает разве что размер твоего черепа , Павел (??), 10:40 , 01-Авг-23, (23) +1

Не умеет жрать память в астрономических масштабах как malloc Ну да Изучай http, Аноним (5), 10:34 , 01-Авг-23, (22) –2

Что изучать, васянское дерьмище Если гулаг продвигает свой вендорлок любыми мет, Аноним (15), 10:45 , 01-Авг-23, (24)

Обожаю уровень компетентности анонимов опеннета Они даже jemalloc от tcmalloc н, Аноним (5), 11:27 , 01-Авг-23, (27)

Я говорил про v8, и о том, что у гулага цель побольше багов при работе с копилеф, Аноним (15), 11:29 , 01-Авг-23, (28)

libvips имеет обвязки к куче языков Glibc malloc безумно течет точнее фрагмент, Аноним (5), 11:56 , 01-Авг-23, (31)

Libvips стрёмное никому не нужное поделие, утечки в ней меня бы не удивили Зато, Аноним (15), 12:15 , 01-Авг-23, (34) +1

Причем тут го, если фрагментирует malloc при использовании libvips сишная либа , Аноним (5), 13:03 , 01-Авг-23, (39) –2

При том, что го не может нормально использовать сишный код, но ты не знаешь даже, Аноним (15), 14:02 , 01-Авг-23, (40)

Здесь просто free не вызывался для malloc из-за кривого go кода Сюрприз, с, Вирт (?), 16:53 , 03-Авг-23, (70)

Чтобы так же тормозить Нет, спасибо , Аноним (3), 11:47 , 01-Авг-23, (30) –1
Интереснее, почему не реализовали пару-тройку вариантов, оставив пользователю вы, n00by (ok), 16:13 , 01-Авг-23, (50)

А разве сейчас у него нет выбора , Аноним (57), 23:57 , 01-Авг-23, (57)

Есть Три раза присесть и сказать Кю , или использовать единственный , n00by (ok), 08:34 , 02-Авг-23, (58)

Ну если слинковаться с нужной либой или, на худой конец, прописать LD_PRELOAD - , Аноним (57), 18:21 , 02-Авг-23, (67)

Так варианты реализуют гипотетически создатели библиотеки, а не пользователи , n00by (ok), 16:35 , 03-Авг-23, (69)

Опять диды налефтпадили СИ-смузер никогда не научатся программировать , Аноним (5), 10:05 , 01-Авг-23, (8) –2

Ты даже не понимаешь смысл проблемы с лефтпадом, но продолжаешь повторять глупос, Аноним (11), 10:13 , 01-Авг-23, (10)

Проблема с лефтпадом была политической, личной, персональной, психологической, з, Аноним (12), 10:22 , 01-Авг-23, (12) +1

Сколько бы сишник не добывал огонь, все равно выйдет за границу буфера , Аноним (5), 10:26 , 01-Авг-23, (17) +3

Сколько бы смузики не добывали огонь всё равно получится лефтпад , Аноним (11), 12:39 , 01-Авг-23, (37) +1

Помнити leftpad 8482 это местный мем Нужно было прикрепить табличку Сарказм, Аноним (5), 10:24 , 01-Авг-23, (14)

Ну вот, а то тут про Hurd говрили, что жёстко приколочен к 32-м битам Хоронили,, Аноним (35), 12:11 , 01-Авг-23, (33)

Так и есть Hurd 64 не существует, его обещают https www gnu org software hurd , Аноним (11), 12:39 , 01-Авг-23, (36)

Скрыто модератором, Аноним (-), 14:23 , 01-Авг-23, (46) +1
Ну прекрасно Вон судя по документации https www gnu org software hurd users-g, Stax (ok), 09:29 , 02-Авг-23, (63)

А на него нужно много портировать У него тоже Glibc, а прикладной софт через не, Аноним (66), 12:02 , 02-Авг-23, (66)

А России нет человека, который может писать на Gnu assembler Все русские ассемб, Аноним (-), 14:07 , 01-Авг-23, (41) –2

О, живой эксперт по ассемблерам И не знает про flat assembler , n00by (ok), 15:45 , 01-Авг-23, (49)

Скрыто модератором, Аноним (-), 18:29 , 01-Авг-23, (54)

Скрыто модератором, n00by (ok), 08:37 , 02-Авг-23, (59)

Nasm - оптимальное решение, Аноним (35), 20:24 , 01-Авг-23, (55)

Скрыто модератором, Аноним (-), 09:48 , 02-Авг-23, (64)

Ну, он и про MASM не знает, который, как бы не в разы, был популярнее тазмо-назм, Аноним (56), 22:12 , 01-Авг-23, (56)

Да MASM там как бы стандарт , поскольку и линкер практически один, и Stephen Le, n00by (ok), 08:54 , 02-Авг-23, (60)

Скрыто модератором, Аноним (-), 09:15 , 02-Авг-23, (62)

Скрыто модератором, n00by (ok), 10:36 , 02-Авг-23, (65)

И правильно делают, Intel syntax для людей потому что, в отличие от AT T syntax , Аноним (51), 16:59 , 01-Авг-23, (51)

Скрыто модератором, Аноним (-), 18:27 , 01-Авг-23, (53)

Нахрен вообще писать на ассемблере под ОС GNU Читать понятно зачем, чтобы отл, Аноним (68), 15:29 , 03-Авг-23, (68)

Ты прав, тебе этого знать не надо , Аноним (-), 12:53 , 04-Авг-23, (72)
Например, в учебных целях У AMD64 много регистров, в Linux удобно вызывать ядро, n00by (ok), 13:44 , 04-Авг-23, (73)

Какие сегменты в Win64 Импорт системных библиотек нужно делать в любой ОС, Neon (??), 04:40 , 07-Авг-23, (76)

Например, стековый Но если ты не понял, то я написал, что приседать с ним не тр, n00by (ok), 10:49 , 26-Ноя-23, (79)

Скрыто модератором, Аноним (-), 14:10 , 01-Авг-23, (42) +1
АНБ прижала с выполнением экспортного законодательства по запрету вывоза техноло, Аноним (74), 07:46 , 05-Авг-23, (74) +1
Musl, Аноним (77), 10:22 , 07-Авг-23, (77)
Очень хочется видеть эти функции в стандарте Реализации strncpy и strncat это б, txgk (ok), 23:31 , 07-Авг-23, (78)

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Анонин (?), 01-Авг-23, 09:29 +/–

> Добавлена поддержка работы в окружении операционной системы Hurd
Ничего себе, оно еще подергивается!
> Реализация функций перенесена из OpenBSD
Была сложна и сами ниасилили
> вывод 1,234,567 приведёт к переполнению на 2 байта
Мда... может они еще что-то с bsd стырят?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #5, #6, #43, #48

2. Сообщение от Аноним (2), 01-Авг-23, 09:30 –1 +/–

> Добавлена поддержка работы в окружении операционной системы Hurd на системах x86_64
Я работал в окружении Hurd на x86_64 и до этого. Ничего не понял

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #35

3. Сообщение от Аноним (3), 01-Авг-23, 09:33 +9 +/–

> Мда... может они еще что-то с bsd стырят?
Главное, чтобы почтовик не тырили. А то, похоже, разрабы OpenSMTPD путают почтовик с remote shell.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

4. Сообщение от Аноним (5), 01-Авг-23, 09:33 +/–

Риторический вопрос: когда они уже перепишут свой жрущий аллокатор, неужели сложно посмотреть как сделано в jemalloc.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15, #30, #50

5. Сообщение от Аноним (5), 01-Авг-23, 09:36 +/–

> Мда... может они еще что-то с bsd стырят?
Пожалуйста, пускай стырят jemalloc. Это позор какой-то, а не штатный malloc в glibc.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #29

6. Сообщение от Аноним (6), 01-Авг-23, 09:40 +/–

> вывод 1,234,567 приведёт к переполнению на 2 байта
Вот это блин вообще неожиданность. Я таким, конечно, не пользуюсь, но... glibc??? Там тоже не могут размер буфера посчитать? Ладно всякие мудрёные ядра, где это случайно, или новомодные поделки от разработчиков на яваскрипте. Но glibc и функция, которая ПРЕДНАЗНАЧЕНА для того, чтоб переполнений буфера не было?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #7, #11

7. Сообщение от Анонин (?), 01-Авг-23, 10:04 +3 +/–

Конечно неожиданность! Glibc пишут практически лучшие погромисты современности, более крутые пишут ядро)
Но кто ж могу подумать, что две запятые в выводе займут дополнительно целых два байта??

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

8. Сообщение от Аноним (5), 01-Авг-23, 10:05 –2 +/–

> приводящая к переполнению буфера в функциях семейства printf при записи в буфер строковых представлений чисел с разделителями тысячных диапазонов
Опять диды налефтпадили. СИ-смузер никогда не научатся программировать.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10

10. Сообщение от Аноним (11), 01-Авг-23, 10:13 +/–

Ты даже не понимаешь смысл проблемы с лефтпадом, но продолжаешь повторять глупость как попугай невпопад.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #12, #14

11. Сообщение от Аноним (11), 01-Авг-23, 10:15 +/–

Расскажи сказку что придёт добрый язык программирования и всё это исправит.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #25, #52

12. Сообщение от Аноним (12), 01-Авг-23, 10:22 +1 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #17

14. Сообщение от Аноним (5), 01-Авг-23, 10:24 +/–

"Помнити leftpad"™ это местный мем. Нужно было прикрепить табличку Сарказм, как для Шелдона Купера?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

15. Сообщение от Аноним (15), 01-Авг-23, 10:25 +/–

Твой васянский jemalloc менее универсален. Кто мешает использовать его, если так хочется?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #20, #22

17. Сообщение от Аноним (5), 01-Авг-23, 10:26 +3 +/–

Сколько бы сишник не добывал огонь, все равно выйдет за границу буфера...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #37

20. Сообщение от Аноним (11), 01-Авг-23, 10:29 –3 +/–

Мешает то что весь софт собирается под glibc, а все остальное остаётся на периферии и не работает?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #23

22. Сообщение от Аноним (5), 01-Авг-23, 10:34 –2 +/–

> Твой васянский jemalloc менее универсален
Не умеет жрать память в астрономических масштабах как malloc? Ну да. Изучай:
https://github.com/lovell/sharp/issues/955
https://github.com/nodejs/node/issues/21973

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #24

23. Сообщение от Павел (??), 01-Авг-23, 10:40 +1 +/–

LD_PRELOAD=./my_malloc.so.1 programm
Мешает разве что размер твоего черепа.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

24. Сообщение от Аноним (15), 01-Авг-23, 10:45 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #27

25. Сообщение от Аноним (25), 01-Авг-23, 11:02 +1 +/–

чего вдруг сказку? Конечно исправит - нет glibc, нет проблемы!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

27. Сообщение от Аноним (5), 01-Авг-23, 11:27 +/–

> Если гулаг продвигает свой
Обожаю уровень компетентности анонимов опеннета! Они даже jemalloc от tcmalloc не отличают, но мнение имеют!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #28

28. Сообщение от Аноним (15), 01-Авг-23, 11:29 +/–

Я говорил про v8, и о том, что у гулага цель побольше багов при работе с копилефтным юзерспейсом, но ты не понял.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #31

29. Сообщение от Аноним (3), 01-Авг-23, 11:46 +1 +/–

> Пожалуйста, пускай стырят jemalloc. Это позор какой-то, а не штатный malloc в glibc.
Штатный мейнстримный malloc вполне хорош. В отличие от тормозного в мюслях.
На практике как раз наблюдаю использование jemalloc там, где из коробки стоят порезанные аналоги glibc, то бишь в alpine и прочих "минималистичных" дистрах.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #32

30. Сообщение от Аноним (3), 01-Авг-23, 11:47 –1 +/–

> Риторический вопрос: когда они уже перепишут свой жрущий аллокатор, неужели сложно посмотреть как сделано в jemalloc.
Чтобы так же тормозить? Нет, спасибо.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

31. Сообщение от Аноним (5), 01-Авг-23, 11:56 +/–

libvips имеет обвязки к куче языков. Glibc malloc безумно течет (точнее фрагментирует) вне зависимости, есть там V8 или нет. Вот еще пример:
https://github.com/libvips/libvips/issues/1929

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #34, #70

32. Сообщение от Аноним (5), 01-Авг-23, 12:01 +3 +/–

> Штатный мейнстримный malloc вполне хорош.
Для локалхоста - да, для серьезной нагрузки - нет (привет фрагментации кучи).
> В отличие от тормозного в мюслях.
С этим никто и не спорит, зачем ты его вспомнил?
> На практике как раз наблюдаю использование jemalloc там
где нужно эффективное выделение памяти, а не безумная фрагментация от glibc malloc.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #44, #71

33. Сообщение от Аноним (35), 01-Авг-23, 12:11 +/–

>Добавлена поддержка работы в окружении операционной системы Hurd на системах x86_64.
Ну вот, а то тут про Hurd говрили, что жёстко приколочен к 32-м битам. Хоронили, а он оказался фениксом.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #36

34. Сообщение от Аноним (15), 01-Авг-23, 12:15 +1 +/–

Libvips стрёмное никому не нужное поделие, утечки в ней меня бы не удивили. Зато у меня есть личные примеры, где tcmalloc вешал систему с zram (какой-то баг мультипоточности) и jemalloc рандомно сегфолтил моно-приложуху на подгрузке данных, на говоря о плохо предсказуемом потреблении ресурсов. Что касается ссылки, то го вообще задействует libc или у него всё своё? И ты притащил ещё больше гулягятины.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #39

35. Сообщение от Аноним (35), 01-Авг-23, 12:15 +/–

Ну бинарный код для i386 работал и работает на x86_64. А вот за 2023-й Hurd нативно на x86_64 портанули. Не знаю, насколько полно только.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

36. Сообщение от Аноним (11), 01-Авг-23, 12:39 +/–

Так и есть Hurd 64 не существует, его обещают https://www.gnu.org/software/hurd/faq/64-bit.html но он не вышел. Просто теперь glibc поддерживает с опережением. Похоже тем кто пытается изобразить Хурд 64 теперь есть с чем работать.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #46, #63

37. Сообщение от Аноним (11), 01-Авг-23, 12:39 +1 +/–

Сколько бы смузики не добывали огонь всё равно получится лефтпад.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

39. Сообщение от Аноним (5), 01-Авг-23, 13:03 –2 +/–

> Что касается ссылки, то го вообще задействует libc или у него всё своё
Причем тут го, если фрагментирует malloc при использовании libvips (сишная либа), вне зависимости от того, из какого языка вызываешь.
> Libvips стрёмное никому не нужное поделие
Уровень аналитики опеннетного анонима уже стало мемом в рунете.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #40

40. Сообщение от Аноним (15), 01-Авг-23, 14:02 +/–

При том, что го не может нормально использовать сишный код, но ты не знаешь даже этого. А по поводу libvips, это поделие ещё кривее ImageMagick.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

41. Сообщение от Аноним (-), 01-Авг-23, 14:07 –2 +/–

А России нет человека, который может писать на Gnu assembler. Все русские ассемблерщики являются вантузниками tasm и nasm.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #49, #51, #68

42. Сообщение от Аноним (-), 01-Авг-23, 14:10 +1 +/–

>GNU C Library (glibc) 2.38, которая полностью следует требованиям стандартов ISO C11 и POSIX.1-2017
Так держать!

Ответить | Правка | Наверх | Cообщить модератору

43. Сообщение от Аноним (-), 01-Авг-23, 14:12 +/–

>Была сложна и сами ниасилили
Разработчики языков программирования и библиотек должны поддерживать ISO (международный стандарт). Высер БЗДунов - это отсебятина.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #45

44. Сообщение от Аноним (-), 01-Авг-23, 14:19 –1 +/–

>Для локалхоста - да, для серьезной нагрузки - нет
Вы адепт секты "Серъёзная нагрузка"?
>(привет фрагментации кучи).
И что в этом такого? Операционная система решает, где и как, в конкретное время, будут распологаться данные.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #47

45. Сообщение от Анонин (?), 01-Авг-23, 14:23 +1 +/–

О ужас, получается гнутики не только не осилили, но еще и нарушают международный стандарт ISO??
Вообще не в какие ворота не лезет!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

46. Сообщение от Аноним (-), 01-Авг-23, 14:23 +1 +/–

Даже если Hurd будет готов, от местной публики пойдут придирки по части интерфейсов WM и DE.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

47. Сообщение от Аноним (5), 01-Авг-23, 14:39 +3 +/–

> Вы адепт секты "Серъёзная нагрузка"?
Нет, просто у меня сервера под той самой нагрузкой.
> И что в этом такого? Операционная система решает, где и как, в конкретное время, будут распологаться данные.
Ну да, жаль процесс падает из-за невозможности выделить большой блок памяти, хотя ее на самом деле завались.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

48. Сообщение от Серб (ok), 01-Авг-23, 15:15 +1 +/–

> Мда... может они еще что-то с bsd стырят?
Может и стырят. А вот в обратную сторону - не судьба...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

49. Сообщение от n00by (ok), 01-Авг-23, 15:45 +/–

О, живой эксперт по ассемблерам. И не знает про flat assembler.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #54, #55, #56

50. Сообщение от n00by (ok), 01-Авг-23, 16:13 +/–

Интереснее, почему не реализовали пару-тройку вариантов, оставив пользователю выбор.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #57

51. Сообщение от Аноним (51), 01-Авг-23, 16:59 +/–

И правильно делают, Intel syntax для людей потому что, в отличие от AT&T syntax (который вы почему-то назвали GNU, хотя gas поддерживает и то, и другое).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #53

52. Сообщение от Аноним (6), 01-Авг-23, 17:41 +/–

Не могу, я расто-хейтер :(
Просто вот вообще не ожидал увидеть такую банальную проблему в glibc.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

53. Сообщение от Аноним (-), 01-Авг-23, 18:27 +/–

Для GNU assembler AT&T syntax - свой родной. А Intel syntax так прикручен.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

54. Сообщение от Аноним (-), 01-Авг-23, 18:29 +/–

Ах да! У вантузников есть ещё и FASM.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #59

55. Сообщение от Аноним (35), 01-Авг-23, 20:24 +/–

Nasm - оптимальное решение

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #64

56. Сообщение от Аноним (56), 01-Авг-23, 22:12 +/–

> О, живой эксперт по ассемблерам. И не знает про flat assembler.
Ну, он и про MASM не знает, который, как бы не в разы, был популярнее тазмо-назмов.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #60

57. Сообщение от Аноним (57), 01-Авг-23, 23:57 +/–

А разве сейчас у него нет выбора?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #58

58. Сообщение от n00by (ok), 02-Авг-23, 08:34 +/–

Есть. Три раза присесть и сказать "Кю!", или использовать единственный.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #67

59. Сообщение от n00by (ok), 02-Авг-23, 08:37 +/–

Эксперт по своему обыкновению не знает, что fasm работает в любой ОС и поддерживает произвольные форматы файлов. Даёт программисту полную свободу действий, в отличие от тоталитарных продуктов.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

60. Сообщение от n00by (ok), 02-Авг-23, 08:54 +/–

Да MASM там как бы "стандарт", поскольку и линкер практически один, и Stephen Leslie Hutchesson *) немало поспособствовал продвижению
*) 26 мая 2023 в госпитале Сиднея в возрасте 74 лет, скончался Стивен Лесли Хатчесон https://wasm.in/threads/umer-stiven-lesli-xatcheson-sozdatel.../

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #62

62. Сообщение от Аноним (-), 02-Авг-23, 09:15 +/–

Вендузятнег n00by очередной раз показал свою вендузятскую сущность.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #65

63. Сообщение от Stax (ok), 02-Авг-23, 09:29 +/–

Ну прекрасно! Вон судя по документации https://www.gnu.org/software/hurd/users-guide/using_gnuhurd.... туда уже портированы GNOME, GIMP, GNU Emacs и куча всего полезного. Жить можно, значит.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #66

64. Сообщение от Аноним (-), 02-Авг-23, 09:48 +/–

Оптимальна чем? Тем что ты не умеешь в AT&T-синтаксис, а умеешь в Intel?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

65. Сообщение от n00by (ok), 02-Авг-23, 10:36 +/–

Анон, не тужься, не все линуксоиды подобны тебе. Некоторые вполне умеют кодить.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

66. Сообщение от Аноним (66), 02-Авг-23, 12:02 +/–

А на него нужно много портировать? У него тоже Glibc, а прикладной софт через неё с ядром взаимодействует.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

67. Сообщение от Аноним (57), 02-Авг-23, 18:21 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #69

68. Сообщение от Аноним (68), 03-Авг-23, 15:29 +/–

Нахрен вообще "писать" на ассемблере под ОС GNU? Читать понятно зачем, чтобы отлаживать. Но писать по собственной воле на асме? Зачем, если вы не делаете кряк? А под GNU кряки не нужны ни для чего.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #72, #73

69. Сообщение от n00by (ok), 03-Авг-23, 16:35 +/–

Так варианты реализуют (гипотетически) создатели библиотеки, а не пользователи. Последние же не хеккеры, что бы уметь писать нубский руткит. Они скажут "это некросплатформенно" и пойдут пить кофе.)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

70. Сообщение от Вирт (?), 03-Авг-23, 16:53 +/–

> Вот еще пример: https://github.com/libvips/libvips/issues/1929
Здесь просто "free" не вызывался для "malloc" из-за кривого "go" кода.
Сюрприз, сюрприз "glibc malloc" течет если не вызывать "free".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

71. Сообщение от вымя (?), 03-Авг-23, 18:11 +/–

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-statu...)
Да и Firefox продолжает пользоваться своим форком.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

72. Сообщение от Аноним (-), 04-Авг-23, 12:53 +/–

>Но писать по собственной воле на асме? Зачем, если вы не делаете кряк? А под GNU кряки не нужны ни для чего.
Ты прав, тебе этого знать не надо.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

73. Сообщение от n00by (ok), 04-Авг-23, 13:44 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #76

74. Сообщение от Аноним (74), 05-Авг-23, 07:46 +1 +/–

> прекращена сборка библиотеки libcrypt, которая в будущем вероятно будет удалена из состава Glibc
АНБ прижала с выполнением экспортного законодательства по запрету вывоза технологий с криптухой за рубеж.
А какие страны в мире сегодня имеют незыблемое законодательство в сфере разработки и распространения технологий ИТ безопасности и криптографии?
Швейцария, как известно, с позором обо*ралась: ЦРУ и БНД удалось выкупить акции, сменить руководство, нанять на работу своих спецагентов и протроянить не взламываемую Швейцарскую криптуху.

Ответить | Правка | Наверх | Cообщить модератору

76. Сообщение от Neon (??), 07-Авг-23, 04:40 +/–

Какие сегменты в Win64 ? Импорт системных библиотек нужно делать в любой ОС

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #79

77. Сообщение от Аноним (77), 07-Авг-23, 10:22 +/–

Musl

Ответить | Правка | Наверх | Cообщить модератору

78. Сообщение от txgk (ok), 07-Авг-23, 23:31 +/–

> Добавлены новые функции strlcpy и strlcat - альтернативы функциям strncpy и strncat, содержащие защиту от переполнения буфера и обязательно выставляющие замыкающий строку нулевой байт. Реализация функций перенесена из OpenBSD. Ожидается, что в будущем данные функции будут включены в стандарт POSIX.
Очень хочется видеть эти функции в стандарте. Реализации strncpy и strncat это большая ошибка, потому что префикс "str" в названиях функций подразумевает работу со строками, которые по стандартному определению являются последовательностью символов с нулевым байтом на конце; однако в результате вызова этих функций может получиться уже совсем не строка, что и является источником некоторых уязвимостей время от времени.

Ответить | Правка | Наверх | Cообщить модератору

79. Сообщение от n00by (ok), 26-Ноя-23, 10:49 +/–

> Какие сегменты в Win64 ?
Например, стековый. Но если ты не понял, то я написал, что приседать с ним не требуется. И вообще про Linux.
> Импорт системных библиотек нужно делать в любой ОС
Тебе нужно, ты и делай, но других ереси не учи.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. Сообщение от Анонин (?), 01-Авг-23, 09:29	+/–
> Добавлена поддержка работы в окружении операционной системы Hurd Ничего себе, оно еще подергивается! > Реализация функций перенесена из OpenBSD Была сложна и сами ниасилили > вывод 1,234,567 приведёт к переполнению на 2 байта Мда... может они еще что-то с bsd стырят?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #3, #5, #6, #43, #48

2. Сообщение от Аноним (2), 01-Авг-23, 09:30	–1 +/–
> Добавлена поддержка работы в окружении операционной системы Hurd на системах x86_64 Я работал в окружении Hurd на x86_64 и до этого. Ничего не понял
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #35

3. Сообщение от Аноним (3), 01-Авг-23, 09:33	+9 +/–
> Мда... может они еще что-то с bsd стырят? Главное, чтобы почтовик не тырили. А то, похоже, разрабы OpenSMTPD путают почтовик с remote shell.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1

4. Сообщение от Аноним (5), 01-Авг-23, 09:33	+/–
Риторический вопрос: когда они уже перепишут свой жрущий аллокатор, неужели сложно посмотреть как сделано в jemalloc.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #15, #30, #50

5. Сообщение от Аноним (5), 01-Авг-23, 09:36	+/–
> Мда... может они еще что-то с bsd стырят? Пожалуйста, пускай стырят jemalloc. Это позор какой-то, а не штатный malloc в glibc.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #29

6. Сообщение от Аноним (6), 01-Авг-23, 09:40	+/–
> вывод 1,234,567 приведёт к переполнению на 2 байта Вот это блин вообще неожиданность. Я таким, конечно, не пользуюсь, но... glibc??? Там тоже не могут размер буфера посчитать? Ладно всякие мудрёные ядра, где это случайно, или новомодные поделки от разработчиков на яваскрипте. Но glibc и функция, которая ПРЕДНАЗНАЧЕНА для того, чтоб переполнений буфера не было?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #7, #11

7. Сообщение от Анонин (?), 01-Авг-23, 10:04	+3 +/–
Конечно неожиданность! Glibc пишут практически лучшие погромисты современности, более крутые пишут ядро) Но кто ж могу подумать, что две запятые в выводе займут дополнительно целых два байта??
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6

8. Сообщение от Аноним (5), 01-Авг-23, 10:05	–2 +/–
> приводящая к переполнению буфера в функциях семейства printf при записи в буфер строковых представлений чисел с разделителями тысячных диапазонов Опять диды налефтпадили. СИ-смузер никогда не научатся программировать.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #10

10. Сообщение от Аноним (11), 01-Авг-23, 10:13	+/–
Ты даже не понимаешь смысл проблемы с лефтпадом, но продолжаешь повторять глупость как попугай невпопад.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8 Ответы: #12, #14

11. Сообщение от Аноним (11), 01-Авг-23, 10:15	+/–
Расскажи сказку что придёт добрый язык программирования и всё это исправит.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6 Ответы: #25, #52

12. Сообщение от Аноним (12), 01-Авг-23, 10:22	+1 +/–
Проблема с лефтпадом была политической, личной, персональной, психологической, зигмундфрейдовской -- какой угодно, но не технической. Нет ничего плохого в том, что используются чьи-от уже готовые функции. Но сишникам кажется, что в каждом новом проекте нужно заново описывать, как добывать огонь. Это уже давно решенная проблема, алло!
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10 Ответы: #17

14. Сообщение от Аноним (5), 01-Авг-23, 10:24	+/–
"Помнити leftpad"™ это местный мем. Нужно было прикрепить табличку Сарказм, как для Шелдона Купера?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10

15. Сообщение от Аноним (15), 01-Авг-23, 10:25	+/–
Твой васянский jemalloc менее универсален. Кто мешает использовать его, если так хочется?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4 Ответы: #20, #22

17. Сообщение от Аноним (5), 01-Авг-23, 10:26	+3 +/–
Сколько бы сишник не добывал огонь, все равно выйдет за границу буфера...
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12 Ответы: #37

20. Сообщение от Аноним (11), 01-Авг-23, 10:29	–3 +/–
Мешает то что весь софт собирается под glibc, а все остальное остаётся на периферии и не работает?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15 Ответы: #23

22. Сообщение от Аноним (5), 01-Авг-23, 10:34	–2 +/–
> Твой васянский jemalloc менее универсален Не умеет жрать память в астрономических масштабах как malloc? Ну да. Изучай: https://github.com/lovell/sharp/issues/955 https://github.com/nodejs/node/issues/21973
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15 Ответы: #24

23. Сообщение от Павел (??), 01-Авг-23, 10:40	+1 +/–
LD_PRELOAD=./my_malloc.so.1 programm Мешает разве что размер твоего черепа.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #20

24. Сообщение от Аноним (15), 01-Авг-23, 10:45	+/–
Что изучать, васянское дерьмище? Если гулаг продвигает свой вендорлок любыми методами, то это ничего не значит.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #22 Ответы: #27

25. Сообщение от Аноним (25), 01-Авг-23, 11:02	+1 +/–
чего вдруг сказку? Конечно исправит - нет glibc, нет проблемы!
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11

27. Сообщение от Аноним (5), 01-Авг-23, 11:27	+/–
> Если гулаг продвигает свой Обожаю уровень компетентности анонимов опеннета! Они даже jemalloc от tcmalloc не отличают, но мнение имеют!
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #24 Ответы: #28

28. Сообщение от Аноним (15), 01-Авг-23, 11:29	+/–
Я говорил про v8, и о том, что у гулага цель побольше багов при работе с копилефтным юзерспейсом, но ты не понял.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #27 Ответы: #31

29. Сообщение от Аноним (3), 01-Авг-23, 11:46	+1 +/–
> Пожалуйста, пускай стырят jemalloc. Это позор какой-то, а не штатный malloc в glibc. Штатный мейнстримный malloc вполне хорош. В отличие от тормозного в мюслях. На практике как раз наблюдаю использование jemalloc там, где из коробки стоят порезанные аналоги glibc, то бишь в alpine и прочих "минималистичных" дистрах.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5 Ответы: #32

30. Сообщение от Аноним (3), 01-Авг-23, 11:47	–1 +/–
> Риторический вопрос: когда они уже перепишут свой жрущий аллокатор, неужели сложно посмотреть как сделано в jemalloc. Чтобы так же тормозить? Нет, спасибо.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4

31. Сообщение от Аноним (5), 01-Авг-23, 11:56	+/–
libvips имеет обвязки к куче языков. Glibc malloc безумно течет (точнее фрагментирует) вне зависимости, есть там V8 или нет. Вот еще пример: https://github.com/libvips/libvips/issues/1929
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #28 Ответы: #34, #70

32. Сообщение от Аноним (5), 01-Авг-23, 12:01	+3 +/–
> Штатный мейнстримный malloc вполне хорош. Для локалхоста - да, для серьезной нагрузки - нет (привет фрагментации кучи). > В отличие от тормозного в мюслях. С этим никто и не спорит, зачем ты его вспомнил? > На практике как раз наблюдаю использование jemalloc там где нужно эффективное выделение памяти, а не безумная фрагментация от glibc malloc.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #29 Ответы: #44, #71

33. Сообщение от Аноним (35), 01-Авг-23, 12:11	+/–
>Добавлена поддержка работы в окружении операционной системы Hurd на системах x86_64. Ну вот, а то тут про Hurd говрили, что жёстко приколочен к 32-м битам. Хоронили, а он оказался фениксом.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #36

34. Сообщение от Аноним (15), 01-Авг-23, 12:15	+1 +/–
Libvips стрёмное никому не нужное поделие, утечки в ней меня бы не удивили. Зато у меня есть личные примеры, где tcmalloc вешал систему с zram (какой-то баг мультипоточности) и jemalloc рандомно сегфолтил моно-приложуху на подгрузке данных, на говоря о плохо предсказуемом потреблении ресурсов. Что касается ссылки, то го вообще задействует libc или у него всё своё? И ты притащил ещё больше гулягятины.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #31 Ответы: #39

35. Сообщение от Аноним (35), 01-Авг-23, 12:15	+/–
Ну бинарный код для i386 работал и работает на x86_64. А вот за 2023-й Hurd нативно на x86_64 портанули. Не знаю, насколько полно только.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2

36. Сообщение от Аноним (11), 01-Авг-23, 12:39	+/–
Так и есть Hurd 64 не существует, его обещают https://www.gnu.org/software/hurd/faq/64-bit.html но он не вышел. Просто теперь glibc поддерживает с опережением. Похоже тем кто пытается изобразить Хурд 64 теперь есть с чем работать.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #33 Ответы: #46, #63

37. Сообщение от Аноним (11), 01-Авг-23, 12:39	+1 +/–
Сколько бы смузики не добывали огонь всё равно получится лефтпад.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #17