The OpenNET Project / Index page

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



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

"Уязвимость во FreeType, позволяющая выполнить код при обработке шрифтов"  +/
Сообщение от opennews (ok), 13-Мрт-25, 14:22 
В библиотеке отрисовки шрифтов...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62875

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

Оглавление

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


2. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноним (2), 13-Мрт-25, 14:24 
А когда добавили? В прошлый раз была уязвимость с шрифтами в формате png. Так теперь и не отключить png во freetype стало.
Ответить | Правка | Наверх | Cообщить модератору

34. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноним (34), 13-Мрт-25, 20:42 
Хороший вопрос... Ибо вариативные шрифты придумала в 2016 году группа компаний Adobe, Apple, Google и Microsoft.
Ответить | Правка | Наверх | Cообщить модератору

44. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноним (44), 13-Мрт-25, 23:57 
Хорошие компании
Ответить | Правка | Наверх | Cообщить модератору

49. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +3 +/
Сообщение от Аноним (49), 14-Мрт-25, 01:24 
> вариативные шрифты придумала в 2016 году группа
> компаний Adobe, Apple, Google и Microsoft.

Ужасные компании!
Мало того что платиновые спонсоры линукс фаундейшн, так еще умудяются наложить в штаны freedesktop'у, создавая стандарты который фридесктопчики ниасиливают!
Подбросили CVE вот так прямо в их репозиторий!

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

64. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от крабб (?), 14-Мрт-25, 09:36 
это пять!
Ответить | Правка | Наверх | Cообщить модератору

3. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +4 +/
Сообщение от Аноним (3), 13-Мрт-25, 14:26 
Никогда такого не было и вот опять
Ответить | Правка | Наверх | Cообщить модератору

4. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +8 +/
Сообщение от Аноним (4), 13-Мрт-25, 14:36 
Заходя в эту новость, я уже предвкушал, что тут будет переполнение буфера.
Ответить | Правка | Наверх | Cообщить модератору

13. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +7 +/
Сообщение от Аноним (13), 13-Мрт-25, 15:20 
Пора это уже в спецификации языка Си указать, что буфер -- это то, за пределы чего должен выйти любой уважающий себя сишник. Закрепить, так сказать, официально этот стандарт де-факто.
Ответить | Правка | Наверх | Cообщить модератору

60. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  –1 +/
Сообщение от Смузихлеб забывший пароль (?), 14-Мрт-25, 07:49 
> из-за присвоения переменной с типом "signed short",
> участвующей в вычислении размера буфера, значения с типом "unsigned long"

Просто диды - мастера не только в индексах, но и в преобразованиях типов которые сами себе напридумывали в т.ч ради экономии на спичках, точнее, отдельных байтах

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

5. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от DeerFriend (?), 13-Мрт-25, 14:43 
freetype-2.13.1-1.fc39
created a year ago for Fedora 39

какой смысл писать про такие древности?

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

8. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +2 +/
Сообщение от НяшМяш (ok), 13-Мрт-25, 14:55 
Любители дебиана уже дуреют с 2.12.1+dfsg-5+deb12u3 прикормки.
Ответить | Правка | Наверх | Cообщить модератору

15. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  –2 +/
Сообщение от kai3341 (ok), 13-Мрт-25, 15:27 
Точно подмечено
Ответить | Правка | Наверх | Cообщить модератору

32. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноним (32), 13-Мрт-25, 18:11 
таки и не все на 12-ом (!)
2.10.4+dfsg-1+deb11u1 all
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

22. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноним (2), 13-Мрт-25, 15:53 
Всего год? В генту уязвимая 2.13.0 до сих пор стабильная. А теперь представь сколько софта тащит только эту версию (и сколько более старые), у нас же деды-специалисты говорят обновляться стыдно и в то же время юнцы-специалисты топят за статическую линковку или как минимум таскать всё бандлом.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

38. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от dannyD (?), 13-Мрт-25, 21:31 
не нада ля-ля

в генту зеленое 2.13.3

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

39. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноним (2), 13-Мрт-25, 21:33 
> не нада ля-ля
> в генту зеленое 2.13.3

