The OpenNET Project / Index page

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



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

Оглавление

Google представил открытый стек OpenSK для создания криптогр..., opennews (??), 30-Янв-20, (0) [смотреть все]

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


6. "Google представил открытый стек OpenSK для создания криптогр..."  +6 +/
Сообщение от proninyaroslavemail (ok), 31-Янв-20, 00:16 
Low level programming сплошь и рядом unsafe, так как предполагает применение машинных инструкций, чтений/записи по сырым указателям на адреса в памяти и прочей низкоуровневой магии. Но, опять таки, поверх этого unsafe можно и нужно делать safe код, в чём раст и помогает.
Ответить | Правка | Наверх | Cообщить модератору

10. "Google представил открытый стек OpenSK для создания криптогр..."  –8 +/
Сообщение от Аноним (10), 31-Янв-20, 02:28 
safe построенный поверх unsafe автоматически превращается в тыкву. Т.о. главнпя мантра растофилов обнуляется, а запредельная сложность, кривой дизайн и уёбищный синтаксис остаются.
Ответить | Правка | Наверх | Cообщить модератору

15. "Google представил открытый стек OpenSK для создания криптогр..."  +/
Сообщение от Аноним (15), 31-Янв-20, 02:40 
Зато запихнули какую-то операционку в стремный нордик, еще и с проприетарным беспроводным стеком небось, потребовался аж M4F навороченный... в общем все прелести hype driven development.
Ответить | Правка | Наверх | Cообщить модератору

18. "Google представил открытый стек OpenSK для создания криптогр..."  +6 +/
Сообщение от qetuo (?), 31-Янв-20, 04:40 
Safe код безопасен тогда, когда безопасна прослойка Unsafe снизу. Для прослойки Unsafe гарантии предоставляет программист, для Safe -- компилятор. Так, в отличие от С/С++, код разбивается на два множества, одно из которых корректно (с точки зрения языка), если корректно другое. Если твоя программа оказалась тыквой, то, скорее всего, именно ты виноват в некорректном коде в Unsafe. Никто не винит sudo за возможность удалить /, но почему-то многие винят Unsafe за возможность писать по рандомному указателю.
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

20. "Google представил открытый стек OpenSK для создания криптогр..."  –2 +/
Сообщение от Аноним (20), 31-Янв-20, 07:45 
Можно подумать что в других языках по другому
Ответить | Правка | Наверх | Cообщить модератору

21. "Google представил открытый стек OpenSK для создания криптогр..."  +2 +/
Сообщение от qetuo (?), 31-Янв-20, 08:36 
Да все точно так же. Просто в расте оно явно разделено, ну и гарантий побольше за счет лайфтаймов. clang похожее умеет, но там нужно флаги подтыкать, да и на уровне языка не хватает конструкций.
Ответить | Правка | Наверх | Cообщить модератору

23. "Google представил открытый стек OpenSK для создания криптогр..."  –2 +/
Сообщение от Аноним (-), 31-Янв-20, 09:07 
> Можно подумать что в других языках по другому

Ну, чо, в Ada классно придумали - аналог VLA сделать. Так что парой нехитрых действий можно поиметь грабель покруче сишников. При том те то хотя-бы догадываются с какой стороны грабли могут прилететь, а господа "за меня подумает компилер и рантайм" просто получают ручкой по затылку. ВНЕЗАПНО.

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

49. "Google представил открытый стек OpenSK для создания криптогр..."  +/
Сообщение от other_anonymous (?), 31-Янв-20, 18:30 
А можно поподробней? Что вы понимаете под "парой нехитрых действий можно поиметь грабель покруче сишников" и что такое "аналог VLA"?
Ответить | Правка | Наверх | Cообщить модератору

55. "Google представил открытый стек OpenSK для создания криптогр..."  –1 +/
Сообщение от Аноним (-), 01-Фев-20, 09:46 
Ну вот то - выделение памяти под массивы переменного размера в рантайме. И если этой фичой безбашенно попользоваться, например, из внешнего параметра формируемого фиг знает как, однажды все очень красиво загнется и вся надежность отправится лесом. При том зачем такой прострел пятки именно в аде - я так и не понял.
Ответить | Правка | Наверх | Cообщить модератору

