The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..., opennews (??), 27-Май-20, (0) [смотреть все]

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


35. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."  +1 +/–
Сообщение от Аноним (-), 27-Май-20, 14:12 
Это C89 античный. И это грабли - потому что на разных железках размер int не гарантирован одинаковым. Это создает поле для багов.
Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

53. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."  +2 +/–
Сообщение от Lex (??), 27-Май-20, 15:51 
По большому счету, у него вообще не должно быть «размера».
А то, это уже какой-то byte/word/dword/итп, а не типо_абстракция_для_высокоуровневого_языка
Ответить | Правка | Наверх | Cообщить модератору

63. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."  +/–
Сообщение от Аноним (61), 27-Май-20, 16:54 
C и не является языком высокого уровня. Проходит по категории среднего.
Ответить | Правка | Наверх | Cообщить модератору

67. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."  –2 +/–
Сообщение от Аноним (64), 27-Май-20, 17:27 
> C и не является языком высокого уровня. Проходит по категории среднего.

Он разный. Вон libcello показывает как из него слепить нечто довольно высокоуровневое. Если оно зачем-то надо. Некоторые на нем умудряются объекты наворачивать. Хоть их изначально там и нет.

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

83. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."  +1 +/–
Сообщение от Аноним84701 (ok), 27-Май-20, 19:31 
>> C и не является языком высокого уровня. Проходит по категории среднего.
> Он разный. Вон libcello показывает как из него слепить нечто довольно высокоуровневое.
> Если оно зачем-то надо. Некоторые на нем умудряются объекты наворачивать. Хоть
> их изначально там и нет.

Э-э-э, я вас расстрою, но возможность с помощью костыле и подпорок придать похожий вид - ну совершенно не показатель "высокоуровневости":


while GetMessage(ADDR msg, 0,0,0) 
.if !TranslateAccelerator(hwnd, hAccel, ADDR msg) 
    invoke TranslateMessage, ADDR msg 
    invoke DispatchMessage, ADDR msg 
.endif 
.endw
...
   CLASS CSprite
      CMETHOD destructor 
      CMETHOD setBitmap    ; sets bitmap for sprite
      CMETHOD move     ; move sprite
 ...
      yPos   dd  ?
      speed   dd  ?
   CSprite ENDS

LOCAL TempRect:RECT
 invoke GetClientRect, hWnd, ADDR TempRect
 xor  ebx, ebx
 .WHILE ebx < MAX_SMILIES
  newobject CSprite
...
  method esi, CSprite, setBitmap, eax

Это древний MASM, если что.
Возможность наколхозить макросами "типа OOP", функц. вызовы и прочее - и близко не дает поддержку на уровне компилятора соотв. ЯП (тех же проверок синтаксиса, семантики и особенно нормальных сообщений об ошибках).
Ответить | Правка | Наверх | Cообщить модератору

116. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."  +/–
Сообщение от Аноним (116), 28-Май-20, 17:01 
> похожий вид - ну совершенно не показатель "высокоуровневости":

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

> 

 
>   method esi, CSprite, setBitmap, eax 
...
>

> Это древний MASM, если что.

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

> Возможность наколхозить макросами "типа OOP", функц. вызовы и прочее - и близко
> не дает поддержку на уровне компилятора соотв. ЯП (тех же проверок
> синтаксиса, семантики и особенно нормальных сообщений об ошибках).

Все это вообще совсем другой вопрос, не имеющий отношения к уровневости языка как такового. И это, у совсем высокоуровневых с диагностикой как раз полный швах, пихоны и явыскрипты валятся в runtime, чем немало задалбывают. Потому что вместо прогера это все валится сразу юзерям на бошку.

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

66. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."  +/–
Сообщение от Аноним (64), 27-Май-20, 17:26 
> По большому счету, у него вообще не должно быть «размера».

Офигенно. До тех пор пока не захочется
- Сделать что-то с данными в памяти.
- Сохранить это в файл.
- Передать это по сети.

...и чтоб с другой стороны еще и поняли что именно им передали, например?! И желательно не в ламерском вебмакачном представлении когда число 100500 занимает цуко 6 байтов хотя реально лезет в 3. А, ну да, правильные парни используют конские либы сериализации или плачутся как это трудно, да? :)

