The OpenNET Project / Index page

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



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

"Уязвимость в zlib, проявляющаяся при сжатии специально оформленных данных"  +/
Сообщение от opennews (ok), 27-Мрт-22, 13:32 
В библиотеке zlib выявлена уязвимость (CVE-2018-25032), приводящая к переполнению буфера при попытке сжатия специально подготовленной последовательности символов во входящих данных. В текущем виде исследователями продемонстрирована возможность вызова аварийного завершения процесса. Может ли проблема иметь более серьёзные последствия ещё не изучено...

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

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

Оглавление

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


1. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +1 +/
Сообщение от _kusb (ok), 27-Мрт-22, 13:32 
Как же одинаковы все эти уязвимости.
Ответить | Правка | Наверх | Cообщить модератору

2. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +/
Сообщение от васёк (?), 27-Мрт-22, 13:39 
спасите мои gz архивы 😱
Ответить | Правка | Наверх | Cообщить модератору

5. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  –3 +/
Сообщение от timur.davletshin (ok), 27-Мрт-22, 13:50 
Разве оно не используется прямо тут, на opennet? Судя по заголовку, тут трафик gzip жмётся.
Ответить | Правка | Наверх | Cообщить модератору

7. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +1 +/
Сообщение от Ан2 (?), 27-Мрт-22, 14:05 
gzip - это не zlib.
Ответить | Правка | Наверх | Cообщить модератору

10. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  –5 +/
Сообщение от timur.davletshin (ok), 27-Мрт-22, 14:13 
> gzip - это не zlib

Ну, для начала, не я про gzip сказал. Я же ни слова про zlib не говорил.

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

12. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +1 +/
Сообщение от Аноним (12), 27-Мрт-22, 14:14 
Zlib это опенсорс реализация deflate, всё, что не zlib -- часто копия/форк. Тот же zip это (среди прочего) формат архива, использующий этот самый deflate (по появился он до png и zlib). А Gzip это не архив.
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

16. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  –2 +/
Сообщение от timur.davletshin (ok), 27-Мрт-22, 14:36 
Всё это конечно классно и правильно, что ты сказал. Но я советую всё же распаковать исходники Firefox и поискать там файлик deflate.c, который и надо в основном пропатчить.
Ответить | Правка | Наверх | Cообщить модератору

20. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +8 +/
Сообщение от YetAnotherOnanym (ok), 27-Мрт-22, 15:03 
> советую всё же распаковать

Давно не встречал такого филигранно тонкого троллинга.

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

3. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  –1 +/
Сообщение от Аноним (12), 27-Мрт-22, 13:42 
Мне интересно, как они получили эту последовательность? А вообще, выглядит довольно опасно, такая уязвимость может быть куда серьёзнее уязвимости в openssl и всего-то надо подставить строку текста под сжатие.
Ответить | Правка | Наверх | Cообщить модератору

6. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +5 +/
Сообщение от Аноним (6), 27-Мрт-22, 13:50 
У чувака программа падала при сжатии. Он начал копать и определил, что причина в zlib. А потом и последовательность для повторения бага подобрал.
Ответить | Правка | Наверх | Cообщить модератору

9. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +1 +/
Сообщение от Jajauma (?), 27-Мрт-22, 14:13 
Адлер сказал да ладно я всё решу(R) и уязвимость фигня

https://github.com/madler/zlib/issues/605#issuecomment-10798...

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

4. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +/
Сообщение от Аноним (4), 27-Мрт-22, 13:43 
> патч с исправлением уязвимости был предложен ещё в 2018 году, но разработчики не обратили на него внимания

Опять... 🤦

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

13. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  –1 +/
Сообщение от Аноним (13), 27-Мрт-22, 14:28 
Опен сорс пауер во всей красе.
Ответить | Правка | Наверх | Cообщить модератору

63. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +/
Сообщение от Аноним (63), 28-Мрт-22, 16:20 
Лицензия AS IS наше всё.
Ответить | Правка | Наверх | Cообщить модератору

25. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +8 +/
Сообщение от КО (?), 27-Мрт-22, 16:09 
Современным хакерам даже не нужно ничего придумывать, все в закрытых/висящих issue.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

31. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +3 +/
Сообщение от Kuromi (ok), 27-Мрт-22, 17:07 
Поэтому и появляются вот эти громкие заголовки, только на хайпе можно заставить разработчика пофиксить проблему которая в обычных условиях признается "слишком редкой, мудреной и сложной в применении"
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

69. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +/
Сообщение от adolfus (ok), 31-Мрт-22, 11:45 
Из таких проблем и состоит, например, libreoffice. Правда только на треть, у второй трети ноги растут из xml, а у третьей -- из использования ООП-наследования.
Ответить | Правка | Наверх | Cообщить модератору

8. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +/
Сообщение от commiethebeastie (ok), 27-Мрт-22, 14:07 
Так это сразу куча серверов под удар попадают.
Ответить | Правка | Наверх | Cообщить модератору

39. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +1 +/
Сообщение от Аноним (39), 27-Мрт-22, 23:29 
Осталось подсунуть файл на сервер и заставить его сжимать...
Ответить | Правка | Наверх | Cообщить модератору

47. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +/
Сообщение от Аноним (6), 28-Мрт-22, 09:26 
> Осталось подсунуть файл на сервер и заставить его сжимать...

Любой web-сервер по дефолту начнёт сжимать что укажешь.
https://en.wikipedia.org/wiki/HTTP_compression

Или волшебную последовательность можно отправить в любую форму на сайте и СУБД сожмёт их при сохранении, или прислать в числе изменений для Git.

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

70. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +/
Сообщение от Kuromi (ok), 31-Мрт-22, 20:31 
Не факт, иногда серверу надо явно включать модули сжатия. Опять же есть более новые методы, тот же brotli
Ответить | Правка | Наверх | Cообщить модератору

14. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +1 +/
Сообщение от Аноним (14), 27-Мрт-22, 14:28 
Переполнение буфера, классика
Ответить | Правка | Наверх | Cообщить модератору

15. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  –4 +/
Сообщение от Аноним (15), 27-Мрт-22, 14:31 
Ну и как обычно, Rust реализация неуязвима
https://github.com/Frommi/miniz_oxide
Ответить | Правка | Наверх | Cообщить модератору

22. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +4 +/
Сообщение от Аноним (22), 27-Мрт-22, 15:26 
Сегфолта может и не будет, но поток же будет повреждён?

Windows 10 тоже до сих пор extended разделы портит, если в самом начале EBR встречается дырка. Толку с того, что diskpart не упал, потом все равно ковыряться в hex-редакторе и вручную править смещения для EBR. Хоть на C, хоть на C#, хоть на javascript пиши...

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

33. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  –1 +/
Сообщение от Kusb (?), 27-Мрт-22, 18:04 
Haiku что-то нехорошее делает с разделами, причём по моему даже если другие были подключены только для чтения.
Ответить | Правка | Наверх | Cообщить модератору

66. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +1 +/
Сообщение от morphe (?), 29-Мрт-22, 16:17 
> Сегфолта может и не будет, но поток же будет повреждён?