59. "Google представил открытый стек OpenSK для создания криптогр..."  +/
Сообщение от Аноним (59), 01-Фев-20, 13:33 
> Ну вот то - выделение памяти под массивы переменного размера в рантайме.

Нет.

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

То ли дело просто выделять память (подсказка: unconstrained массивы совершенно ни при чем) c внешнего фиг знает как формируемого параметра.

> - я так и не понял.

Это тут ключевое.

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

68. "Google представил открытый стек OpenSK для создания криптогр..."  +/
Сообщение от Аноним (-), 02-Фев-20, 07:08 
> Нет.

Да. Можно делать выделение памяти без выделения памяти. Еще один баянный метод проверить что будет - сделать бесконечную рекурсию.

Кстати с последним вышел облом, я это под cortex M запилил, мне было интересно посмотреть как вообще сработает кастомный обработчик hardfault. А оно хренась и не падает?! Оказывается GCC шибко умный, заинлайнил все, на выделение стэка забил. Так что микроконтроль с мизером памяти наворачивает себе бесконечную рекурсию. Сюрприз!

> То ли дело просто выделять память (подсказка: unconstrained массивы совершенно ни при
> чем) c внешнего фиг знает как формируемого параметра.

А на сях можно и не выделять. Ну вон на том мк вообще *alloc и free нету. И единственный способ таким манером пятку себе подстрелить - как раз поюзать VLA из C99. И собственно одна из причин по которой их не советуют - надежность снижают.

> Это тут ключевое.

Ну вы то как эксперт в управлении памятью нам ща урок грамотности дадите? :)

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

70. "Google представил открытый стек OpenSK для создания криптогр..."  +/
Сообщение от Аноним (59), 02-Фев-20, 16:30 
>> Нет.
> Да. Можно делать выделение памяти без выделения памяти. Еще один баянный метод проверить что будет - сделать бесконечную рекурсию.

Нет. Для начала, определитесь: выделять или не выделять, потому что ранее вы сами же писали о "выделение памяти под массивы переменного размера в рантайме."
Повторю еще раз, для экспертов выделения без выделения и прочей диалектики: unconstrained массивы в Аде - не аналог VLA.

> Кстати с последним вышел облом, я это под cortex M запилил, мне
> было интересно посмотреть как вообще сработает кастомный обработчик hardfault. А оно хренась и не падает?! Оказывается GCC шибко умный, заинлайнил все, на
> выделение стэка забил. Так что микроконтроль с мизером памяти наворачивает себе бесконечную рекурсию. Сюрприз!

Очень интересно (нет) и познавательно (тоже на самом деле нет) - вы открыли для себя новые грани современной оптимизации компиляторами для бесконечной рекурсии и сделали вывод что "налог VLA" в Аду работает так же  грабельно как и в GCC?

Еще раз, для экспертов по интересному смотрению: unconstrained массивы в Аде - не аналог VLA.

>> Ну вот то - выделение памяти под массивы переменного размера в рантайме.
>> например, из внешнего параметра формируемого фиг знает как,
> А на сях можно и не выделять.

Так выделять или не выделять?

> Ну вон на том мк вообще *alloc и free нету.

Это прекрасно, но непонятные претензии были к Аде (потому что аноним решил, что фичи там должны быть реализованны так же, как в GCC)

Т.е. по вашему, реализация ады все равно вставит заглушки для выделения памяти и будет крешится или где?
Это не так:
http://docs.adacore.com/live/wave/gnat_ccg/html/gnatccg_ug/g...
> Dynamic Memory Handling
> The use of dynamic memory (access types, aka pointers) is supported by the
> GNAT Pro CCG compiler, and will generate calls to the standard C functions
> malloc() (for memory allocation) and free() (for deallocation). If dynamic
> memory is used in the Ada sources, then malloc() and possibly free() need to
> be provided by the C compiler.