> А то, это уже какой-то byte/word/dword/итп, а не типо_абстракция_для_высокоуровневого_языка

Си хорош тем что позволяет залезать в довольно низкоуровневые дела. Один из немногих ЯП который смог подвинуть асм в глубоко системных вещах. И в этом плане - ну вот есть у вон той железки допустим регистр. И он 16 битов. Потуги обращаться к нему с другими порциями - ни к чему хорошему не ведут. И очень хорошо что можно задекларить сие как uint16_t, допустим.

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

86. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."  –1 +/–
Сообщение от Lex (??), 27-Май-20, 20:14 
И... что ?
Без какого-либо стандарта передачи данных, на другом конце всё равно не поймут, хоть запередавайся.

Такое «оправдание» откровенно дырявой абстракции - даже хуже вебмакакства.

Если речь о работе с числами, то совершенно очевидно, что работать оно должно ожидаемо, а не черти как.. и всё из-за того, что «силой гения высоколобых умников нельзя просто взять и работать с числами».
В конечном счёте это, скорее всего, упирается ни в какие не в размеры( слыхал что-нибудь о выравнивании, на котором прямо сейчас, скорее всего, гораздо больше памяти тратится ), а в оптимизации вычислений, т.к 64-битной машине считать 32-битные числа будет таки ощутимо проще, чем 8-битному «процу». Вот отсюда, скорее всего, и растут ноги сего цирка с числами.

п.с: кстати о размере.. интересно, а у строк тоже ограничение на размер - 8/16/32/64 байта или, всё-таки, нет и, тем не менее, на другом конце их при передаче отлично «понимают» ?)

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

117. "25 уязвимостей в RTOS Zephyr, в том числе эксплуатируемые че..."  +/–
Сообщение от Аноним (-), 28-Май-20, 17:13 
> И... что ?

И - то. Абстрактный int - совсем не то же что uint32_t. Когда у меня есть последний - я точно знаю что он может быть передан как 4 байта (в провод, воздух, файл, ...). А когда это int - вот тут уже большой вопрос как это передавать, как понять сколько это займет, ...

> Без какого-либо стандарта передачи данных, на другом конце всё равно не поймут,
> хоть запередавайся.

Да блин, с int неизвестного размера вы даже прочитать записанный собой же файл так с наскока не сможете - а откуда вы знаете где этот int заканчивается? Есть некоторые variable-length кодировки integer'ов, но они как раз "транспортные" и неэффективны на тему применения математики сразу к этому представлению процом.

> Такое «оправдание» откровенно дырявой абстракции - даже хуже вебмакакства.

Глядя на то как электроны выжирают ресурсы - я что-то не уверен.

> Если речь о работе с числами, то совершенно очевидно, что работать оно
> должно ожидаемо, а не черти как.. и всё из-за того, что
> «силой гения высоколобых умников нельзя просто взять и работать с числами».

Ну и вот uint32_t по сравнению с int хрен знает какого размера - это вот как раз в эту сторону шаги. Так мы по крайней мере знаем сколько в этот тип лезет и можем осмысленно состыковывать это с теми данные которые жуем. А если это int какой-то, который на вон той системе еще и не столько, а столько - упс.

> размеры( слыхал что-нибудь о выравнивании, на котором прямо сейчас, скорее всего,
> гораздо больше памяти тратится )

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

> машине считать 32-битные числа будет таки ощутимо проще, чем 8-битному «процу».
> Вот отсюда, скорее всего, и растут ноги сего цирка с числами.

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

> п.с: кстати о размере.. интересно, а у строк тоже ограничение на размер
> - 8/16/32/64 байта или, всё-таки, нет и, тем не менее, на
> другом конце их при передаче отлично «понимают» ?)

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

В этом месте вебмакаки кажется начинают догадываться, что парсинг строк далеко не самое эффективное занятие на свете. А потом приходит гугл, берет БОЛЬШОЙ тапок и объявляет: извините. ребята, но мы заколебались платить за сервера и трафик. Поэтому HTTP/2 будет бинарным, и ниипет.

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

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

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




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

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