Переполнение буфера выльется либо в панику (если код не обрабатвает его, проверить можно через инструменты для запрета паник https://docs.rs/no-panic), либо в ошибку
Молча проглотить в Rust будет сложно

Я посмотрел - компрессор статичных блоков везде переполнения переводит в ошибки
https://github.com/Frommi/miniz_oxide/blob/991e3154b49e56cf7...

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

67. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +/
Сообщение от morphe (?), 29-Мрт-22, 19:30 
Ну и пример из уязвимости корректно обрабатывает
Ответить | Правка | Наверх | Cообщить модератору

27. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  –3 +/
Сообщение от Аноним (27), 27-Мрт-22, 16:21 
А чего же там 68% кода на некошерной Сишке?
C 68.4%
Rust 26.4%
C++ 4.9%
Shell 0.3%
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

30. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  –2 +/
Сообщение от Аноним (39), 27-Мрт-22, 16:57 
Как обычно, взяли сишный код, обернули слоем раста...
Ответить | Правка | Наверх | Cообщить модератору

37. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +1 +/
Сообщение от Аноним (37), 27-Мрт-22, 21:34 
>> Pure rust Rust replacement for the miniz deflate/zlib encoder/decoder using no unsafe code
>> This project is organized into a C API shell and a rust crate.
>> The C API is intented to replicate the api exported from miniz, and in turn also part of zlib.
> Как обычно, взяли сишный код, обернули слоем раста...

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

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

34. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +1 +/
Сообщение от Аноним (-), 27-Мрт-22, 18:18 
> А чего же там 68% кода на некошерной Сишке?
> C 68.4%
> Rust 26.4%
> C++ 4.9%
> Shell 0.3%

С того, что как истинный Опеннетный Воен Супротив Раста - читал опой?
> miniz_oxide_C_API
> The C API is intented to replicate the api exported from miniz, and in turn also part of zlib. > The C header is generated using cbindgen

...
> the miniz C code used for tests

...
> or to compare to miniz
> $ ./travis-after-success.sh

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

45. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  –3 +/
Сообщение от Аноним (45), 28-Мрт-22, 09:06 
Чтож этот суперский раст не может сам себя протестировать. Это просто ор.  
Ответить | Правка | Наверх | Cообщить модератору

50. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +2 +/
Сообщение от Аноним (50), 28-Мрт-22, 11:23 
>> Pure rust Rust replacement for the miniz deflate/zlib encoder/decoder using no unsafe code.
>> The C API is intented to replicate the api exported from miniz,
> Чтож этот суперский раст не может сам себя протестировать.

Для неумеющих в английский, переведу: оно написано как замена miniz.
А теперь расскажи поподробнее, как именно Воен собрался тестировать совместимость c либой miniz без использования последней?

> Это просто ор.

С опеннетовского воинствующего ламерья ...


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

54. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +/
Сообщение от Аноним (54), 28-Мрт-22, 13:56 
> А теперь расскажи поподробнее, как именно Воен собрался тестировать совместимость c либой miniz без использования последней?

Какая же каша в голове.

В таких случаях пишутся заглушки которые обрабатывают запросы.
Использовать реальную библиотеку?

Какой версии?

Для какой архитектуры?

В каком окружении?

С какими параметрами собранную?

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

55. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +1 +/
Сообщение от Аноним (55), 28-Мрт-22, 14:27 
>> А теперь расскажи поподробнее, как именно Воен собрался тестировать совместимость c либой miniz без использования последней?
> Какая же каша в голове.

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

Ну да, зачем брать и прогонять _готовые_ тесты и примеры из miniz с новой либой, если можно просто написать свои заглушки ...

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

61. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +/
Сообщение от Аноним (54), 28-Мрт-22, 16:15 
> Ну да, зачем брать и прогонять _готовые_ тесты и примеры из miniz с новой либой, если можно просто написать свои заглушки ...

То есть тестироваться будет на одной архитектуре с одним набором окружения и одним набором параметров сборки.

Красавцы!

У вас все так? Или только это?

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

65. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +/
Сообщение от Аноним (-), 28-Мрт-22, 17:29 
> То есть тестироваться будет на одной архитектуре с одним набором окружения и
> одним набором параметров сборки.

Т.е., если бы Воен соизволил заглянуть дальше заголока, то знал бы, что тестироваться будет точно так же, как и miniz.
> Красавцы!
> У вас все так? Или только это?

У кого "у вас" и кто вообще "вы", Воены-Знатоки?


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

18. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +1 +/
Сообщение от YetAnotherOnanym (ok), 27-Мрт-22, 15:00 
Хммм... а ведь я не очень давно поимел странный эпизод, когда у меня почему-то при распаковке архива распаковалась только часть одного из файлов. Полдня угробил в поисках ошибки у себя, прежде чем догадался сделать просто tail и увидел, что файл битый. Не удивлюсь, если и в распаковщике какая-нибудь фигня обнаружится.
Воспроизвести не удалось.
Ответить | Правка | Наверх | Cообщить модератору

23. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +/
Сообщение от Аноним (12), 27-Мрт-22, 15:46 
Почему-то? Как можно не проверять код завершения? Я только вчера столкнулся (впервые на самом деле), что все архивы с пикабу выдают такую ошибку:

error: invalid zip file with overlapped components (possible zip bomb)
Error: extraction wasn't successfull

Распаковался только 100гб архив. Но я проверял код завершения, поэтому rm -rf /* не случился (и да, там много rm-rf в инструкциях, это удобно).

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

24. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  –1 +/
Сообщение от YetAnotherOnanym (ok), 27-Мрт-22, 16:08 
Там унзип в пайп пихал, там скрипт не ждал кода завершения.
Ответить | Правка | Наверх | Cообщить модератору

28. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +1 +/
Сообщение от Аноним (12), 27-Мрт-22, 16:22 
Звучит достаточно ненадёжно, большая часть zip архивов идёт в неправильной кодировке. Стримить можно только данные, которые пожаты потоковым компрессором.

Но и в таком случае есть всякие set -o pipefail и shopt -s inherit_errexit.

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

19. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  –2 +/
Сообщение от Gedweb (ok), 27-Мрт-22, 15:01 
Произошла чудовищная ошибка! Подобная уязвимость в любимом языке stackoverflow заняла бы 10 экарнов коментов
Ответить | Правка | Наверх | Cообщить модератору

21. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  –2 +/
Сообщение от Аноним (22), 27-Мрт-22, 15:16 
Это фиаско, такого от древнего и изученного алгоритма не ожидаешь!
Ответить | Правка | Наверх | Cообщить модератору

38. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +4 +/
Сообщение от Аноним (38), 27-Мрт-22, 21:57 
проблема в реализации, а не алоритме
Ответить | Правка | Наверх | Cообщить модератору

40. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  –2 +/
Сообщение от Аноним (39), 28-Мрт-22, 00:46 
реализация и есть своего рода алгоритм.
Ответить | Правка | Наверх | Cообщить модератору

43. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +1 +/
Сообщение от Брат Анон (ok), 28-Мрт-22, 07:56 
Вы путаете понятие "программирование" и "кодинг".
Алгоритм стоит уровнем выше реализации. Реализации может не быть, а алгоритм будет.
Реализаций может быть несколько, а алгоритм один.
И проблема здесь -- в дырявом Си и псевдобезопасном Расте, который дырявость Си заметает под ковёр ансейва.
Самое плохое решение -- делать вид, что ты умный и красивый таковым не являясь. Го в этом смысле -- гораздо честнее. Старается не лезть в Си и не обещает того, что невозможно.
Ответить | Правка | Наверх | Cообщить модератору

46. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  –1 +/
Сообщение от Аноним (45), 28-Мрт-22, 09:08 
Сказал А говори Б. Го это второй божественный раст.  
Ответить | Правка | Наверх | Cообщить модератору

49. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +2 +/
Сообщение от PnD (??), 28-Мрт-22, 11:04 
Тогда уж java. После лечебного голодания и трудотерапии.

* Я ещё помню флэш-моб времён фидонета "перепишем всё с C на Java". И "java-процессоры" (там до 2010 движ продолжался и даже остался кое-какой выхлоп в виде "продвинутого" сборщика мусора).
История повторяется через ≈25 лет. Но, похоже что в виде фарса. Ресурсов нету на новый банкет.

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

56. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  –2 +/
Сообщение от burjui (ok), 28-Мрт-22, 14:46 
Вот чего у растохейтеров не отнять, так это умение приплести Rust к любой теме.
Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

57. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  –2 +/
Сообщение от burjui (ok), 28-Мрт-22, 14:58 
И да, unsafe (читается "ансейф") - не для заметания под ковёр, а для локализации небезопасных операций, которые всё равно неизбежны. Просто когда нужно убедиться в корректности реализации, в Rust ты вручную проверяешь только блоки unsafe, а в C - весь код. И ничего невозможного Rust не обещает, в документации прямо сказано, что безопасность работы с памятью гарантирована только для той части кода, которая не обёрнута в unsafe. В типичном проекте на Rust это 100% кода, потому что unsafe нужен крайне редко для нетривиальных вещей.

Короче, RTFM нубы, надоело уже читать ваш straw man бред.

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

58. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +1 +/
Сообщение от Брат Анон (ok), 28-Мрт-22, 15:42 
> Короче, RTFM нубы, надоело уже читать ваш straw man бред.

Угу. Ждём дыру в компиляторе, связанную с концепцией владения и гонкой данных.
Всё впереди.

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

59. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  –2 +/
Сообщение от burjui (ok), 28-Мрт-22, 16:12 
Баги есть в любом ПО. Давайте не будем писать на C тогда, а то вдруг компилятор сгенерит некорректный машинный код.
Ответить | Правка | Наверх | Cообщить модератору

60. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  –2 +/
Сообщение от burjui (ok), 28-Мрт-22, 16:13 
А чего мелочиться, давайте не использовать ПО вообще.
Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

62. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +1 +/
Сообщение от Аноним (63), 28-Мрт-22, 16:15 
Просто ты недалекий пыхер. Твой уровень интеллекта это максимум «не использовать ПО ваще». Мне тебя жалко.  
Ответить | Правка | Наверх | Cообщить модератору

64. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  –2 +/
Сообщение от burjui (ok), 28-Мрт-22, 16:51 
Пожалей лучше себя. И при чём тут вообще "пыхер"?
Ответить | Правка | Наверх | Cообщить модератору

68. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +/
Сообщение от morphe (?), 29-Мрт-22, 19:39 
Такие есть и были, но это именно что баги, которые со временем пофиксят, и которые не проявляются при нормальных условиях

Баги в borrow чекере позволяют лишь писать некорректный код, но сами по себе баги в коде не создают, т.к borrow checker не влияет на поведение

В данный момент есть 2 давно живущих такие баги:
https://github.com/rust-lang/rust/issues/25860
https://github.com/rust-lang/rust/issues/85099 (Не совсем в borrow checkerе, но близко)

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

71. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +/
Сообщение от Andrew (??), 01-Апр-22, 13:04 
...в unsafe требуется оборачивать даже разыменовывание указателя - эта операция требуется в любой производительной современной программе, чуть сложнее "привет мир". Я как только это увидел, сразу закинул Rust за шкаф, и продолжил дальше на Go.
Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

72. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +/
Сообщение от burjui (ok), 01-Апр-22, 19:34 
Вот мне всегда было интересно: каково это - быть упёртым хейтером. Наверное, это сродни религии.

Ссылки в Rust - это просто указатели, для которых компилятором даются определённые СТАТИЧЕСКИЕ гарантии (во время компиляции). Разыменование ссылки, явное или неявное (скажем, через вызов метода) - то же самое, что и разыменование указателя. Скептикам - rust.godbolt.org в помощь:

pub fn add1(num: &i32) -> i32 {
    *num + 1
}

Добавляем флаг -C opt-level=1 (самый слабый уровень оптимизаций) и видим:

example::add1:
        mov     eax, dword ptr [rdi]
        add     eax, 1
        ret

Ну как, достаточно производительно?

Оптимизации, если что - для краткости листинга. Без оптимизаций (-C opt-level=0) разыменование будет точно такое же, только будет добавлена обработка переполнения при сложении:

example::add1:
        push    rax
        mov     eax, dword ptr [rdi]
        inc     eax
        mov     dword ptr [rsp + 4], eax
        seto    al
        test    al, 1
        jne     .LBB0_2
        mov     eax, dword ptr [rsp + 4]
        pop     rcx
        ret
.LBB0_2:
        lea     rdi, [rip + str.0]
        lea     rdx, [rip + .L__unnamed_1]
        mov     rax, qword ptr [rip + core::panicking::panic@GOTPCREL]
        mov     esi, 28
        call    rax
        ud2

.L__unnamed_1:
        .quad   .L__unnamed_2
        .asciz  "\017\000\000\000\000\000\000\000\002\000\000\000\005\000\000"

str.0:
        .ascii  "attempt to add with overflow"

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

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

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

73. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +/
Сообщение от Andrew (??), 03-Апр-22, 20:03 
Да кому нужно голову морочать с Rust, тратить в 3-5 раз больше времени на язык, который ржавчиной обозвали и сделали в нем синтаксис еще хуже чем в птичьем языке, когда в Go есть всё что надо и указатели нормальные, и они работают как указатели. И В Go наверное уже лучший сборщик мусора в мире среди всех языков. Ваш пример с ассемблером в основной массе никому не нужен, даже для драйверов уже не нужен почти нигде, это удел гиков.
Ответить | Правка | Наверх | Cообщить модератору

48. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +1 +/
Сообщение от test (??), 28-Мрт-22, 10:34 
А это точно не на бекдоор наткнулись ? Сложно представить последовательность влияющую на это.
Ответить | Правка | Наверх | Cообщить модератору

51. "Уязвимость в zlib, проявляющаяся при сжатии специально оформ..."  +2 +/
Сообщение от Аноним (63), 28-Мрт-22, 12:03 
Конечно же нет такого не может быть. Это фантастика. Ты разве когда-нибудь видел чтобы бекдоры вставляли специально. Бред какой-то.  Ты смотришь неправильные ТВ каналы, тебя там наймиты зазомбировали. Начиная с этой строчки ты забудешь что такое бекдоры и что они вообще существуют.
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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