все 3 зелёные (2.13.0 2.13.2 2.13.3), крайне странное решение.

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

40. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от dannyD (?), 13-Мрт-25, 21:36 
ну может зависимости какие, каким-то пакетам нужны устаревшие версии.
Ответить | Правка | Наверх | Cообщить модератору

41. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноним (2), 13-Мрт-25, 21:37 
Причём, 2.13.3 уже почти год без обновлений, хочешь свежей собирай из гита и софт к этому может весьма плохо отнестись. Ситуация довольно патовая, ключевая либа такая дохлая -- одни уязвимости добавляют по мере надобности.
Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

7. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +2 +/
Сообщение от Аноним (7), 13-Мрт-25, 14:54 
Дарка от бублика наш линукс злосчастный.
К тому же, если учесть, что код всем открыт. Чем там все кичатся.
Кто бы что ни говорил, но зачастую это банальный кактус, который мы с ехидной улыбкой, как у 20-летних заносчивых супэраутишников, жуём все вместе.
Ну.. жуём дальше господа ))
Ответить | Правка | Наверх | Cообщить модератору

59. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +1 +/
Сообщение от Аноним (59), 14-Мрт-25, 07:30 
Согласен, надо ставить проприетарную Solaris от Oracle.
Ответить | Правка | Наверх | Cообщить модератору

67. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноним (67), 14-Мрт-25, 10:34 
лучше такой же астра линкус
там манда ты
Ответить | Правка | Наверх | Cообщить модератору

61. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от ИмяХ (ok), 14-Мрт-25, 08:03 
>>код всем открыт. Чем там все кичатся.

Странный повод, чтоб кичиться. Ведь благодаря открытому коду любой школьник может прочитать diff закрытия свежей уязвимости и по быстрому написать зловред для тех, кто ещё не успел обновиться.

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

65. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноним (65), 14-Мрт-25, 10:13 
Не любому это надо, у кого-то и детство есть.
Ответить | Правка | Наверх | Cообщить модератору

9. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +2 +/
Сообщение от Аноним (9), 13-Мрт-25, 15:00 
> Amazon Linux 2, Debian stable / Devuan, RHEL 8 и 9

Вся суть "стабильных" дистрибутивов.

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

10. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноним (10), 13-Мрт-25, 15:11 
А что не так? Стабильные дистры затаскивают и бекпортируют себе фикс уязвимостей. Стабильные дистры не тащат новые фичи, которые ломают поведение библиотек/программ.
Ответить | Правка | Наверх | Cообщить модератору

18. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +2 +/
Сообщение от Аноним (-), 13-Мрт-25, 15:37 
> Стабильные дистры затаскивают и бекпортируют себе фикс уязвимостей.

Ну-ну. Проблема была исправлена еще в 2023 году.
А сейчас на календаре 2025й, но окаменевший деб все еще уязвим
security-tracker.debian.org/tracker/CVE-2025-27363

Вот где бекпорт??

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

23. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноним (10), 13-Мрт-25, 16:16 
Дак выявили проблему в этом году. Как они могли себе фикс бекпортировать, если проблема еще не была обнаружена?
Ответить | Правка | Наверх | Cообщить модератору

29. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +2 +/
Сообщение от Аноним (-), 13-Мрт-25, 16:56 
> Дак выявили проблему в этом году.

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

> Как они могли себе фикс бекпортировать, если проблема еще не была обнаружена?

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

В итоге в шта6ильных сурьезных дистрах типа RHEL9 дырень прожила на полтора года дольше чем во всяких рачах и бубунтах

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

31. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +1 +/
Сообщение от User (??), 13-Мрт-25, 17:51 
Ты не бойся, в рачах уже четыре новые слопатили)
Ответить | Правка | Наверх | Cообщить модератору

35. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноним (9), 13-Мрт-25, 21:13 
> Дак выявили проблему в этом году. Как они могли себе фикс бекпортировать, если проблема еще не была обнаружена?

Обновившись до актуальной версии, прикинь.

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

36. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноним (9), 13-Мрт-25, 21:14 
> А что не так? Стабильные дистры затаскивают и бекпортируют себе фикс уязвимостей.

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

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

11. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +2 +/
Сообщение от Аноним (11), 13-Мрт-25, 15:14 
Я забыл, дум уже запустили в шрифте или мне приснилось?
Ответить | Правка | Наверх | Cообщить модератору

45. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +2 +/
Сообщение от Аноним (44), 13-Мрт-25, 23:58 
GTA запустили
Ответить | Правка | Наверх | Cообщить модератору

51. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноним (51), 14-Мрт-25, 01:49 
https://fuglede.github.io/llama.ttf/
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

12. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Fracta1L (ok), 13-Мрт-25, 15:17 
Разрабы freetype просто не умеют писать на сишке, вот местные комментаторы никогда бы не допустили такого бага.
Ответить | Правка | Наверх | Cообщить модератору

16. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Ivan_83 (ok), 13-Мрт-25, 15:31 
> до версии 2.13.0 включительно и устранена в версии 2.13.1 (июнь 2023 года).

А что за некронвости такие!?

freetype2-2.13.3 уже стоит из портов.

Опять у растовиков обострение и пообщатся захотелось?

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

17. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +1 +/
Сообщение от Аноним (-), 13-Мрт-25, 15:35 
> А что за некронвости такие!?

Обычные некроновости для некродистров вроде Debian stable / Devuan, RHEL 8 и 9 и так далее.
Потому что исправлено оно было в июне 2023 года, но не помечено как CVE.
Поэтому бекпорта не было.

> Опять у растовиков обострение и пообщатся захотелось?

О чем тут общаться? Типикал сишная дыра, никогда такого не было и вот опять.
А вот предупредить некролюбов что нужно обновиться - это доброе дело.

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

21. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Ivan_83 (ok), 13-Мрт-25, 15:50 
> А вот предупредить некролюбов что нужно обновиться - это доброе дело.

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

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

24. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +2 +/
Сообщение от 12yoexpert (ok), 13-Мрт-25, 16:22 
все корпоративные дистры со старыми либами
Ответить | Правка | Наверх | Cообщить модератору

25. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноним (25), 13-Мрт-25, 16:28 
Годно. Теперь код необязательно запускать, достаточно открыть его в редакторе, чтобы произошел взлом.
Ответить | Правка | Наверх | Cообщить модератору

26. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноним (2), 13-Мрт-25, 16:47 
Достаточно открыть страничку в интернете без дефолтной блокировки шрифтов ublock. Будь готовые прототипы в паблике, можно было бы использовать их их для обхода цифровой тюрьмы¸а так ничего хорошего.
Ответить | Правка | Наверх | Cообщить модератору

28. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноним (-), 13-Мрт-25, 16:47 
Раньше было лучше (с)
В 2020 у них была 0-day дырень [1], которая мало того что активно эксплуатировалась.
Так еще и работала через браузер (хром и лиса).
И работала на андроиде.

Вот это уровень!

[1] opennet.ru/opennews/art.shtml?num=53922

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

33. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноним (33), 13-Мрт-25, 18:32 
Перед этим правдва надо установить нужный шрифт, и вот потом уже да.
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

30. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +1 +/
Сообщение от Аноним (30), 13-Мрт-25, 17:46 
Если это жадность до ОЗУ, то это необоснованно, т.к. в 32 битных системах переменная всё равно по факту займет 32 бита (если не извращаться, и к массивам не относится), а в 64-битной - 64. Более того, если говорить о микроконтроллерах с Cortex M, то там в некоторых случаях придется дополнительно выполнить команды SXTB, SXTH, UXTB и UXTH при операциях с меньшими по разрядности типами.
Ответить | Правка | Наверх | Cообщить модератору

37. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  –1 +/
Сообщение от Аноним (9), 13-Мрт-25, 21:19 
> т.к. в 32 битных системах переменная всё равно по факту займет 32 бита (если не извращаться, и к массивам не относится), а в 64-битной - 64

Да ты что.

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

63. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноним (63), 14-Мрт-25, 08:18 
Прикинь, в ОЗУ Cortex M0 оно так по умолчанию.
Ответить | Правка | Наверх | Cообщить модератору

42. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  –1 +/
Сообщение от Аноним (-), 13-Мрт-25, 21:38 
> в 32 битных системах переменная всё равно по факту займет 32 бита

Да ладно? Так уж и займёт 32 бита?

Попробуй такое:

struct test {
    char a;
    char b;
    char c;
    char d;
};

struct test var;

assert!(sizeof(var) == 16);

Отметь, это не массив нисколько.

> в некоторых случаях придется дополнительно выполнить команды SXTB, SXTH, UXTB и UXTH при операциях с меньшими по разрядности типами.

Ага. Это ты ещё не видел как битовые поля распаковывают в представление, над которым затем можно выполнять осмысленные операции.

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

47. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от _kp (ok), 14-Мрт-25, 00:14 
Выравнивание подобной структуры, если об упаковке явно не указано, зависит и от платформы, и от уровня оптимизации, и конкретного компилятора.

>>Ага

Полагаться на то что выдал sizeof  - некорректно.
Ваше утверждение тоже неверное.
Правильный ответ: неопределенный размер. Хотя и с большой вероятностью 32 или 128 бит, но не конкретное  значение.

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

52. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +3 +/
Сообщение от Аноним (52), 14-Мрт-25, 02:59 
> Ваше утверждение тоже неверное.

Какое утверждение? Где и что я утверждал? Вы assert сочли "утверждением"? Это не утверждение, это часть кода, которую я предлагал скомпилировать и посмотреть, что выйдет.

> Выравнивание подобной структуры, если об упаковке явно не указано, зависит и от платформы, и от уровня оптимизации, и конкретного компилятора.

Да-да.

> Полагаться на то что выдал sizeof  - некорректно.

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

> Правильный ответ: неопределенный размер.

Это не совсем правильный ответ. Одно из свойств C, которое делает его незаменимым везде, это фиксированный ABI. Да, этот ABI зависит от платформы, но как только мы определились с платформой, так сразу мы можем точно сказать, сколько байт будет занимать вышеприведённая структура. Нам не нужно для этого знать, каким компилятором для данной платформы мы будем пользоваться.

Флагами компилятора можно это всё "испортить", но, кстати, не "флагами уровня оптимизации", потому что ABI должен быть фиксированным вне зависимости от уровня оптимизации: как ты будешь вызывать функции libc, если твой уровень оптимизации меняет layout структур libc? То есть ты такой сказал -O0, для отладки, и у тебя всё сломалось, потому что libc скомпилирована с -O2 или с -Os?

Более того, я вам скажу, что ваш ответ категорически неправильный. Он истинный с формальной точки зрения (хотя бы потому, что мы всегда можем найти компилятор C, который делает не так как все), но он _абсолютно_ _бесполезен_ на практике. С философской точки зрения это банальный нигилизм, отрицание всего по каким-то метафизическим формальным причинам, с положением толстого болта на прагматику.

Таким образом _правильный краткий ответ_: размер структуры вполне определён на каждой платформе, хотя могут быть нюансы.

Более развёрнутый правильный ответ таков. Есть простое правило: alignment члена структуры равно его размеру, округлённому вверх на ближайшую степень двойки (но не больше 4 или 8 байт, в зависимости от битности системы). Таким образом, смещения членов относительно начала структуры будут 0, 1, 2 и 3, потому что alignment char'а 1 байт.

Если вы укажете мне десктопную/серверную* систему в которой это правило не работает, вместо дальнейших пустопорожних рассуждений об абстрактных опциях компилятора, то я буду премного вам благодарен. Мне всегда интересно расширить свой кругозор. А до тех пор, пока вам такую систему найти не удалось, я продолжу следовать этому правилу, располагая поля в своих структурах так, чтобы структура бы занимала минимальный размер, не упираясь в проблемы с unaligned access. Собственно то правило выше, можно переформулировать в ещё более прагматичной форме, которая прям инструкция к действию: самый простой способ минимизировать размер структуры, не сталкиваясь с ограничениями packed структур, это располагать поля в структуре в порядке уменьшения их размера.