Идем далее - я так понял, тут был спры^W кейс сильно урезанного рантайма. Что ж:

https://docs.adacore.com/gnathie_ug-docs/html/gnathie_ug/gna...


No_Allocators,  -- This restriction ensures at compile time that there are no occurrences of an allocator.
No_Implicit_Heap_Allocations,            -- (RM D.8(8), H.4(3))
No_Implicit_Loops,  
No_Protected_Type_Allocators,  


5.1.13. No_Anonymous_Allocators
[RM H.4] This restriction ensures at compile time that there are no occurrences of an allocator of anonymous access type.

Или это был намек, что Адисты не Сишники, а значит – по умолчанию глупые и недалекие люди и не знают, где и как у них там выделяется память?
Позвольте и тут усомниться.

>> Так что парой нехитрых действий можно поиметь грабель покруче сишников.
> И единственный способ таким манером пятку себе подстрелить - как раз поюзать VLA из C99. И собственно одна из причин по которой их не советуют - надежность снижают.

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


>> Это тут ключевое.
> Ну вы то как эксперт в управлении памятью нам ща урок грамотности дадите? :)

Хотя вы, как известный эксперт по необоснованным заявлениям, ценному мнению и дартаньянствованию, с последующим спрыгам с темы, уже соломки подстелили, приплетя тут МК и "вообще *alloc и free нету", так и быть:
https://docs.adacore.com/gnat_ugx-docs/html/gnat_ugx/gnat_ug...
> The Secondary Stack
> GNAT returns objects from functions via registers (if small) or via the
> primary stack. For the latter, the caller of the function typically
> allocates space for the return object on its primary stack before the call.
> However, Ada allows functions to return objects of unconstrained types, for
> example unbounded array types such as String, and unconstrained
> discriminated record types
>  In this case the caller does not know the size of the returned object at the point of the call.
> To resolve this problem, GNAT provides each task with a secondary stack that objects of unconstrained types are returned on. On native and cross targets using the full run-time, the secondary stack by default is allocated dynamically on the heap.

Надеюсь, что такое "using full run-time" и каковы последствия, объяснять не надо?
На всякий случай, цитирую еще из возможных опций урезания рантайма:

https://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/s...
>  No_Secondary_Stack
> [GNAT] This restriction ensures at compile time that the generated code does
> not contain any reference to the secondary stack. The secondary stack is
> used to implement functions returning unconstrained objects (arrays or
> records) on some targets
. Suppresses the allocation of secondary stacks for
> tasks (excluding the environment task) at run time.

Все еще с нетерпением ждем список граблей "круче и неочевидней" сишных.

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

52. "Google представил открытый стек OpenSK для создания криптогр..."  +/
Сообщение от анонн (ok), 31-Янв-20, 20:57 
>> Можно подумать что в других языках по другому
> Ну, чо, в Ada классно придумали - аналог VLA сделать.

https://www.adaic.org/resources/add_content/docs/craft/html/...?
> Ada95
> The bounds of an array don’t have to be static; you’re allowed to calculate
> them at run time:
>    Appts : Appt_Array (1..N);   -- N might be calculated when the program is run

Заодно стырив машину времени!

> Так что парой нехитрых действий можно поиметь грабель покруче сишников. При том те то хотя-бы догадываются с какой стороны грабли могут прилететь, а господа "за меня подумает компилер и рантайм" просто получают ручкой

В чем именно "покруче" можно поиметь грабель? Или аноним, как обычно, слышал звон?

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

29. "Google представил открытый стек OpenSK для создания криптогр..."  +/
Сообщение от Аноним (29), 31-Янв-20, 11:06 
по другому, потому во всех других языках, кроме rust, безопасная часть - интерпретируемая или JIT-компилируемая (== более медленная чем нативный код)
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

38. "Google представил открытый стек OpenSK для создания криптогр..."  +2 +/
Сообщение от Аноним (38), 31-Янв-20, 13:32 
Переведу просто безопасная часть становится небезопасной. Никакого профита раст не дает. Даже скорость разработки у него не выше.
Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

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

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




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

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