*) эмбедщина не интересна, там свои правила, там даже соответствие в граните отлитым стандартам C весьма условно. Там уже у каждой зверюшки свои погремушки, каждая железка требует отдельного изучения особенностей архитектуры и компилятора.

> Хотя и с большой вероятностью 32 или 128 бит, но не конкретное  значение.

Что значит "не конкретное значение"? Мне не понятно это ваше заявление, равно как и ваш отказ полагаться на то, что говорит sizeof: sizeof специфически говорит о том, сколько структура занимает места в памяти (не считая padding'а после неё, который может добавляться с тем, чтобы выдержать alignment других объектов в памяти). Что вы вообще хотели сказать этим? Я вот гадаю, и единственное объяснение, которое мне приходит на ум, это то, что компилятор может хранить эту структуру распакованной в четырёх регистрах. Он запросто может проделать такое в процессе оптимизации. Распаковать из RAM в регистры, поработать с ними, потом упаковать обратно в RAM, если компилятору покажется, что это будет быстрее, чем каждый раз обращаться к индивидуальным полям структуры по адресу. Я полагаю, что и на стеке он может хранить поля этой структуры в любом порядке с любым padding'ом который ему удобно, в конце концов там делали даже ассемблерные программисты во времена DOS, потому что push на стек клал 2 байта, и запушить туда один байт было невозможно. Таким образом, если хотелось освободить регистр, сохранив байт хранящийся там, то на стек летел этот байт расширенный нулями до двух байт.

Но если вы _это_ имели в виду, то это мимо кассы. Речь идёт о layout'е структур в RAM. Аноним выше специфически хотел поговорить об этом. Это не memory layout структуры, это то что делает оптимизатор (человек или алгоритм), когда ему не надо заботиться об ABI: это временное, нефиксированное представление данных, с которым будет работать только локальный код, и оно оптимизировано под этот код.

Если же вы имели в виду что-то иное, то вам следует изложить свою мысль внятно и последовательно.

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

56. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  –1 +/
Сообщение от _kp (ok), 14-Мрт-25, 04:32 
Да, утверждение не Ваше, лишне я сказал.
Но, в остальном, мы друг друга поняли все равно верно.

>>Если вы укажете мне десктопную/серверную* систему в которой это правило не работает

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

>>эмбедщина не интересна

Сейчас там отличий от десктопного кода все меньше

>>Мне не понятно это ваше заявление, равно как и ваш отказ полагаться на то, что говорит sizeof

Не верно полагаться но именно на то, что sizeof выдаст предполагаемый размер.
А если он проверяется в рантайме, то конечно, ему тогда уже нужно доверять. ;)

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

57. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  –1 +/
Сообщение от Аноньимъ (ok), 14-Мрт-25, 04:32 
> Одно из свойств C, которое делает его незаменимым везде, это фиксированный ABI. Да, этот ABI зависит от платформы

🤣🤣🤣🤣🤣

Это капец.

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

62. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноним (63), 14-Мрт-25, 08:17 
Речь о переменных, а не о полях структуры, помимо массивов. И речь идет о жадности, а на операции с битовыми полями сколько инструкций нужно выполнить?
Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

53. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от мявemail (?), 14-Мрт-25, 04:12 
в очередной раз доказывает несостоятельность разного рода изкоробочных селинуксов и подчеркивает нужность МАСов.
Ответить | Правка | Наверх | Cообщить модератору

54. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от мявemail (?), 14-Мрт-25, 04:14 
>из-за присвоения переменной с типом "signed short", участвующей в вычислении размера буфера, значения с типом "unsigned long",

госпади, на это же все современные компиляторы жалуются.
как это произошло вообще ?

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

55. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."  +/
Сообщение от Аноньимъ (ok), 14-Мрт-25, 04:31 
Варнинги отключили. Иначе память при компиляции ими переполнялась.
Ответить | Правка | Наверх | Cообщить модератору

66. Скрыто модератором  +/
Сообщение от Аноним (65), 14-Мрт-25, 10:18 
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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