Профиль: Аноним (вход | регистрация) неRU opennet.me  
The OpenNET Project / Index page

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



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

"При переводе Firefox на zlib-rs разработчики натолкнулись на ошибку в CPU Intel"  +/
Сообщение от opennews (??), 17-Июн-26, 13:22 
Организация Trifecta Tech Foundation, развивающая такие проекты, как ntpd-rs, sudo-rs, zlib-rs и bzip2-rs, рассказала о переходе Firefox на использование библиотеки zlib-rs, написанной на языке Rust, для сжатия и распаковки c использованием метода gzip. Кроме защиты от проблем, вызванных ошибками при работе с памятью, переход с zlib на  zlib-rs привёл к заметному повышению производительности - в проведённых тестах ускорение составило от 3.3 до 32.5 раз при единичных операция декодирвоания и от 2.7 до 10.86 раз при декодировании непрерывного потока...

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

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

Оглавление

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


1. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (1), 17-Июн-26, 13:22 
> переход с zlib на zlib-rs привёл к заметному повышению производительности - в проведённых тестах ускорение составило от 3.3 до 32.5 раз при единичных операция декодирвоания и от 2.7 до 10.86 раз при декодировании непрерывного потока

А вотъ если бы замѣнили zlib на zlib-ng, приростъ былъ бы еще больше.

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

3. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +10 +/
Сообщение от Аноним (3), 17-Июн-26, 13:26 
zlib-ng-rs
Ответить | Правка | Наверх | Cообщить модератору

6. Скрыто модератором  +4 +/
Сообщение от Аноним (6), 17-Июн-26, 13:35 
Ответить | Правка | Наверх | Cообщить модератору

61. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +8 +/
Сообщение от Куклочай (?), 17-Июн-26, 14:39 
zlib-ng разрабы:
- Ну да, ну да, пошел я нахрен

А если честно у них бенчмарки еще лучше и производительнее для avx512, avx2 в сравнении с zlib-rs

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

365. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (365), 19-Июн-26, 16:33 
*Исправлено в 152.0.1
https://www.firefox.com/en-US/firefox/152.0.1/releasenotes/
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +5 +/
Сообщение от Аноним (3), 17-Июн-26, 13:25 
Intel всё. Не покупайте последние поколения его процессоров.
Ответить | Правка | Наверх | Cообщить модератору

15. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +6 +/
Сообщение от Аноним (365), 17-Июн-26, 13:47 
13 и 14 поколения это не последние.
Ответить | Правка | Наверх | Cообщить модератору

20. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (365), 17-Июн-26, 13:55 
https://en.wikipedia.org/wiki/List_of_Intel_CPU_microarchite...
Ответить | Правка | Наверх | Cообщить модератору

236. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +3 +/
Сообщение от Аноним (236), 18-Июн-26, 00:56 
Очень похоже, что нейроslop пробрался уже и в процы.
Ответить | Правка | Наверх | Cообщить модератору

31. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +11 +/
Сообщение от Аноним (3), 17-Июн-26, 14:04 
Для меня все после 2020 последние)
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

36. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (365), 17-Июн-26, 14:07 
Ваше право, но вводить в заблуждения не надо.
Ответить | Правка | Наверх | Cообщить модератору

65. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от КО (?), 17-Июн-26, 14:43 
Дак а где выше Raptor и Arrow то купить, лол
Ответить | Правка | Наверх | Cообщить модератору

73. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –2 +/
Сообщение от Аноним (365), 17-Июн-26, 14:50 
В смысле ? В магазинах, на маркетплейсах.

Из десктопных после 14-го поколения вышли модели Arrow Lake и Arrow Lake Refresh.
В мобильном сегменте после 14-го вышли Meteor Lake, Lunar Lake, Arrow Lake, Panther Lake.

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

188. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (3), 17-Июн-26, 21:16 
Так из десктопных только Arrow Lake следующие если верить комментарию ниже)

Nova Lake ещё не вышла

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

189. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (3), 17-Июн-26, 21:16 
Точнее выше)
Ответить | Правка | Наверх | Cообщить модератору

190. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (3), 17-Июн-26, 21:19 
https://en.wikipedia.org/wiki/Arrow_Lake_(microprocessor)#:~:text=History
Ответить | Правка | К родителю #188 | Наверх | Cообщить модератору

198. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (365), 17-Июн-26, 21:33 
>из десктопных только Arrow Lake

Хороши процы, 250K Plus и 270K Plus лучшие за свой прайс.

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

200. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (365), 17-Июн-26, 21:38 
>250K Plus

https://3dnews.ru/1142277/

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

117. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (117), 17-Июн-26, 16:39 
Всё, что после Prescott, последние.
Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

26. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Анонимemail (26), 17-Июн-26, 13:59 
А почему не покупать процессоры Intel?
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

30. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (3), 17-Июн-26, 14:04 
Гугл "загрязнение на фабрике intel"
Ответить | Правка | Наверх | Cообщить модератору

151. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –4 +/
Сообщение от Bottle (-), 17-Июн-26, 17:57 
Потому что Advanced Marketing Devices.
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

29. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +3 +/
Сообщение от Ivan_83 (ok), 17-Июн-26, 14:02 
Так уже давно, как накупил ам4 на старте (и потом тоже) так и сижу до сих пор и потребности в ам5 или чём то более свежем не ощущаю совсем. А прошло то уже 9 лет.
Думаю что года до 2035 будет вполне норм.

А про иинтел смотрел как 13 поколение с кривым микрокодом само себя убивало турбобустом.

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

143. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (365), 17-Июн-26, 17:26 
>Думаю что года до 2035 будет вполне норм

Просто вы закрываете глаза на уязвимости AMD.
Пролистайте список за последние года два-три:
https://www.opennet.ru/keywords/amd.html

>само себя убивало турбобустом

Загуглите для полноты картины:
«ryzen 5000 сгорают»
«ryzen 7000 сгорают»
«ryzen 9000 сгорают»

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

191. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (3), 17-Июн-26, 21:20 
> уязвимости

Какие из них варианты Spectre?)

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

240. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +2 +/
Сообщение от Аноним (365), 18-Июн-26, 01:44 
>Какие из них варианты Spectre?

- https://opennet.ru/56835-amd
- https://opennet.ru/54890-amd

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

217. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 17-Июн-26, 23:28 
А что мне с тех "уязвимостей"?
Я и апдейты микрокода не накатываю, хотя мог бы - всего то пара строчек в конфигах чтобы включить.

Не знаю у кого там что сгорает, у меня за всё время только ryzen 1300x заглючил: система после аптайма в 2+ суток вешалась на мертво.
И в отличии от дятлов "мне на все деньги!!!!" я выключаю буст и летом ещё и частоты скидываю, так что оно у меня выше 60С не греется, и напругу понижаю, так чтобы выше 1,1В не было.

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

245. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –2 +/
Сообщение от Аноним (245), 18-Июн-26, 02:17 
> я выключаю буст и летом ещё и частоты скидываю, так что оно у меня выше 60С не греется, и напругу понижаю, так чтобы выше 1,1В не было.

М мог бы просто юзать нормальный CPU и не страдать фигней.

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

290. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 16:28 
Это какой?
Они все нынче кипятильники с автобустом.
Ответить | Правка | Наверх | Cообщить модератору

317. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 18-Июн-26, 22:22 
Такой, который не сгорает от перегрева. То есть НЕ AMD.
Ответить | Правка | Наверх | Cообщить модератору

318. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 22:36 
Это вы мне страшилку времён 2002-2003 годов напоминаете?
В остальном отключаете турбобуст, местами даже даунвольтильнг делать не надо и всё работает стабильно и не шибко греется.
Ответить | Правка | Наверх | Cообщить модератору

331. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 19-Июн-26, 02:26 
> Это вы мне страшилку времён 2002-2003 годов напоминаете?

Времен 2025 года:

https://www.opennet.ru/opennews/art.shtml?num=63786

Ну и выше тебе как бы подсказку дали https://www.opennet.ru/openforum/vsluhforumID3/140482.html#143

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

364. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 19-Июн-26, 16:24 
А возможно что там сосед за стенкой собрал ускоритель заряженных частиц и хреначил им.
Подтверждения то так и не было.

Кроме того, я уже писал что буст надо выключать, делать андервольтинг по необходимости, тогда и проц не будет грется.
Это вопрос даже не столько к инженерам АМД/интела сколько к их маркетинговым отделам которые авторазгон врубают до предела.

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

97. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (97), 17-Июн-26, 15:47 
Конечно всё... Теперь только RTX-Spark.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

251. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от MihaNixemail (ok), 18-Июн-26, 04:36 
Почему последние?
Даже в старых устройствах бывают ошибки. У меня, например, старый Atom до сих пор служит. Он работает хорошо и почти без проблем. Однако есть одна проблема: некоторые инструкции значительно замедляют вычисления. Некоторые сразу вызывают зависание системы. Иногда случаются сбои при загрузке. Со временем случаи неудачной загрузки стали происходить чаще.

В 99% случаев неправильное сочетание операционной системы и программ вызывает сбои в работе.
Поэтому я однажды собрал для него программную конфигурацию, и с тех пор он работает уже более 10 лет.
Стараюсь лишний раз его не выключать и не перезагружать, потому что он часто не загружается с первого раза. Даже аккумулятор к нему прикрутил на случай сбоев в электросети. Жалко его выбрасывать, ведь большую часть времени он работает исправно.

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

4. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +13 +/
Сообщение от Аноним (4), 17-Июн-26, 13:30 
> на языке Rust проблема приводила к аварийной остановке,

Звучит неприятно.

> в то время как в Си подобная ситуация привела бы к незаметному повреждению данных без остановки работы.

А это - катастрофически.
Особенно если повреждение данных можно использовать как RCE.

> в проведённых тестах ускорение составило от 3.3 до 32.5 раз при единичных операция декодирвоания и от 2.7 до 10.86 раз при декодировании непрерывного потока

Кто так из местных кyкapeкал что раст медленный?

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

7. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +11 +/
Сообщение от Аноним (6), 17-Июн-26, 13:38 
Значит, в оригинальном zlib этот алгоритм написан неоптимальным образом.
Ответить | Правка | Наверх | Cообщить модератору

9. Скрыто модератором  –4 +/
Сообщение от Аноним (9), 17-Июн-26, 13:39 
Ответить | Правка | Наверх | Cообщить модератору

23. Скрыто модератором  +/
Сообщение от Аноним (6), 17-Июн-26, 13:58 
Ответить | Правка | Наверх | Cообщить модератору

10. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –3 +/
Сообщение от Аноним (10), 17-Июн-26, 13:40 
> Значит, в оригинальном zlib этот алгоритм написан неоптимальным образом.

ваше высказывание ущемляет писателей кода на расте.

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

22. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –4 +/
Сообщение от q (ok), 17-Июн-26, 13:57 
То есть сишники кичились тем, что они не проверяют нуллы и прочие границы буферов, чтобы потом получить не только CVE, но и неоптимальный код? То есть утверждение о том, что "пусть иногда бывают CVE, зато скорость высокоскоростная" оказалось ложью?
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

28. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (6), 17-Июн-26, 14:01 
Это конкретно разработчики zlib накосячили с оптимальностью реализации алгоритмов.
Ответить | Правка | Наверх | Cообщить модератору

82. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от q (ok), 17-Июн-26, 15:08 
Разработчики zlib - не сишники?
Ответить | Правка | Наверх | Cообщить модератору

88. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (6), 17-Июн-26, 15:14 
Китайцы жители планеты Земля. Но не все жители пданеты Земля являются китайцами.
Ответить | Правка | Наверх | Cообщить модератору

89. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от q (ok), 17-Июн-26, 15:21 
То есть если провинился шотландец -- он уже всё, ненастоящий шотландец?
Ответить | Правка | Наверх | Cообщить модератору

107. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (6), 17-Июн-26, 16:01 
Вообще не согласуется с написанным мной.
Ответить | Правка | Наверх | Cообщить модератору

111. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от q (ok), 17-Июн-26, 16:18 
А твое с написанным мной согласуется? Ну например ты там писал, что "не все китайцы каратисты". Словно бы опровергая меня, якобы писавшего, что "ВСЕ сишники" чёто-там. Читай мои комменты внимательнее, прежде чем блистать логикой.

И кстати, блистая логикой в белом пальто, ты совершенно забыл ответить на ряд вопросов:

- Разработчики zlib - не сишники?
- если провинился шотландец -- он уже всё, ненастоящий шотландец?

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

91. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (91), 17-Июн-26, 15:25 
Ваша логика не работает. Если ткнуть в случайного человека, то они и японцем может оказаться. А вот сишников, кого не ткни, все как один неправильные, и не важно, что это за проект: xorg, linux, freebsd, nginx, quemu, openbsd или какой-то другой проект. Пока-что ни одного нормального проекта с сишниками до сих пор нет.
Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

94. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (94), 17-Июн-26, 15:32 
> Пока-что ни одного нормального проекта с сишниками до сих пор нет.

Добавлю к утверждению выше еще такой пикантный факт: GCC пишется на С++

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


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

90. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (94), 17-Июн-26, 15:23 
> Разработчики zlib - не сишники?

Не настоящие!
Вообще они выписаны из сищников на прошлой неделе.

Каждый знает что НАСТОЯЩИЙ СИШНИК пишет быстрый и корректный код, не делает use-after-free и не выходит за пределы буфера.

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

109. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (109), 17-Июн-26, 16:14 
>НАСТОЯЩИЙ СИШНИК пишет быстрый и корректный код, не делает use-after-free и не выходит за пределы буфера

И не существует в природе ... :)

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

340. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Проходил мимо (?), 19-Июн-26, 07:51 
Существует.
Точнее существует такой стиль программирования, - назовем его "параноидальным программированием", - при котором целенаправленно культивируется недоверие к входным данным и написанному коду, в том числе и своему собственному, и делается упор на качественную обработку ошибок. Вот когда начинаешь писать в таком стиле, то все так любимые Си-шниками ошибки куда-то внезапно исчезают, а программы работают надежно, как автомат Калашникова. Причем писать в таком стиле можно на любом языке программирования.
Ответить | Правка | Наверх | Cообщить модератору

345. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (91), 19-Июн-26, 09:09 
>Точнее существует такой стиль программирования, - назовем его "параноидальным программированием"

Не существует. В противном случае, сишные программы не кишили бы таким количеством уязвимостей.

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

100. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Совершенно другой аноним (?), 17-Июн-26, 15:49 
если сравнить исходные тексты zlib и zlib-ng, хотя-бы на примере реализации crc32, то можно
что в первой гораздо меньше ручных оптимизаций под процессоры, и в отличии от zlib-ng и zlib-rs нет оптимизации под sse2+ через всякие instrinsic-и. Думаю, аналогично и с другими вещами.
Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

11. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +8 +/
Сообщение от Аноним (11), 17-Июн-26, 13:41 
Говорит лишь о том, что оригинальный код можно ускорить в 1000 раз. Ну вон сравни infozip unzip и 7z -- второй раз в 10 быстрее zip распаковывает. Это типичная манипуляция, принятая в ржавом комьюнити -- написать код, который не делает то же самое, и утверждать, что стало быстрее теперь.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

19. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +2 +/
Сообщение от Аноним (19), 17-Июн-26, 13:53 
> Говорит лишь о том, что оригинальный код можно ускорить в 1000 раз.

А чего не в 10000? Или 10000000?

> Ну вон сравни infozip unzip и 7z -- второй раз в 10 быстрее zip распаковывает.

Вотэбоутизм в стиле "А вот у хох..."
Каким макаром связаны перечисленные с zlib?

> Это типичная манипуляция, принятая в ржавом комьюнити

Слово "типичный" намекает, что сейчас будут врать под видом обобщения))

> написать код, который не делает то же самое,

Хм, серьезное заявление.
А пруфы что zlib-rs не делает то же самое что zlib будут?
В Firefox он заменил старый - значит, что для лисы функционал одинаковый.

> и утверждать, что стало быстрее теперь.

Т.е "ваши тесты - не тесты" и ты можешь это опровергнуть?
Или просто по привычке газифицируешь лужу?

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

50. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (11), 17-Июн-26, 14:24 
Каким образом? И там и там deflate.
Ответить | Правка | Наверх | Cообщить модератору

57. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (57), 17-Июн-26, 14:29 
> опровергнуть?

а почему он должен, пока что видно только фанатские,  "это другое".

а тем временем, наскольже раст никому не нужен если проблему искали целый год?

насколько же мало этих разработчиков если ниукого не нашлось актуального интела под рукой

все это лишний раз указывает на очень активное меньшенство которое пытается перекричать большенство

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

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

110. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (109), 17-Июн-26, 16:18 
>проблему искали целый год

Потому что до раста сишка занималась вредительством втихаря .

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

32. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (32), 17-Июн-26, 14:05 
> Говорит лишь о том, что оригинальный код можно ускорить в 1000 раз.

Вот когда ускорят, тогда и поговорим.

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

58. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –3 +/
Сообщение от Аноним (11), 17-Июн-26, 14:35 
Осталось выяснить, зачем это делать. Deflate совершенно мёртв -- там, где он использовался, теперь brotli (который по совокупности параметров несколько лучше) и zstd (всем лучше). На подходе замена zstd для областей применения brotli (использующая несколько иной подход к кодированию, алгоритмы ускорять уже некуда).
Ответить | Правка | Наверх | Cообщить модератору

81. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (32), 17-Июн-26, 15:07 
PNG? не, не слышал.
Ответить | Правка | Наверх | Cообщить модератору

92. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (11), 17-Июн-26, 15:26 
> PNG? не, не слышал.

Именно. Махровое легаси с гигатоннами костылей.

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

99. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (32), 17-Июн-26, 15:48 
> Deflate совершенно мёртв
> там, где он использовался, теперь brotli

Legacy ≠ мёртвое.

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

104. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (11), 17-Июн-26, 15:52 
Это не legacy, это obsolete. Легаси это зип и как же он задрал своими 8-битными кодировками. А ведь, казалось бы, юникод в него 20 лет назад добавили. Deflate в нём меньшая из проблем.
Ответить | Правка | Наверх | Cообщить модератору

113. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (113), 17-Июн-26, 16:25 
>Deflate совершенно мёртв -- там, где он использовался, теперь brotli

Я понимаю, если бы ты еще ляпнул про LZMA2, но мертворожденный brotli, от которого даже сам родитель (гугел) шарахается...
Поделись, откуда такая "достоверная" статистика берется.

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

120. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (11), 17-Июн-26, 16:43 
Оттуда, что он везде и он заменил deflate. А вот zstd пока не везде.
Ответить | Правка | Наверх | Cообщить модератору

145. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 17-Июн-26, 17:37 
> Deflate совершенно мёртв

Ну да, все уже совершено выкинули ZIP и PNG.

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

147. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (11), 17-Июн-26, 17:44 
В zip уже zstd добавили лет 10 назад. Ну юникод тоже добавили 20 лет назад. Да, все выкинули zip и png, чем скорее, тем лучше.
Ответить | Правка | Наверх | Cообщить модератору

153. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (245), 17-Июн-26, 18:02 
> В zip уже zstd добавили лет 10 назад.

В ZIP много чего добавили, но используется он везде именно с deflate.

> Да, все выкинули zip и png

Абсолютно нелепый копиум. Это буквально самый распространенный в мире формат архивов и самый распространенный в мире формат для lossless-изображений.

> чем скорее, тем лучше.

Так "выкинули" или "скорее бы уже"?

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

159. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (11), 17-Июн-26, 18:19 
Ты ошибаешься про "самый распространённый". Хроническая неспособность работать с юникодом и полная невозможность использования для обмена информацией между 2 устройствами сделали его изгоем. А пнг слишком нишевый, настолько, что 30 лет спустя только фотошоп умеет в него кодировать нормально (и в том числе с палитрами). Такой вот опенсорс.
Ответить | Правка | Наверх | Cообщить модератору

170. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 17-Июн-26, 19:22 
> Ты ошибаешься про "самый распространённый".

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

Абсолютный детсад.

>> самый распространенный в мире формат для lossless-изображений.
> А пнг слишком нишевый

То же самое. Якобы "нишевый", но о "не нишевом" lossless формате ты тактично умолчал, зато приплел какой-то словесный понос про "нормальность кодирования" и "опенсорс".

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

173. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –3 +/
Сообщение от Аноним (11), 17-Июн-26, 19:47 
Адекватный человек не порол бы чушь сейчас на твоём месте. Рар и 7з не имеют проблем с передачей между устройствами и наиболее популярны для обмена файлами. Тар тоже и он наиболее полноценный вариант, сохраняющий все атрибуты на линуксах. Что до графики, это либо нормальный лосслесс как PSD (неспособность опенсорса с ним работать только его проблема, у проприетарных программ нормальная совместимость из того, что я видел) и его деривативы, либо tiff и его деривативы. Проблема PNG в том, что этот формат не содержит исходных данных. Это формат без потерь, но без потерь в него не кодируют -- это фактически невозможно сделать на практике.
Ответить | Правка | Наверх | Cообщить модератору

186. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 17-Июн-26, 21:08 
>> название самого распространенного формата архива в качестве контраргумента
> Рар, 7з, Тар

Rar, 7z и TAR - это, по-твоему, самые распространенные форматы архивов?

>> самый распространенный в мире формат для lossless-изображений.
> PSD

Абсолютная дурка. PSD вообще не формат изображения, а специфичный контейнер Фотошопа. Если считаешь иначе - удаче тебе прткрутить его на веб-страницу, вставить в PDF или перезнтацию, да и просто открыть в твоем просмотрщике изображений.

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

193. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (193), 17-Июн-26, 21:22 
>>> Ты ошибаешься про "самый распространённый".
>> ...дальше бы адекватный человек привел бы название самого распространенного формата архива в качестве контраргумента, но ты тактично это не сделал и продолжаешь напевать о "невозможностях" и "неспособностях".
> Рар и 7з не имеют проблем с передачей между устройствами и наиболее популярны для обмена файлами. Тар тоже и он наиболее полноценный вариант, сохраняющий все атрибуты

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

Я извиняюсь, но вы вообще читаете то, на что отвечаете, или у вас СДВГ?

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

199. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (11), 17-Июн-26, 21:34 
Как можно ответить на тупейший вопрос в стиле местного инвалида-дцпшника? Смотря где. Для обмена файлами, я так прикину 40% файлов в рар, примерно 30% в 7з, остальное зип и тар. Если считать производные и технические файлы без юникода, не для обмена, зип вполне окажется самым распространённым.
Ответить | Правка | Наверх | Cообщить модератору

202. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (202), 17-Июн-26, 21:44 
> Как можно ответить на тупейший вопрос в стиле местного инвалида-дцпшника?

В чем тупость вопроса "какой формат архивов самый распространенный"? Причем обсолютно логичного после того, как вы заявили, что это якобы не ZIP.

> Смотря где.

Написано же было "в мире" (цитата) "Это буквально самый распространенный в мире формат архивов". Я вам еще раз повторяю: читайте то, на что отвечаете.

> Для обмена файлами, я так прикину 40% файлов в рар, примерно 30% в 7з

Ах, вы "прикинете"... А вот в рельном мире все ОС поддерживают из коробки именно ZIP, а не проприетарный закрытый RAR. И потому именно ZIP является самым распространенным.

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

205. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (11), 17-Июн-26, 21:52 
Я повторюсь. Если ты не понял, зип -- невозможно использовать для обмена файлами. То, что в "все ОС" из коробки -- неюзабельный огрызок с проблемами, не работающий с файлами нормально и _все_ всё равно ставят 7зип или винрар для работы с зип. Проприетарность и закрытость абсолютно нерелевантный фактор для 99% людей и не основной для 99.999% людей. Теперь понятно?
Ответить | Правка | К родителю #202 | Наверх | Cообщить модератору

210. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (210), 17-Июн-26, 22:16 
> Если ты не понял, зип -- невозможно использовать для обмена файлами.

И плевать, что люди это делали десятками лет - и до сих пор продолжают делать.

>> ОС поддерживают из коробки
> Проприетарность и закрытость абсолютно нерелевантный фактор

Зато он релевантный для той самой "поддержки в ОС из коробки", а как следствие - и распространности.

Вот сейчас я стану по работе коллегам на их макбуки слать RAR. Догадываетесь, какая будет реакция?

> Теперь понятно?

Понятно, что вы живете в каком-то информационном пузыре, где ZIP умер, а RAR - самый популярный формат.

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

212. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (11), 17-Июн-26, 22:30 
У каждого свой пузырь. У меня пузырь люди со всего мира и китайцев с зип только могила исправит, у тебя, видимо, пузырь -- люди с работы с 1 (твоей) локалью. Нормальная будет реакция, сразу узнаешь, кто из коллег инвалид.
Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

213. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (213), 17-Июн-26, 22:44 
> У каждого свой пузырь. У меня пузырь люди со всего мира

Ну так я и говорю: люди в вашем "всем мире" используют RAR.

> китайцев с зип только могила исправит, у тебя, видимо, пузырь -- люди с работы с 1 (твоей) локалью

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

>> Вот сейчас я стану по работе коллегам на их макбуки слать RAR. Догадываетесь, какая будет реакция?
> Нормальная будет реакция

Нет, нормальной она точно не будет.

> сразу узнаешь, кто из коллег инвалид.

В такой ситуации инвалидом буду выглядеть только я сам.

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

215. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (11), 17-Июн-26, 22:50 
Ну да, примерно 2 из 3 файлов в рар, если это зип -- есть хороший шанс, что извлечь вообще никак не получится. Или придётся выставлять кодировку gbk и может быть извлечётся. Или другую gb. У корейцев свои кодировки. Удачи угадать, в какой стороне автор архива, это для начала.
Ответить | Правка | К родителю #213 | Наверх | Cообщить модератору

154. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от ProfessorNavigator (ok), 17-Июн-26, 18:06 
> Да, все выкинули zip

Какой прыткий вьюноша..

https://en.wikipedia.org/wiki/OpenDocument
https://en.wikipedia.org/wiki/Office_Open_XML

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

158. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (11), 17-Июн-26, 18:14 
Собственно, я и говорю, что это легаси и технический долг. Те, кто это придумал, были умными и дальновидными.
Ответить | Правка | Наверх | Cообщить модератору

163. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от ProfessorNavigator (ok), 17-Июн-26, 18:26 
> Собственно, я и говорю, что это легаси и технический долг. Те, кто
> это придумал, были умными и дальновидными.

Легаси-не легаси, но и то и другое с нами, я так подозреваю, останется надолго. И то, и другое - zip-архивы.


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

174. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (174), 17-Июн-26, 19:48 
JAR — zip-архив.
APK — zip-архив.
IPA — zip-архив.
Вот просто что сразу в голову пришло.
Ответить | Правка | Наверх | Cообщить модератору

178. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (178), 17-Июн-26, 20:06 
По его логике это все тоже автоматически записывается в легаси. 👍
Ответить | Правка | Наверх | Cообщить модератору

250. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Покулансипокус (?), 18-Июн-26, 02:32 
На си можно написать код не медленнее любого другого языка, только надо больше для этого потрудиться, чем на расте.
Раст изначально настроен на максимальную автоматическую оптимизацию и с его моделью компилятору легче определить что и как можно оптимизировать. Си более гибкий и для оптимизатора могут в нём возникать неопределенные моменты, когда он точно не знает приведет ли определенная оптимизация к ошибке или нет.
Также раст например по-умолчанию оптимизирует расположение полей в структуре и тем самым больше структур может поместиться в кеш, что может сильно ускорить производительность.
Си не оптимизирует структуры -- эта оптимизация возложена на программиста. Но как я заметил не все программисты даже об этом знают.

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

А конкретно по данной новости, они при переписывании на раст могли ещё лучше оптимизировать. Если туже работу на си сделать, то тоже скорость увеличится. Только вопрос, почему за столько лет не сделали ?

Это не манипуляция была, это новость -- стало же быстрее, об этом и сообщили.
Фанаты си пусть сделают быстрее на си и тоже сообщат об этом
А так в данной библиотеке пока лидирует раст, если нет там потери нужного функционала.
А конечному пользователю наверно всё-равно на каком языке написано, но ему будет не всё-равно, если одна из версий будет существенно быстрее. Скорее всего он её и выберет

Таким образом, если программисты си не напрягутся, то раст перетянет одеяло на себя.
И без разницы всем будет манипуляция там или нет. Если на расте быстрее будет, то значит на нём лучше. Плюс вон явно вылетело по ошибке, а не испортило данные, как могло бы быть на си.
Программисты на си могут и тут с растом тягаться, но им надо напрячься посильнее и лучше контролировать свой код. В расте же данный вид ошибок программисты могут возложить на компилятор и заняться более лучшим контролем логики.

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

265. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (11), 18-Июн-26, 12:16 
Формально, ты неправ. Например, чтение из файла всегда будет медленнее и менее эффективно в си, чем чтение файла в си++. Я так и не смог придумать, каким образом их уровнять, libc точно позволяет меньше libc++. Ты скажешь, не всем в программе необходима операция чтения файла и вообще это нишевое применение. Возможно. Но всем необходимы операции сложения матриц и тут тоже быстрее фортрана сделать тяжело. В любом случае, быть быстрее си это не то чтобы достижение. Под ручной оптимизацией ты, видимо, подразумеваешь задействование SIMD, но это не ручная оптимизация, это просто ассемблерные вставки. А со всем остальным справляется неплохо PGO. Компилятор не очень умный, на самом деле, хотя за 20 лет значительный прогресс нарисовался. Это видно, когда открываешь для себя профилировщик -- компилятор постоянно надо направлять, без этого программы у тебя получатся кривые и неэффективные. Что касается раста, то он принципиально не может быть более эффективным из-за накладных расходов в рантайме, да и твои любимые структуры более раздуты и хуже контролируются -- как итог, процессор используется менее эффективно. Память тоже.
Ответить | Правка | Наверх | Cообщить модератору

18. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (18), 17-Июн-26, 13:52 
А если переписать на Си будет еще быстрее.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

21. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (21), 17-Июн-26, 13:57 
А на чем по твоему написана zlib? (www.zlib.net)

Спойлер: C 74.0%

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

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

56. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (11), 17-Июн-26, 14:28 
Начни с того, что такое zlib? Продолжи тем, что такое png. Это васянское позорище, по недоразумению получившее распространение. Устаревшее в момент появления, 30 лет назад.
Ответить | Правка | Наверх | Cообщить модератору

122. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (117), 17-Июн-26, 16:43 
Я тоже так считаю.

Всегда пользовался gif.  И размер меньше, и анимацию можно добавить.

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

146. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 17-Июн-26, 17:40 
> Продолжи тем, что такое png. Это васянское позорище, по недоразумению получившее распространение. Устаревшее в момент появления, 30 лет назад.

А что вместо него? Особенно 30 лет назад.

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

156. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (11), 17-Июн-26, 18:09 
Tiff до сих пор актуален и лишён недостатков png.
Ответить | Правка | Наверх | Cообщить модератору

175. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (245), 17-Июн-26, 19:52 
> Tiff до сих пор актуален и лишён недостатков png.

АХАХА! Только истинный эксперт может петь про кривое старое легаси - и в качестве контрпримера приводить буквально древнего монстра франкенштейна, целиком и полностью склееного из кучи расширений. 🤣 Да, TIGF настолько актуален, что уже давно заменил PNG и на вебсайтах!

И ЧСХ, опция сжатия "ZIP" в диалоге сохранения TIFF Фотошопа (или "Deflate" в GIMP) тебе не о чем не говорит.

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

177. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (11), 17-Июн-26, 20:02 
Веб не имеет никакой мотивации использовать лосслесс где-либо, webp успешно занял нишу лосслесса в вебе. То, что tiff паршивый комбайн, всё ещё не мешает использовать его как intermediate формат без потерь в большинстве случаев.
Ответить | Правка | Наверх | Cообщить модератору

180. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +2 +/
Сообщение от Аноним (245), 17-Июн-26, 20:20 
> Веб не имеет никакой мотивации использовать лосслесс где-либо

Ты в курсе, что значит буква N в PNG?

Конечно имеет мотивацию, ведь простая графика типа иконок и простых иллюстраций (не фото) в lossless может получится даже меньше размером, чем lossy - и при этом, главное, не содержит никаких артефактов сжатия.

Ты уверенно продолжаешь пробивать дно, хотя за язык тебя никто не тянет.

> webp успешно занял нишу лосслесса

Так WEBP или TIFF? Ты там определись уже.

> То, что tiff паршивый комбайн, всё ещё не мешает использовать его как intermediate формат без потерь

В каких конкретно случаях TIFF используется ВМЕСТО PNG как intermediate формат?

> не мешает использовать его как intermediate формат без потерь в большинстве случаев

Ок, а в каких случаях мешает?

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

185. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –2 +/
Сообщение от Аноним (11), 17-Июн-26, 20:33 
Дно толкьо у тебя в голове. Png вовсе не lossless. Png это rgb и grayscale. А исходники либо lab/luv, либо cmyk.

>простая графика типа иконок и простых иллюстраций

Только палетированный png, его может сгенерировать только фотошоп. Это совсем не те же пнг, что видят большинство людей. Если в jpegxl этот вопрос будет решён, про пнг и фотошоп можно забыть.

>в каких случаях мешает

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

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

187. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 17-Июн-26, 21:14 
> Png вовсе не lossless. Png это rgb и grayscale. А исходники либо lab/luv, либо cmyk.

Холи мазер оф гад. 🤦 Да тут целое бинго!

> палетированный png, его может сгенерировать только фотошоп.

Вот это новости! Как же я ве эти годы делал это в Гимпе?

> Это совсем не те же пнг, что видят большинство людей

Шта?

> Если в jpegxl этот вопрос будет решён

Вот когда будет решен, тогда и будешь петь про смерт PNG.

>>> То, что tiff паршивый комбайн, всё ещё не мешает использовать его как intermediate формат без потерь в большинстве случаев.
>>в каких случаях мешает?
> дилетанты занимаются профессиональной обработкой и думают, что png без потерь.

Ты не ответил на вопрос.


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

179. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (178), 17-Июн-26, 20:08 
> Tiff до сих пор актуален и лишён недостатков png.

О каких конкретно недостатках PNG, отсутствующих в TIFF, идет речь?

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

103. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (18), 17-Июн-26, 15:52 
Нет, ты не понял. Открою тебе тайну, но код можно переписать не меняя язык.
Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

33. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 17-Июн-26, 14:05 
> А это - катастрофически.

Реально, катастрофа: растоманы не умеют понимать прочитанный текст на родном языке.

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

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

67. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (67), 17-Июн-26, 14:46 
Всегда удивляло что обычную рекламу айтишники научились фильтровать, но любую айтишную рекламу принимают на веру.

> в то время как в Си подобная ситуация привела бы к незаметному повреждению данных без остановки работы

Смотря как написать...и также можно и на раст)

> в проведённых тестах ускорение составило от 3.3 до 32.5 раз при единичных операция декодирвоания и от 2.7 до 10.86 раз при декодировании непрерывного потока

Любой разработчик знает что любую нетривиальную программу можно представить быстрее если преподнести её в выгодном свете. Берём греп, существенно переписываем алгоритм, добавляем агрессивные оптимизации, убираем часть функциональности и вуа-ля! Убийца грепа готов. Меняем язык и говорим что все благодаря languagename. Берём zlib-ng, переписываем на другом абсолютно любом языке с возможностью дотянуться до асма, собираем под процессор получаем кратный прирост производительности по сравнению с zlib...

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

95. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (91), 17-Июн-26, 15:43 
>Всегда удивляло что обычную рекламу айтишники научились фильтровать, но любую айтишную рекламу принимают на веру.

Всегда удивляло количество мракобесов среди айтишников.

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

132. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (132), 17-Июн-26, 17:01 
А чего вы удивляетесь? Это прямой результат установки "гуманитарные науки не нужны".
Ответить | Правка | Наверх | Cообщить модератору

171. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (91), 17-Июн-26, 19:35 
Допустим. Какая именно гуманитарная наука поможет, с учётом того, что аргументы, приводимые за или против лежат в технической плоскости?
Ответить | Правка | Наверх | Cообщить модератору

127. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (127), 17-Июн-26, 16:49 
> Кто так из местных кyкapeкал что раст медленный?

а что, у вас там раст исполняется в цпу? сравнивать надо кодогенерацию ллвм с гцц, проснись уже 21 век!

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

131. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Фамилия (?), 17-Июн-26, 16:57 
> > на языке Rust проблема приводила к аварийной остановке,
> Звучит неприятно.
> > в то время как в Си подобная ситуация привела бы к незаметному повреждению данных без остановки работы.
> А это - катастрофически.
> Особенно если повреждение данных можно использовать как RCE.

Поясните, плиз, что это значит. Я читаю это как "благодаря расту оно падает и не даёт злоумышленнику украсть ваши биткоины". Но я не понимаю - как раст нивелирует ошибку в процессоре?

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

341. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Проходил мимо (?), 19-Июн-26, 08:02 
Rust не нивелирует ошибку в процессоре, Rust не дает ошибке в процессоре превратить ваши ценные данные в сено, пропущенное через корову.
Ответить | Правка | Наверх | Cообщить модератору

349. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Фамилия (?), 19-Июн-26, 15:13 
А как он это сделал? Ну вот как, объясните, плиз. Расту доступны только инструкции процессора. Инструкция процессора сбойнула и сделала что-то непредвиденное. Что раст с этим может сделать? Раст попросил процессор сложить два числа, а он сделал вычитание. А следом идёт инструкция обращения к памяти. Раст, когда компилировал код, всё просчитал и заверил программиста, что после сложения можно обратиться к памяти - и это будет безопасно.

Но процессор сделал не сложение, а вычитание. А инструкция обращения к памяти никуда ведь не делась из exe'шника. Она всё так же выполнится и либо будет сегфолт, либо молчаливое продолжение работы. Зависит от того, что и как разложилось по памяти.

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

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

369. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от anonymous (??), 19-Июн-26, 19:34 
>> в то время как в Си подобная ситуация привела бы к незаметному повреждению данных без остановки работы.
>А это - катастрофически.

А в оригинальном zlib ошибка подтверждена или это домыслы растоманов? Что-то я не видел отчетов в zlib по этому поводу. Наверное, потому что референс не подвержен надуманным проблемам ошибок в процессорах?

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

5. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (5), 17-Июн-26, 13:30 
> Ошибка устранена обходным путём в кодовой базе Firefox и zlib-rs.

Это конечно прекрасно, а что же с остальными кодом, который выдает генератор кода LLVM? Предлагается надеяться на удачу или кто-то исправит интеловский микрокод?

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

8. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +2 +/
Сообщение от Аноним (10), 17-Июн-26, 13:38 
>Предлагается надеяться на удачу или кто-то исправит интеловский микрокод?

адм купи, там не нужно исправление.

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

46. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –2 +/
Сообщение от Аноним (365), 17-Июн-26, 14:15 
>адм купи

Там другого хватает, почитайте:
https://www.opennet.ru/keywords/amd.html

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

38. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +6 +/
Сообщение от Ivan_83 (ok), 17-Июн-26, 14:08 
Если бы вы читали рассылки gcc и llvm или ERRATA по процам то знали бы что там таких багов в процах просто вагонами.
Я когда то лично наступал на:
- жутко медленную работу отдельных инстриктов на отельных арихитектурах
- libasn1 скомпиленное clang -O2+ падало на парсинге сертификатов
- вроде что то ещё было с llvm, уже забыл, помню что пару багов там открывал всего
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

114. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –3 +/
Сообщение от Аноним (114), 17-Июн-26, 16:33 
бсдишники со своим шлангом должны страдать.
Ответить | Правка | Наверх | Cообщить модератору

142. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 17-Июн-26, 17:22 
Так фря собирается и gcc, в чём страдание то?
Или вы думаете что на других ОС llvm будет генерировать более правильный код?
Ответить | Правка | Наверх | Cообщить модератору

69. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (91), 17-Июн-26, 14:46 
Вместо LLVM может быть любой компилятор https://habr.com/ru/articles/332552/
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

157. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (157), 17-Июн-26, 18:13 
Поскольку есть N-ное число пользователей, у которых при слове "обновления" происходит тряска (а обновлённый микрокод попадает на пользователям либо с обновлениями ОС/соответствующего пакета, либо с обновлением прошивки (которую обновляет ещё меньшее число пользователей), обходные пути придётся реализовывать разработчикам софта.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

13. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от mikhailnov (ok), 17-Июн-26, 13:43 
Закостылили в zlib-rs через insafe, забавно :)
Ответить | Правка | Наверх | Cообщить модератору

16. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (365), 17-Июн-26, 13:49 
>Первое проявление проблемы было замечено в процессе тестирования ранних сборок более года назад, но на системах разработчиков её не удавалось воспроизвести.

Интересно:
https://data.firefox.com/dashboard/hardware

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

27. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +4 +/
Сообщение от cheburnator9000 (ok), 17-Июн-26, 13:59 
>> Display Resolution

1920x1080 = 50%
3840x2160 = 2%

Адептусам-фанатикам "4K сейчас стандарт" посвящается.

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

34. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (3), 17-Июн-26, 14:06 
По удобству стандарт это 2K.
Ответить | Правка | Наверх | Cообщить модератору

37. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (37), 17-Июн-26, 14:07 
Стандарт для чего?
Для офисных рабов которым железо обновляли лет 15 назад?
Ну так им будут fullHD покупать еще 20 лет.
Как и двухядерные селероны.

Ибо "сэкономил значит заработал".

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

43. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +2 +/
Сообщение от НяшМяш (ok), 17-Июн-26, 14:12 
2К на 27 дюймов это оптимальное разрешение для игр и работы, если не сидеть в 20см от экрана, плюс масштабирование интерфейса можно оставить 100%. Для чисто текста 4К предпочтительнее конечно же.
Ответить | Правка | Наверх | Cообщить модератору

123. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (123), 17-Июн-26, 16:44 
> Для чисто текста 4К предпочтительнее конечно же.

У вас что-то со шрифтами или библиотекой рендера не так, если они на 1920x1080 вас не устраивают. У меня даже на 1366x768 шрифты фритайпа были чёткие, с антиалиасингом и не расплывались по всему монитору блюмом (под иксами, хз что за костыли нужны под вейландом чтобы субпикселку правильно ренлерить).

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

274. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (91), 18-Июн-26, 12:54 
При большом размере влезет больше текста.
Ответить | Правка | Наверх | Cообщить модератору

59. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (59), 17-Июн-26, 14:37 
> 1920x1080 = 50%
> 3840x2160 = 2%

Так это данные лисы.
У них 5.17% пользователей это Windows 7. Семерка, Карл!
data.firefox.com/dashboard/hardware

> Адептусам-фанатикам "4K сейчас стандарт" посвящается.

Давай посмотрим не на офисный планктон из бухгалтерии, а например на стим.
1920 x 1080 - 51.89% совпадает.
2560 x 1440 - 21.20%
3440 x 1440 - 3.18%
3840 x 2160 - 5.00% - т.е среди любителей поиграть 4к в 2.5 раза популярнее.

В любом случае если у тебя 50% юзеров имеют разрешение больше чем фуллХД, то это не то что стоит игнорировать.
(И это без учета платежеспособности)))

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

119. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (32), 17-Июн-26, 16:43 
Да там ещё 1440×900 и 1366×768 в заметных количествах, что уж тут говорить.
Ответить | Правка | Наверх | Cообщить модератору

129. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (129), 17-Июн-26, 16:53 
> Да там ещё 1440×900 и 1366×768 в заметных количествах, что уж тут говорить.

Ну так сколько было нетбуков на 1366×768?
Или ноутов времен царя гороха...

Просто лиса это предпоследние убежище для некролюбов.
Дальше только всякие паленки, либрвульфы и уже на дне диллою

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

253. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ю.Т. (?), 18-Июн-26, 07:32 
1366 - это не только нетбуки, но и дешевые телевизоры, применяемые как мониторы.
Ответить | Правка | Наверх | Cообщить модератору

194. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от фняк. (?), 17-Июн-26, 21:24 
Так а чем на семёрке то пользоваться кроме фокса?

Windows 7
Chrome 109 is the last version to support this operating system.
Chrome 109 was released January 10, 2023

пу-пу-пу

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

347. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Pepenezemail (ok), 19-Июн-26, 11:41 
Supermium. Он уже 144.
Ответить | Правка | Наверх | Cообщить модератору

371. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от ferris (?), 20-Июн-26, 02:04 
Использовать VxKex для запуска почти любой современной программы на win7.
Ответить | Правка | К родителю #194 | Наверх | Cообщить модератору

220. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (220), 17-Июн-26, 23:46 
4К ещё ладно, как жить с мыслью что стандарт -- это последний хром на одиннадцатой винде?
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

17. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +3 +/
Сообщение от Аноним (17), 17-Июн-26, 13:50 
Я знал, что моя кора дуба самый лучший процессор. Буду дальше на нем сидеть.
Ответить | Правка | Наверх | Cообщить модератору

125. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (117), 17-Июн-26, 16:46 
Самый лучший процессор это Pentium III Tualatin, но в принципе, Pentium D Prescott тоже хорош.
Ответить | Правка | Наверх | Cообщить модератору

136. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (132), 17-Июн-26, 17:05 
Так толсто, что аж горячо
Ответить | Правка | Наверх | Cообщить модератору

133. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от King_Carloemail (ok), 17-Июн-26, 17:01 
> Я знал, что моя кора дуба самый лучший процессор. Буду дальше на
> нем сидеть.

Вот тут вы жестоко ошибаетесь. Кора дуба дырявый основоположник дырявости всех последующих процов интел. Выкиньте его немедленно, у вас хакер завёлся!
https://xakep.ru/2007/06/29/39040/

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

24. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +2 +/
Сообщение от Аноним (245), 17-Июн-26, 13:58 
> о переходе Firefox на использование библиотеки zlib-rs

Это что же делается, люди добрые! Сперва Chrome заменил сишные Freetype и libxml растовыми аналогами, а теперь вот еще и Firefox сишный zlib заменила растовым. Такими темпами скоро все фундаментальные сишные либы заменят на проклятый раст. 😭

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

53. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –2 +/
Сообщение от Аноним (53), 17-Июн-26, 14:27 
всё должно работать медленно, а то ты не станешь покупать новый проц и память за 10-ти кратную цену
Ответить | Правка | Наверх | Cообщить модератору

181. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +5 +/
Сообщение от Аноним (245), 17-Июн-26, 20:22 
> всё должно работать медленно, а то ты не станешь покупать новый проц и память

Но ведь в новости написано:

"переход с zlib на zlib-rs привёл к заметному повышению производительности"

Выходит, Раст экономит мне денежку?

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

254. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ю.Т. (?), 18-Июн-26, 07:33 
Ну ясно же. Сейчас у тебя станут появляться лишние циклы процессора. Сдавать будешь! Богатеть!
Ответить | Правка | Наверх | Cообщить модератору

25. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (25), 17-Июн-26, 13:59 
> на CPU Raptor Lake вместо 8-15 битов из RCX, соответствующих регистру CH, в память записывались биты 0-7, соответствующие регистру CL.

выходит, до сих пор никакой код не записывал в память регистр CH, и потому не получал ошибок на этих процессорах?

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

128. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (123), 17-Июн-26, 16:50 
Мб потому что все записывали такое по маске с нулями в младших байтах в RCX/ECX, а не в отдельный для этого регистр. Вот вам и закрытый микрокод.
Ответить | Правка | Наверх | Cообщить модератору

35. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +2 +/
Сообщение от Аноним (35), 17-Июн-26, 14:06 
Не понятно с чего бы C Незаметно бы повредил данные,а Rust упал. Если тут идёт работа с данными, результат работы записывается куда-то. Ну записались не те данные и всё. С чего бы раст это отдетектил.
Ответить | Правка | Наверх | Cообщить модератору

41. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –4 +/
Сообщение от Ivan_83 (ok), 17-Июн-26, 14:10 
Это домыслы евангелистов, надо же хоть какую то пользу придумать для оправдания этого монстра.
Ответить | Правка | Наверх | Cообщить модератору

44. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +2 +/
Сообщение от НяшМяш (ok), 17-Июн-26, 14:15 
Для гениев в патче есть развёрнутый комментарий, почему так происходит.

https://github.com/trifectatechfoundation/zlib-rs/pull/520/f...

Хотя я опять забыл что мы на пoпeннeтe, тут одни кeкспeрты-oнaнимуcы, любители корыдуба и дыpяшки.

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

47. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –2 +/
Сообщение от Ivan_83 (ok), 17-Июн-26, 14:19 
Код не читабельный.
А такой паттерн много где может быть, хотя те кто уже наступал на грабли с выравниванием пишут в таких случаях по одному байту или используют memcpy().
Ответить | Правка | Наверх | Cообщить модератору

51. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 17-Июн-26, 14:24 
> Код не читабельный

С чего бы растовый выглядел читабельным для человека, который за всю жизнь осилил только C и Lua?

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

138. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –3 +/
Сообщение от Ivan_83 (ok), 17-Июн-26, 17:15 
пхп, джава/джаваскрип, питон, шеллскрипт, перл, бейсик, асм и даже паскаль - всё относительно читабельное, но не это.
Ответить | Правка | Наверх | Cообщить модератору

155. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (245), 17-Июн-26, 18:08 
> джава/джаваскрип

Классика жанра. 😂

> перл, [..] асм
> относительно читабельно

Тут уже совсем какой-то нелепый троллинг.

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

172. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (91), 17-Июн-26, 19:45 
>пхп, джава/джаваскрип, питон, шеллскрипт, перл, бейсик, асм и даже паскаль

Ыкспертиза как всегда на высоте. Вас кто за язык дёргал, когда вы про перл писали? Забыли про "программу из одной строчки на perl"? Или вы, как и полагается растохейтеру, даже на си программировать не умеете?
>Код не читабельный.

Покажите строку и ткните пальцем в том место, где она не читаемая.

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

182. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (245), 17-Июн-26, 20:26 
> Или вы, как и полагается растохейтеру, даже на си программировать не умеете?

Чел, он буквально "java/javascript" через слеш пишет. Т.е. для него это примерно одинаковые языки, которые он знает не сильнее девочек-HR, которые точно так же пишут в вакансиях по еайму.

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

218. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 17-Июн-26, 23:32 
Скажу вам больше: я их не знаю и знать не хочу!
Однако я сдал экзамен (и все лабы что полагались для допуска) в местном универе в 2023 году по java, и у меня собственный плагин к ruTorrent на java script + php.

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

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

223. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (245), 17-Июн-26, 23:54 
> Скажу вам больше: я их не знаю и знать не хочу!

Это было и так очевидно.

> Те не знание языков не мешает мне на них читать и писать код

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

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

292. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 16:30 
Уху, ведь надо быть экспердом по прыжкам с мостов чтобы авторитетно заявлять что этого делать нинада.
Ответить | Правка | Наверх | Cообщить модератору

303. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 18-Июн-26, 20:58 
> Уху, ведь надо быть экспердом по прыжкам с мостов чтобы авторитетно заявлять что этого делать нинада.

Мы обсуждаем не прыжки с мостов, а языки программирования.

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

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

319. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 22:40 
Я не хочу пробовать г-но на вкус, чтобы быть экспертом в его вкусах и советовать другим не принимать внутрь.
Ваше г-но я уже видел, употреблять его меня ни капли не тянет.

Учтите что я не обсуждаю вкусы, консистенцию и прочие характеристики, мне из далека всё понятно.

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

332. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 19-Июн-26, 02:29 
>> Мы обсуждаем не прыжки с мостов
> Я не хочу пробовать г-но на вкус

Я тебе еще раз повторяю: обсуждаются языки программирования, а не прыжки с моста и пробование г-на на вкус. Чел, повзрослей уже.

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

355. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Ivan_83 (ok), 19-Июн-26, 15:52 
А что мне с языков?
Я вам изначально написал: проблема которую решат раст - не интересна. Синтаксис сложный, стандартная либа и базовый набор - огромный.
Это всё прекрасно оценивается без знания языка и траты времени на его изучение.

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

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

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

264. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Володька Драйвер (?), 18-Июн-26, 12:09 
Утверждать, что знаешь язык потому, что сдал лабы в универе - это очень кринж. В 2023 году =)
Ответить | Правка | К родителю #218 | Наверх | Cообщить модератору

293. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 16:30 
Ты бы хоть перечитал прежде чем писать :)
Ответить | Правка | Наверх | Cообщить модератору

367. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от freecoderemail (ok), 19-Июн-26, 17:52 
Зато честно. Похоже это типичный портрет растохейтера.
Ответить | Правка | К родителю #264 | Наверх | Cообщить модератору

370. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 19-Июн-26, 21:16 
Да мне до раста фиолетово (пусть бы загибался где то на задворках), если бы фонаты его не тащили в другие проекты где его никогда не было.
Ответить | Правка | Наверх | Cообщить модератору

314. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (91), 18-Июн-26, 21:49 
>Плагин можете сами на гитхубе найти и оценить какчество кода.

Если вы так хотите похвастаться, то скиньте ссылку.
>Скажу вам больше: я их не знаю и знать не хочу!
>Однако я сдал экзамен (и все лабы что полагались для допуска) в местном универе в 2023

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

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

320. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 22:43 
https://github.com/rozhuk-im/rutorrent-hostname

Лабы сданы, вопросы отвечены - что ещё надо?
Я сдал и забыл и снёс OpenJDK из системы, тк знание для меня не востребованное: ничего нового я на этом писать не собираюсь, и из имеющегося очень редко приходится копатся.

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

327. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (91), 19-Июн-26, 00:18 
>и оценить какчество кода.

Разочаровывающее.
https://github.com/rozhuk-im/rutorrent-hostname/blob/120e1d5...
https://github.com/rozhuk-im/rutorrent-hostname/blob/120e1d5...
json изобретён
https://github.com/rozhuk-im/rutorrent-hostname/blob/120e1d5...
Структуры изобретены
https://github.com/rozhuk-im/rutorrent-hostname/blob/120e1d5...
Если вы уж преобразовываете к строке, то преобразовывайте в момент присваивания. Хотя что мешает вам сравнивать даты - непонятно
https://github.com/rozhuk-im/rutorrent-hostname/blob/120e1d5...
Велосипед, используйте стандартную библиотеку

Дальше анализировать лень.
>Лабы сданы, вопросы отвечены - что ещё надо?

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

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

352. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 19-Июн-26, 15:46 
JSON там и нафик не упал ради такого.
Дело не в структурах а в компактном размещении в памяти, хотя может для этой задачи и не актуально.
Насчёт сравнения возможно вы и правы.
Хз что именно вы предлагаете из стандартной библиотеки.

Претензия к обучению - это вообще не ко мне.
Задача вуза в данном случае дать обзорные знания и базовые навыки, а не 30+ лет опыта и глубокую экспертизу в отрасли. Там так то и другие предметы есть, которые тоже изучать и сдавать надо.

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

374. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (91), 20-Июн-26, 03:46 
>JSON там и нафик не упал ради такого.

JSON нужен для того, чтобы не было велосипедов.
>Дело не в структурах а в компактном размещении в памяти

Чего именно вы пытаетесь добиться? Или опять идея фикс?
>Хз что именно вы предлагаете из стандартной библиотеки.

Ну так для этого язык надо хоть минимально знать.
>Задача вуза в данном случае дать обзорные знания и базовые навыки

Задача вуза - повесить на вас студенческий кредит, и дать подставку под горячее, от которой фанатеют вахтёры.
>а не 30+ лет опыта

30+ лет кнопкодавства, где каждый день похож на другой?
>и глубокую экспертизу в отрасли

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

Конечно, как я мог забыть! Хороший программист обязан иметь литературный вкус и быть в состоянии обсудить хоть античных философов, хоть английских классиков, хоть постмодернистских современников. Желательно ещё ему иметь поставленный голос, и чёрный пояс по баскетболу. Ну а собственно программировать уметь ему не обязательно, не по профессии же он будет работать.

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

376. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 20-Июн-26, 22:11 
JSON в данном случае не эффективное решение: нужно всего то передать имя хоста и его IP адрес, для этого достаточно склеить их в одну строку и добавить разделитель.

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

Раз предложения хороших нет - оставлю код пока таким как есть :)

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

219. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Ivan_83 (ok), 17-Июн-26, 23:36 
Может на перле и есть извращенцы, но в 2011 году его синтаксис не помешал мне с нуля накорябать там целый DHCPv4 демон.

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

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

266. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (91), 18-Июн-26, 12:20 
>Строки 52 и 62, в которых больше всего буков

Ыкспертиза
>ненужный языковой мусор

Где именно вы увидели мусор?
>а первая подразумевает что нужно что то о языке знать чтобы уловить смысл

Вот ведь ВНЕЗАПНО! А что, perl не нужно знать? Вот что такое @_ ? Что такое while(<>) ?
>потому что так сходу не понятно что там происходит.

Потому, что вы не0силят0р. Если бы у вас была бы хотя бы насмотренность, то вы бы сразу догадались, что речь идёт о присваивании, изменяемом заимствовании, срезе. Но ведь вы же ничего не знаете. Аналогично, вы даже не можете узнать приведение типов.

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

294. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 16:34 
Чувак, язык где так пишут:
core::ptr::write_unaligned(buf.as_mut_ptr().cast::<[u8; 2]>(), dist.to_le_bytes())
это помойка.
Заметь, именно язык, потому что это его часть.

Да, на С было можно написать тоже самое, но это не являлось бы частью языка, а было бы частью либы или приложения.

Если вам не понятно что это помойка - увы.

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

297. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (297), 18-Июн-26, 17:05 
> Чувак, язык где так пишут:
> core::ptr::write_unaligned(buf.as_mut_ptr().cast::<[u8; 2]>(), dist.to_le_bytes())

А что тут непонятного?

> это помойка.

Написал чучак пишущий "java/javascript"))

> Заметь, именно язык, потому что это его часть.

Тебе расстраивают длинные слова? Или непонятные значки?

> Да, на С было можно написать тоже самое, но это не являлось бы частью языка, а было бы частью либы или приложения.

Пф, на СИ пишут вот так
#define __is_constexpr(x) \
    (sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8)))
И это дepьмо хотели запхать вот прям в ядре линукс.

> Если вам не понятно что это помойка - увы.

Увы? Слушай мнение ваньки, который кроме СИ и луа вообще ничего не учил мало кого волнует.
Посмотри сколько новостей про раст, как бы тебе не нравилось - караван идет.


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

298. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 18:09 
__is_constexpr() - вот что пишут на С.
Остальное там под капотом.

(sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8))) - это как раз то как на расте пишут.


> Написал чучак пишущий "java/javascript"))

java/javascript/c/c++/php - мне примерно одинаково их читать если что. Там более-менее С подобный синтаксис везде.
Это вы эстетствуете и строите из себя граммар наци, а мне пофиг на чём написать чтобы заработало. Особенно когда это чужой написанный и работающий код и его надо немного поправить.


> Тебе расстраивают длинные слова? Или непонятные значки?

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

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

299. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +2 +/
Сообщение от Аноним (19), 18-Июн-26, 18:49 
>> Написал чучак пишущий "java/javascript"))
> java/javascript/c/c++/php - мне примерно одинаково их читать если что.

Ахахаха, особенно пыха, который больше на какой-то $баш $похож.

> Это вы эстетствуете и строите из себя граммар наци, а мне пофиг на чём написать чтобы заработало.

При чем тут "эстетствуете"?
Мне как раз тоже пофиг - если будет работать, и поэтому делать козью мopду и кривиться "ой тут много двоеточий" я не буду.

> Нет, оно слишком корявое чтобы с ним связыватся, вот мой диагноз.

Да, и это диагноз человека ничего кроме СИ и луа не трогавшего.

> Я уже много раз писал: развесистый синтаксис ни в одну голову не влезет, поэтому язык или простой и популярный или такой как кресты и раст - для странных людей с ЧСВ.

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

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

Типа сишники см огут назвать все 193 варианта UB в С99 по памяти)
Лучше лишний раз заглянуть в справку, чем часами ловить use-after-free.

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

326. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 19-Июн-26, 00:17 
> Мне как раз тоже пофиг - если будет работать, и поэтому делать козью мopду и кривиться "ой тут много двоеточий" я не буду.

Таки да.
Но по молодости я уже писал код внешне отдалённо похожий на то что в патче к либе, и спустя годы понял что так не стоит писать - потому что потом (спустя лет 5) ничего не понятно.
Я так же ходил в сторону своей либы со всеми функциями на свете, включая врапперы к библитечным и тоже понял что это плохая идея ибо упомнить это всё не возможно и лучше лишний раз написать пару строчек с библиотемным кодом и копипастить их чем написать их в свой враппер.


> Да, и это диагноз человека ничего кроме СИ и луа не трогавшего.

Ахха, и компа у меня своего нет, мне ребёнок сообщения под диктовку сюда пишет :)


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

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


> Типа сишники см огут назвать все 193 варианта UB в С99 по памяти)

А зачем?
Я вам писал про то, что даже оглавление по тому какие функции есть в крестах или расте в голове сильно проблематично, а без такого кеша скорость написания или чтения+понимания сильно падает.
В случае С - язык да и либа довольно скудные, не сложно запомнить что есть и типовые приёмы применения.

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

300. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 18-Июн-26, 20:28 
> поэтому язык или простой и популярный или такой как кресты и раст - для странных людей с ЧСВ

И тебя не смущает, что именно на крестах написан компилятор твоей Сишечки?

И не смущает писать о "популярности" языка, удел которого - ядро ОС да несколько дырявых библиотек? Причем пишешь ты вот прямо из браузера на C++.

Такого лицемера, как ты, еще поискать нужно.

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

302. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 20:58 
Не смущает.
В случае крестов лягушку варят постепенно, многие и не понимают что происходит за последние лет 25 с языком.
А у раста сразу кипяток, туда самые этисамые идут.

Ещё и игры все в которые я играю на крестах написаны - мне норм если что.
Я ж не фонатик как растоманы, которым везде какие то страхи мерещатся.

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

305. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 18-Июн-26, 21:07 
> Не смущает.
> Ещё и игры все в которые я играю на крестах написаны - мне норм если что.
> Я ж не фонатик...

...а лицемер, о чем я выше и написал.

> В случае крестов лягушку варят постепенно, многие и не понимают что происходит за последние лет 25 с языком.

Зато опеннетного Ваньку не проведешь - он-то все насквозь видит и понимает! Не то, что эти писаки компиляторов и 95% остального софта, которым Ванька ежедневно пользуется.

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

307. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (91), 18-Июн-26, 21:13 
>язык где так пишут:

Так - это как? Я у вас спрашиваю, какая именно проблема вас смущает, ткните пальцем, а вы дальше строки не продвинулись.
>Заметь, именно язык, потому что это его часть.
>Да, на С было можно написать тоже самое, но это не являлось бы частью языка

Совершенно непонятно, по какому принципу вы записываете или не записываете что-то в часть языка.
>Если вам не понятно что это помойка - увы.

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

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

323. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 23:29 
core::ptr::write_unaligned
Если это не часть языка то что?

as_mut_ptr()
Это тоже похоже на встроенный тип.

.cast::<[u8; 2]>()
Это опять что то от языка.

to_le_bytes()
это 50/50 - может и где то в проге/либе реализовано, проект которой обсуждается.


> Перловский код вы почему-то никак комментировать не стали.

Потому что меня он мало интересует.

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

329. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (91), 19-Июн-26, 00:50 
>Если это не часть языка то что?

Ну приплыли. Вы кроме как цитирования текста мысли связно формулировать можете? Если вы приводите какой-то фрагмент, то вы должны указать, что именно вам не нравится. Двоеточия мешаются? А вы давно c++ видели? Давно? Вы же говорили, что perl нормально выглядит, тут решение один в один. Кроме того, против php где они выглядят как \ вы тоже не возражали.
>Это тоже похоже на встроенный тип.

При чём здесь тип, когда мы говорим о синтаксисе? Но в любом случае, это не тип, это вызов функции.
>to_le_bytes()

Что дальше? Что именно здесь вам не нравится?
>это 50/50 - может и где то в проге/либе реализовано, проект которой обсуждается.

Дальше что? У вас нет никакого вывода.

Вы мало того, что лицимерите, когда говорите что в rust ужасный синтаксис, вы ещё и лжёте, когда говорите про синтаксис других языков, ведь в них точно такие же конструкции вы старательно не замечаете.
>Потому что меня он мало интересует.

Так с этого и надо начинать. Вы не разбираетесь не только в rust но и в perl в придачу, зато высказываете своё ыкспертное мнение что по одному, что по второму. Не удивлюсь, если вы и в си точно так же плаваете.

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

334. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 19-Июн-26, 02:43 
>> Это тоже похоже на встроенный тип.
> Вы не разбираетесь не только в rust но и в perl в придачу, зато высказываете своё ыкспертное мнение что по одному

Да этот персонаж вон даже типы данных от имен методов не отличает. От чем тут можно говорить вообще?

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

343. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (123), 19-Июн-26, 08:22 
Инлайны кастов (::cast, to_mut_ptr), трансформаций данных (иначе что ещё может означать .to_le_bytes) внутри вызова функции - это лютый говнокод. На Си так тоже можно сделать, но не нужно, плюс этого происходит меньше ибо меньше сумасшедших типов встроенных, аля того же mut.

Покажите сначала код, который не писал только что узнавший про другие языки пейсатель на JavaScript/Python, херачащий киллометровые строки из вызовов, где на каждой точке меняется тип данных и происходит мутация, да ещё и десяток тайпкастов (включая to_mut). И тогда можно будет сравнивать ваш nightly язык, всё ещё не пришедший к стабильному стандарту и имеющий всего один компилятор (потому что стандарта нету, хотя бы де-факто) с лингва-франка компьютеров.

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

356. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 19-Июн-26, 15:54 
Какой вопрос - такой ответ.
Ответить | Правка | К родителю #329 | Наверх | Cообщить модератору

312. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 18-Июн-26, 21:35 
> Чувак, язык где так пишут:

core::ptr::write_unaligned(buf.as_mut_ptr().cast::<[u8; 2]>(), dist.to_le_bytes())
это помойка.
> Заметь, именно язык, потому что это его часть.
> Да, на С было можно написать тоже самое, но это не являлось бы частью языка, а было бы частью либы

Чел, все названия методов из твоего куска кода - это буквально и есть часть либы, а не языка.

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

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

324. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 23:30 
Не знал что zlib-rs содержит в себе:
- core::ptr::write_unaligned
- as_mut_ptr()
- cast::<[u8; 2]>()
- to_le_bytes() - ну это ещё можно поверить.
Ответить | Правка | Наверх | Cообщить модератору

333. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 19-Июн-26, 02:36 
>> Чел, все названия методов из твоего куска кода - это буквально и есть часть либы, а не языка
> Не знал что zlib-rs содержит в себе:

Не zlib-rs, а стандартная библиотека Раста. Господи...

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

357. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 19-Июн-26, 15:56 
Значит стандартная либа и есть помойка. Локация зафиксирована.
Ответить | Правка | К родителю #333 | Наверх | Cообщить модератору

48. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (48), 17-Июн-26, 14:21 
Там какой-то unsafe в юзерспейсной библиотеки. Короче, нещитово.
Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

195. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от fidoman (ok), 17-Июн-26, 21:27 
Чё-т анекдот напомнило, про отрезание кончиков у сосисок.
Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

49. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +2 +/
Сообщение от Аноним (245), 17-Июн-26, 14:22 
> Не понятно с чего бы C Незаметно бы повредил данные,а Rust упал.
> С чего бы раст это отдетектил.

Банально с того, что в Расте есть проверка на выходы за пределы буфера.

Я понимаю, что сишники такого в жизни не видали и вообще не понимают, как такая магия возможна - но в новости же ссылки есть на багрепорты со стектрейсами.

> Если тут идёт работа с данными, результат работы записывается куда-то.

В том и дело, что "за пределы буфера" - это не "куда надо".

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

62. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (57), 17-Июн-26, 14:40 
> Расте есть проверка на выходы за пределы буфера.

Даа, а расскажи зачем? если это задача ОС, а если это не задача ОС, то чутка подкрутить компилятор, и наша программа получает полной доступ ко всей памяти?

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

102. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от morphe (?), 17-Июн-26, 15:51 
ОС выдаёт память постранично, от 4кб до нескольких мегабайт
Всё что происходит внутри страниц это уже ответственность юзерспейса отслеживать
Ответить | Правка | Наверх | Cообщить модератору

183. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (245), 17-Июн-26, 20:27 
>> Расте есть проверка на выходы за пределы буфера.
>Даа, а расскажи зачем?

В новости написано, зачем:

"в Си подобная ситуация привела бы к незаметному повреждению данных без остановки работы"

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

74. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Другой Аноним (?), 17-Июн-26, 14:50 
> > Не понятно с чего бы C Незаметно бы повредил данные,а Rust упал.
> > С чего бы раст это отдетектил.
> Банально с того, что в Расте есть проверка на выходы за пределы буфера.

То есть runtime проверка границ буфера в rust это не миф?

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

201. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (123), 17-Июн-26, 21:42 
Вы не понимаете, раст это делает дешевле(tm) и быстрее(c) с неправильно пропаршенными даннами (т.е. мы понятия не имеем, что происходит), чем правильно написанный код с правильно пропаршенными данными на сишке. Обезьянки никак не поймут, что ошибки с памятью - это симптом невалидности данных, а не сама по себе проблема.
Ответить | Правка | Наверх | Cообщить модератору

206. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 17-Июн-26, 21:55 
> чем правильно написанный код с

Ох уж этот мифический "правильно написанный код С". 😂 Где же его увидеть-то? Ведь бесконечный поток CVE с выходами за пределы буферов примерно на 100% состит именно из сишочного кода.

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

232. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (123), 18-Июн-26, 00:22 
Если чёрт ногу сломит разобраться, что происходит с данными в Си коде - это плохой Си код. В расте происходит дроч на псведо-джавовский псевдо-ооп синтаскис со всеми этими .make_slice и прочей дичью занимающей четыре экрана (как будто специально для лллмок писали, чтобы натренированный кланкер на английском мог дополнить всё украденным с реддита, стаковерфлоу, гитхаба и википедии кодом), и он вообще не помогает писать код лучше, тем более читать его.
Ответить | Правка | Наверх | Cообщить модератору

283. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Анонимemail (283), 18-Июн-26, 13:57 
> В расте происходит дроч на псведо-джавовский псевдо-ооп синтаскис

Дядь, а ты вообще знаешь, что такое ООП и как java выглядит? Я бы понял, если бы сравнили в каким-нибудь OCaml (откуда в раст утащили алгебраические типы и паттерн-матчинг), но с ждавой???? Ну с жабоскриптом может еще какое-то сравнение в качестве совы на глобус натянуть, но точно не жабоподбные языки. Да там вообще нихрена общего, кроме некоторых закорючек

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

207. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 17-Июн-26, 21:56 
> То есть runtime проверка границ буфера в rust это не миф?

А кто-то говорил, что миф?

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

282. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Другой Аноним (?), 18-Июн-26, 13:57 
Кто-то говорил, что без рантайм оверхеда
Ответить | Правка | Наверх | Cообщить модератору

286. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 18-Июн-26, 15:26 
> Кто-то говорил, что без рантайм оверхеда

Ну вот им вопросы и задавай.

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

296. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Другой Аноним (?), 18-Июн-26, 16:55 
Вы хоть как-нибудь помечайте друг друга.
Ответить | Правка | Наверх | Cообщить модератору

75. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (91), 17-Июн-26, 14:50 
>Если тут идёт работа с данными, результат работы записывается куда-то.

Не куда-то а вне буфера. Неуж-то сишники не понимаю, что такое переполнение буфера?

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

184. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 17-Июн-26, 20:29 
> Неуж-то сишники не понимаю, что такое переполнение буфера?

Судя по его постановке вопроса, он вообще человек, далекий от какого-либо программирования.

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

233. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (123), 18-Июн-26, 00:23 
Буферов не существует. Кто-то не понимает, как работает виртуальная память.
Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

246. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 18-Июн-26, 02:21 
> Буферов не существует.

...но сишники об этом не знали и продолжали вылазить за их пределы.

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

288. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (91), 18-Июн-26, 16:12 
Тот кто не верит в существование буеферов, пусть для начала прочитает про выделение памяти.
Ответить | Правка | К родителю #233 | Наверх | Cообщить модератору

40. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +2 +/
Сообщение от НяшМяш (ok), 17-Июн-26, 14:10 
Забавно, что с тем же Хаффманом такая же ошибка вылезла сначала в Unreal Engine. В блог посте есть ссылка на статью годовалой давности - https://fgiesen.wordpress.com/2025/05/21/oodle-2-9-14-and-in.../
Ответить | Правка | Наверх | Cообщить модератору

42. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +8 +/
Сообщение от Аноним (48), 17-Июн-26, 14:12 
> Библиотека zlib-rs была задействована в выпуске Firefox 151, но после её интеграции некоторые пользователи столкнулись с проблемой, приводившей к аварийному завершению из-за выхода за допустимые границы.

А я ведь говорил, что вся эта проржавевшая безопасность с трансляцией в LLVM-IR - это фигня, если ржавый сам не компилирует свой код в ассемблер. Достаточно найди багу в LLVM-бекенде и на специально скрафтенном ржавом коде будут и переполнения и боровы все поразбегаются. Но раctoфили не верили.

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

55. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (55), 17-Июн-26, 14:28 
Какая связь с трансляцией в LLVM-IR и багом в cpu? Любой другой компилятор на любом другом языке сделал бы то же самое если в нём не было бы предварительно зашита информация что такой ассемблерный код генерировать нельзя.
Ответить | Правка | Наверх | Cообщить модератору

63. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (48), 17-Июн-26, 14:40 
Вот всегда у вас так - во всем виноваты Си-библиотеки, с которыми вы линкуетесь, ядро на Си, в котором вы процессы форкаете, теперь вот и процессоры у вас виноваты. Короче, виноваты все вокруг, но не код на расте.
Ответить | Правка | Наверх | Cообщить модератору

76. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (55), 17-Июн-26, 14:53 
В посте есть ссылка на блог разработчика Oodle, который на этот баг наткнулся (и зарепортил) год назад. Не нашёл подтверждений, но что-то мне подсказывает что пишет он на C или C++, а не на Rust, и ему тоже пришлось модифицировать свой код, чтобы компилятор не генерировал инструкций, вызывающих проблем в процессоре.
Ответить | Правка | Наверх | Cообщить модератору

160. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (245), 17-Июн-26, 18:22 
> А я ведь говорил, что вся эта проржавевшая безопасность с трансляцией в LLVM-IR - это фигня

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

"Отмечается, что в коде на языке Rust проблема приводила к аварийной остановке, в то время как в Си подобная ситуация привела бы к незаметному повреждению данных без остановки работы"

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

> Достаточно найди багу в LLVM-бекенде и [...] будут и переполнения и боровы все поразбегаются.

Очередной эксперт не отличает проверки времени компиляции от проверок в рантайме. 🥱

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

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

167. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (167), 17-Июн-26, 19:01 
> То есть язык буквально позволил выловить багу компилятора (при которой сишочка просто бы дала бы вулн),

Не компилятора, а конкретного CPU. Но да, сути это не меняет.

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

203. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (123), 17-Июн-26, 21:46 
Выловили её в тестах в дебаг билде, а не на этапе компиляции. Причём тут раст? Причём с таким синтаксисом (buf.get_slice().to_bytes().only_give_me_lowest_ones().do_it_fast()[42 .. 69]) ничем не лучше, чем написать библиотеку-обёртку для си вокруг операций с памятью, которые будут делать ровно то же самое, только намного читабельнее и ближе к сути, без трёхэтажных преобразований типа байт в тип uint8.
Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

208. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (245), 17-Июн-26, 22:04 
> Выловили её в тестах в дебаг билде, а не на этапе компиляции.

Да, естественно. Об этом и речь. Или как вы представляете себе отлов ошибки CPU на этапе компиляции?

> Причём тут раст?

Эмм... Потому что выловили ее в коде, написанном на Расте при помощи проверок, которые делает Раст.

> написать библиотеку-обёртку для си вокруг операций с памятью, которые будут делать ровно то же самое

Конечно можно написать обертки. А еще можно и за беферы не вылазить, и doouble-free с use-after-free не делать, и вообще писать надежный и безопасный код на С. Только жаль, что за более чем полувека существования языка этого ни у кого так и не получилось.

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

214. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –4 +/
Сообщение от ProfessorNavigator (ok), 17-Июн-26, 22:48 
>[оверквотинг удален]
> Да, естественно. Об этом и речь. Или как вы представляете себе отлов
> ошибки CPU на этапе компиляции?
>> Причём тут раст?
> Эмм... Потому что выловили ее в коде, написанном на Расте при помощи
> проверок, которые делает Раст.
>> написать библиотеку-обёртку для си вокруг операций с памятью, которые будут делать ровно то же самое
> Конечно можно написать обертки. А еще можно и за беферы не вылазить,
> и doouble-free с use-after-free не делать, и вообще писать надежный и
> безопасный код на С. Только жаль, что за более чем полувека
> существования языка этого ни у кого так и не получилось.

А покажите нам код, написанный лично вами, уважаемый эксперт. Чтобы мы оценил уровень вашей квалификации и впечатлились.


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

229. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (229), 18-Июн-26, 00:16 
> А покажите нам код, написанный лично вами, уважаемый эксперт. Чтобы мы оценил уровень вашей квалификации и впечатлились.

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

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

230. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от ProfessorNavigator (ok), 18-Июн-26, 00:18 
> Удивительно видеть, как вы заикаетесь о качестве кода после того, как буквально
> в каждой новости о вашем MyLibrary в комментариях все выпадают и
> от качества вашего кода, и от квалификации, и от реакции на
> любую попытку указать вам на ошибки.

Попытка перевести стрелки не засчитана)) А говорите - уведомления не настраивали...

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

269. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (91), 18-Июн-26, 12:47 
>Чтобы мы оценил уровень вашей квалификации и впечатлились.

А вы способны понять чужую мудрость? Ну держите специально упрощённый пример.

%token LESS
%token MORE
%token <string> NAME

tag:
| LESS; t = NAME; MORE
  { Tag t }

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

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

273. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от ProfessorNavigator (ok), 18-Июн-26, 12:52 
>>Чтобы мы оценил уровень вашей квалификации и впечатлились.
> А вы способны понять чужую мудрость? Ну держите специально упрощённый пример.
> %token LESS
> %token MORE
> %token <string> NAME
> tag:
> | LESS; t = NAME; MORE
>   { Tag t }
> А теперь объясните что здесь написано, и чем это лучше вашего г-кода.
> А потом, живо переписывать ваш г-код.

Не-не-не, ссылочку на проект, написанный лично вами, будьте добры. Впрочем - и так всё понятно.

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

275. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (91), 18-Июн-26, 12:58 
>Не-не-не, ссылочку на проект

У очередного ыксперта случился приступ "ой всё". Сначала вам код подавай, потом проект, потом вы в проекте язык непонятный увидите, потом ещё к чему-то придерётесь. Так что не уезжайте с темы, быстро отчитывайтесь, чем этот код лучше чем ваш велосипед.

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

276. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –2 +/
Сообщение от ProfessorNavigator (ok), 18-Июн-26, 13:22 
>>Не-не-не, ссылочку на проект
> У очередного ыксперта случился приступ "ой всё". Сначала вам код подавай, потом
> проект, потом вы в проекте язык непонятный увидите, потом ещё к
> чему-то придерётесь. Так что не уезжайте с темы, быстро отчитывайтесь, чем
> этот код лучше чем ваш велосипед.

Свободен))

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

308. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (91), 18-Июн-26, 21:14 
Мне совершенно не понятно, зачем затягивать дискуссию, если вы первым же сообщением можете написать "ой всё", чтобы сразу всем всё было понятно?
Ответить | Правка | Наверх | Cообщить модератору

316. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от ProfessorNavigator (ok), 18-Июн-26, 22:11 
> Мне совершенно не понятно, зачем затягивать дискуссию, если вы первым же сообщением
> можете написать "ой всё", чтобы сразу всем всё было понятно?

Всё просто. дружище, всё просто... Я ведь не скрываю, какова моя цель. В отличие от вас, господа. Цель - показать, кто вы есть на самом деле, чтобы помешать вам делать то, что вы делаете. И ведь забавно, как просто это делать. Достаточно банального "Talk is cheap, show me the code".

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

328. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (91), 19-Июн-26, 00:27 
>Я ведь не скрываю, какова моя цель

Нести мракобесие в массы?

Я вам скинул предельно конкретный пример, что вы сделали? Проигнорировали. Какой смысл вам скидывать лично мой код, если вы его тупо не сможете понять?

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

351. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от ProfessorNavigator (ok), 19-Июн-26, 15:44 
>>Я ведь не скрываю, какова моя цель
> Нести мракобесие в массы?
> Я вам скинул предельно конкретный пример, что вы сделали?
> Проигнорировали.

Естественно, что я его проигнорировал. Потому что он не на Ржавом и не на С, а на JS или чём то подобном (простите, но в сортах г... лично мне разбираться не интересно). Т.е. вы понятия не имеете, о чём вы говорите - эти ЯП созданы для другого и используются по-другому. И то, что код ваш - установить невозможно. Я вам точно такой же пример могу накидать на чём угодно. С помощью поисковика.

Вообще интересная картина складывается. Вы высказали ваше мнение о С. Мне оно показалось в корне неверным, но я всего знать не могу, поэтому попросил вас (или того, кто изначальный комментарий написал - кто вас, анонимов разберёт) подтвердить вашу квалификацию - вполне вероятно, что вы знаете что-то, чего не знаю я. В ответ же я получил потоки сознания, переход на обсуждение моей личности и моего кода. Хотя ни я, ни мой код тут вообще не при чём. Из чего следует сразу несколько выводов:

1) Ваша квалификация в обсуждаемом вопросе - нулевая.  
2) Но тем не менее мнение своё высказываете. Причин тому может быть несколько. Ваша глупость, преследование корыстных интересов или и то и другое сразу (наиболее вероятный вариант). Поскольку при этом конечную цель ваших действий вы, очевидно, скрываете - я делаю вывод, что ваши действия могут быть недружелюбными и направленными во вред как мне, так окружающим меня людям. В свете чего логично, что я вам буду мешать всеми доступными способами. Прекратить это можно двумя способами - перестаньте делать то, что вы делаете или проясните ваши цели, и если я в свою очередь сочту их приемлемыми, то перестану вам мешать.

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

353. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (353), 19-Июн-26, 15:48 
Ого, сколько вы понаписивали.

> Мне оно показалось в корне неверным,

Мнение человека прославившегося отвратительным кодом. Очень ценное.

> поэтому попросил вас подтвердить вашу квалификацию

Зачем? С вашей квалификацией и так все ясно.

>  Из чего следует сразу несколько выводов:

Приходи когда научишься писать код нормально.

Свободен!

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

372. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (91), 20-Июн-26, 03:28 
>Естественно, что я его проигнорировал.

Нет, не естественно. Вы, когда вам дают то, что вы просите, начинаете выкручиваться, придумывая требования задним числом.
>Потому что он не на Ржавом и не на С

Какой неубедительный аргумент. Знанием о том, что си дыряв, может обладать даже шестикласник, который видел пару примеров сишного кода.
>а на JS или чём то подобном

И близко не угадали
>Т.е. вы понятия не имеете, о чём вы говорите - эти ЯП созданы для другого и используются по-другому.

Вы так говорите, словно человек может знать только один язык.
>Мне оно показалось в корне неверным

Что нужно делать, когда кажется?
>подтвердить вашу квалификацию - вполне вероятно, что вы знаете что-то, чего не знаю я

Для того, чтобы подтвердить мнение, нужно об этом мнении говорит, а не уводить разговор в сторону.

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

(* patscc -DATS_MEMALLOC_LIBC -o main main.dats -latslib *)
#include "share/atspre_staload.hats"
staload "libats/libc/SATS/stdio.sats"
staload "libats/libc/SATS/stdlib.sats"

implement main0 () =
  let
    (* ввод *)
    val () = fprintln!(stdout_ref, "Write ascii line")
    val strptr = fileref_get_line_string stdin_ref
    val strnptr = strptr2strnptr strptr
    val () = fprintln!(stdout_ref, "Write index")
    val idx_strptr = fileref_get_line_string stdin_ref
    val str_str = strptr2string idx_strptr
    val i = atoi str_str
    val () = fprintln!(stdout_ref, "Index is ", i)
    (* проверка *)
    val j = g1ofg0_int i
    val length = strnptr_length strnptr
    val _ = g1int_lt(j, 4)
    val l = g1ofg0_int length
    val c0 = length > j
    val c1 = j > ~1
    (* печать *)
    val () =
      if c0 then
        if c1 then
          let
            val c = strnptr_get_at (strnptr, j)
          val _ =
           fputc0_char(c, stdout_ref)
          in
            fprintln!(stdout_ref, "")
          end
    in
    (* освобождение ресурсов *)
    strnptr_free (strnptr)
  end

Данный код просит ввести ascii строку, после чего предлагает ввести индекс, а после чего печатает символ по этому индексу, и наконец - освобождает память. Чем этот код лучше сишного аналога? Тем, что если сишник забудет освободить ресурсы, и не напишет free, то программа скомпилируется, а память утечёт. Если вы удалите strnptr_free из кода выше, то вас будет ждать ошибка компиляции. Так же, как вы видите, в коде предусмотрена проверка, чтобы пользователь не вылез за границы массива. Если вы замените c0 или c1 на true, то вас тоже будет ждать ошибка компиляции. Таким образом, ATS даёт вам гораздо больше гарантий, чем си, плюсы и раст вместе взятые. Если вы перепишите этот код на один из этих языков, а потом удалите любую из предложенных строк, то эти языки с радостью пропустят эту ошибку прямо в прод. У вас не получится сделать функциональный аналог ни на одном из них.

Разобрались наконец-то?

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

375. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от ProfessorNavigator (ok), 20-Июн-26, 11:59 
Дружище, скажите, вы по русски хорошо понимаете? Если нет - я могу на английском продублировать. Других языков, к сожалению, не знаю, но могу попробовать через автопереводчик. Так вот для сидящих в танке повторяю через дуло: сначала подтвердите, что вы программист на С или хотя бы на Ржавом - пришлите ссылку на проект, в котором лично вы принимаете участие - только потом будем с вами на тему C/Ржавого разговаривать. Нет подтверждения - сразу свободен. Ну и поинтересуйтесь - кому и что вы пишите. А то читать смешно. И да - работодателю передайте пламенный привет. Чем больше он будет подобной ерундой сейчас заниматься, тем хуже ему будет потом. Не угрожаю - просто констатирую факт, исходя из знания истории.

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

335. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (245), 19-Июн-26, 02:46 
> Цель - показать, кто вы есть на самом деле, чтобы помешать вам делать то, что вы делаете.

Ты бы лучше пошел, да C++ нормально выучил. У тебя код будто пьяная обезьяна писала.

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

277. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (277), 18-Июн-26, 13:29 
Прохфессор! А вот и вы!
Покажите пожалуйста свой код (только желателльно нормальный, а не тот ужас который вы показывали в прошлый раз).

Вашу квалификацию мы уже оценили.
Может вы сможете исправить мнение, но сомнительно.

А пока не научитесь хотя бы парсер без ошибок написать - можете быть свободны))

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

279. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от ProfessorNavigator (ok), 18-Июн-26, 13:43 
> Прохфессор! А вот и вы!
> Покажите пожалуйста свой код (только желателльно нормальный, а не тот ужас который
> вы показывали в прошлый раз).
> Вашу квалификацию мы уже оценили.
> Может вы сможете исправить мнение, но сомнительно.
> А пока не научитесь хотя бы парсер без ошибок написать - можете
> быть свободны))

Попытка съехать с темы №2 снова не засчитана. Кода, я так понял, не будет.


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

281. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (281), 18-Июн-26, 13:51 
> Попытка съехать с темы №2 снова не засчитана.

Куда сьехать? Вы о чем?

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

Вот зачем ему вообще что-то доказывать?

> Кода, я так понял, не будет.

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


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

234. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 00:23 
Выловили её в коде на расте только авторы статьи.
Тут в коментах уже была ссылка как годом ранее в анреал(вроде) выловили этоже самое, там раста нет - сплошные кресты.
Ответить | Правка | К родителю #208 | Наверх | Cообщить модератору

248. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 18-Июн-26, 02:24 
> Выловили её в коде на расте только авторы статьи.

Естественно, ведь новость о них.

> Тут в коментах уже была ссылка как годом ранее в анреал(вроде) выловили этоже самое, там раста нет - сплошные кресты.

И что это значит?

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

295. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 16:36 
Вон же ниже уже написали:

> почитайте внимательней, эту ошибку обнаружили до того, и не благодаря средствам безопасности в
> Расте (https://fgiesen.wordpress.com/2025/05/21/oodle-2-9-14-and-in...-).

Это до растеров долго доходило.

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

241. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (48), 18-Июн-26, 01:52 
> Да, естественно. Об этом и речь. Или как вы представляете себе отлов ошибки CPU на этапе компиляции?

Не знаю. Это ж у вас там безопасный ЯП, вот и думайте как.

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

267. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (91), 18-Июн-26, 12:27 
>Причём с таким синтаксисом >(buf.get_slice().to_bytes().only_give_me_lowest_ones().do_it_fast()[42 .. 69])

Каким синтаксисом? Вы испугались цепочки вызова методов? Так это есть практически везде. Или вас срезы так пугают?
>чем написать библиотеку-обёртку для си вокруг операций с памятью, которые будут делать ровно то же самое

Она не будет делать то же самое, она будет портить память. Спросите любого ненастоящего сишника, хоть из linux, хоть из freebsd, хоть из xorg.

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

268. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от ProfessorNavigator (ok), 18-Июн-26, 12:31 
> Она не будет делать то же самое, она будет портить память.

А теперь покажите нам ваш код, хотя бы на Ржавом. Чтобы мы поняли уровень вашего экспертного мнения.

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

336. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 19-Июн-26, 02:48 
> А теперь покажите нам ваш код, хотя бы на Ржавом. Чтобы мы поняли уровень вашего экспертного мнения.

Твой, прости господи, код уже все видели. Не тебе тут об "уровне" заикаться.

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

354. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от ProfessorNavigator (ok), 19-Июн-26, 15:51 
> Твой, прости господи, код уже все видели. Не тебе тут об "уровне"
> заикаться.

А при чём здесь я? Не я высказываю "экспертное" мнение.

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

366. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (245), 19-Июн-26, 16:52 
>> Твой, прости господи, код уже все видели. Не тебе тут об "уровне"
> заикаться.
> А при чём здесь я? Не я высказываю "экспертное" мнение.

При том, что ты собрался код оценивать. С твоим-то "уровнем".

Говорить с бракоделом не о чем.

Свободен.

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

304. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 21:06 
Не испугались мы, нету у нас фобий относительно никчёмности кода или людей с отлонениями.

Просто такая запись, если это где то на С написано считается "плохо пахнущим кодом". А у вас на расте большая часть кода так записана.

buf.get_slice()
to_bytes()
only_give_me_lowest_ones()
do_it_fast()
это ЧЕТЫРЕ вызова функций подряд, без каких либо проверок что они отработали без ошибок.
А потом там видимо ещё на выходе ожидают массива определённого размера и обращаются к его элементам, опять без проверок.

Знаю ваше "языка вумный, не то что мы глупые, он фсё проверит сама!".
Ну проверит, дальше то что произойдёт?
Прога упадёт на ровном месте из за некритичной ошибки с непонятным сообщением об ошибке?

Ну так и на С некоторые пишут: тяп-ляп, упадёт и ладно, значит данные кривые были или памяти не хватило - пусть юзер сам разбирается, у меня то работает.
А потом приходят растовщики с таким же кривым кодом на расте и учат жизни.


> Она не будет делать то же самое, она будет портить память. Спросите любого ненастоящего сишника, хоть из linux, хоть из freebsd, хоть из xorg.

Так раст собирается с помощью LLVM написанного на крестах, те получается раст будучи собранным уже испорчен!

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

310. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (245), 18-Июн-26, 21:23 
> buf.get_slice()
> to_bytes()
> only_give_me_lowest_ones()
> do_it_fast()
> это ЧЕТЫРЕ вызова функций подряд,

Ты даже не соображаешь, что комментируешь выдуманный код. 🤦

> без каких либо проверок

При этом в новости говорится о баге, который выловили БУКВАЛЬНО благодаря этим проверкам.

> Прога упадёт на ровном месте из за некритичной ошибки

При этом в новости говорится о записи за пределы буфера с последующим RCE.

> с непонятным сообщением об ошибке?

При этом в новости по ссылке аккуратненький стек вызовов.

В сухом остатке ты просто наглый лжец.


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

321. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 22:53 
> Ты даже не соображаешь, что комментируешь выдуманный код.

https://github.com/trifectatechfoundation/zlib-rs/pull/520/f...
Ну да, реально выдуманный, а потом закомиченный в кодовую базу.
В чём проблема с кодом я описал :)


> При этом в новости говорится о баге, который выловили БУКВАЛЬНО благодаря этим проверкам.

Новость перечитай, её год назад выловили, даже больше, в проекте не то на С не то на крестах (лень смотреть).


> При этом в новости говорится о записи за пределы буфера с последующим RCE.

У вас в каждая кошка на улице говорит об RCE, как только мир не развалился.


> При этом в новости по ссылке аккуратненький стек вызовов.

0  xul.dll  MOZ_Crash(char const*, int, char const*)  mfbt/Assertions.h:382
0  xul.dll  RustMozCrash(char const*, int, char const*)  mozglue/static/rust/wrappers.cpp:18
1  xul.dll  mozglue_static::panic_hook(std::panic::PanicHookInfo*)  mozglue/static/rust/lib.rs:102
2  xul.dll  core::ops::function::Fn::call<void (*)(ref$<std::panic::PanicHookInfo>), tupl...  /rustc/4d91de4e48198da2e33413efdcd9cd2cc0c46688/library/core/src/ops/function.rs:250
3  xul.dll  alloc::boxed::impl$30::call()  library/alloc/src/boxed.rs:2007
3  xul.dll  std::panicking::rust_panic_with_hook()  library/std/src/panicking.rs:836
4  xul.dll  std::panicking::begin_panic_handler::closure$0()  library/std/src/panicking.rs:701
5  xul.dll  std::sys::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_h...  library/std/src/sys/backtrace.rs:168
6  xul.dll  std::panicking::begin_panic_handler()  library/std/src/panicking.rs:692
7  xul.dll  core::panicking::panic_fmt()  library/core/src/panicking.rs:75

Этот стёк 100% бесполезный, как и весь раст.
Найдите здесь указание на строку с проблемой.
Но моё замечание относилось вообще то к тому коду который закомиттили как исправление.


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

337. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 19-Июн-26, 03:16 
>> При этом в новости говорится о баге, который выловили БУКВАЛЬНО благодаря этим проверкам.
> Новость перечитай, её год назад выловили, даже больше, в проекте не то на С не то на крестах (лень смотреть).

В новости говорится о баге в коде FF, а не о каком-то левом "проекте не то на С не то на крестах". И В FF его обнаружили и выловили благодаря растовым проверкам.

> Найдите здесь указание на строку с проблемой.

Очевидно, что указание на файл и строку находится в сообщении об ошибке, а не в стеке вызовов. У тебя прямо под носом "(char const*, int, char const*)", но тебе некогда головой думать - нужно против Раста воевать.

https://github.com/mozilla-firefox/firefox/blob/main/mozglue...
https://github.com/mozilla-firefox/firefox/blob/main/mfbt/As...

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

342. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (123), 19-Июн-26, 08:12 
> Очевидно, что указание на файл и строку находится в сообщении об ошибке

Это называется не бектрейс, это тупо эквивалент printf внутри sigaction который повесили на segfault.

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

346. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 19-Июн-26, 10:56 
> Это называется не бектрейс

Да? Ну тогда просвети, что в твоем понимании настоящий бэктрейс и как он выглядит.

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

360. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 19-Июн-26, 16:02 
Экспертиза 80лв защитана.
Ответить | Правка | Наверх | Cообщить модератору

359. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 19-Июн-26, 16:01 
>> При этом в новости по ссылке аккуратненький стек вызовов.

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

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

313. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (91), 18-Июн-26, 21:44 
>Просто такая запись, если это где то на С написано считается "плохо пахнущим кодом".

Вы произвольным образом перемешиваете си и не си.
>это ЧЕТЫРЕ вызова функций подряд, без каких либо проверок что они отработали без ошибок.

Если бы вы были образованным человеком, то знали бы что ошибки в rust обрабатываются с помощью монад, что делает невозможным случайно забыть данную проверку, в отличии от си, где это реализовано целой кучей разных способов, которые можно элементарно забыть или перепутать без ошибки компиляции. Просто запомните, что баги можно отлавливать на этапе компиляции.
>на выходе ожидают массива определённого размера и обращаются к его элементам

Как раз для таких случаев и придуман ATS. Только вот проблема в том, что он вам ещё больше не понравится.
>Знаю ваше "языка вумный, не то что мы глупые, он фсё проверит сама!".

Кто виноват, что язык умнее вас? Ещё в 80-ые годы были способы обнаружить ошибки во время компиляции, а вы, за более чем 40 лет это до сих пор не поняли.
>Прога упадёт на ровном месте из за некритичной ошибки

Для начала, потрудитесь привести доказательство, что пользовательский код может вызвать это падение. Если вы не заметили, поля структуры объявлены приватными.
>с непонятным сообщением об ошибке?

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

Уж кому, кому, а не сишнику это говорить. Куча персонажей уверены, что разыменновывание нулевого указателя это не UB. Но, даже если сишник и хочет писать правильный код, то за неимением зависимых, алгебраический, линейных типов, а так же кучи других вещей, он не может написать корректный код.

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

322. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 23:07 
> Если бы вы были образованным человеком, то знали бы что ошибки в rust обрабатываются с помощью монад, что делает невозможным случайно забыть данную проверку, в отличии от си

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


> Просто запомните, что баги можно отлавливать на этапе компиляции.

А на практике оказывается что у вас в рантайме всё валится.


> Как раз для таких случаев и придуман ATS.

Извращенцы!
Нет чтобы обычным if() проверить.


> Кто виноват, что язык умнее вас?

Если он умнее меня - то пусть сам всё и пишит.
Раз не может сам писать - пусть заткнётся и не мешает мне.


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

Любая функция может вернуть ошибку. Бегать и проверять что это не так - себе дороже.


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

Ну да, точно.
И ещё какой то мусорный файл .core в папке постоянно появляется, и приходится его руками удалять.
Ничо нипанятно.


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

Да да, одна надежда на святую гниль, приди и спаси нас всех!!!


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

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

330. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (91), 19-Июн-26, 00:59 
>Если бы вы знали чтонибудь то слышали бы о SEH и прочих штуках

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

На каком этапе? Обрабатывать ошибки имеет смысл только в том случае, если они вызваны внешним по отношению к библиотеке кодом, а не ошибкой в самой библиотеке. Как по вашему должен работать код при сбоящем процессоре?
>А на практике оказывается что у вас в рантайме всё валится.

Сообщение про зависимые типы вы благополучно пропустили
>Нет чтобы обычным if() проверить.

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

Глупым программистам нужно мешать делать баги.
>Да да, одна надежда на святую гниль, приди и спаси нас всех!!!

Если вы не заметили, то в rust нет зависимых типов.
>Вы про С знаете ещё меньше чем я про раст

Во-первых, вы про rust не знаете ничего. Во-вторых, вы не привели ни одного доказательства моего незнания.

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

361. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 19-Июн-26, 16:10 
> Вот в этом то и проблема, что он них я могу только услышать, так как они почти нигде не применяются.

Ну раз вам запрещено применять структурные исключения то и правда нигде.
Так то почти 100% на венде содержат SEH, чтобы вы знали. Просто больше половины не ставит своих обработчиков.


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

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


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

У вас идиотия какая то: зачем ошибка компиляции нужна в данном случае?


> Глупым программистам нужно мешать делать баги.

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


> Если вы не заметили, то в rust нет зависимых типов.

Понятия не имею что это такое и знать не хочу потому что это никак не помогает достичь результата.


> Во-первых, вы про rust не знаете ничего.

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


> Во-вторых, вы не привели ни одного доказательства моего незнания.

Извините, но это похоже на синдром данинга-крюгера. Я тут бессилен что либо привести ещё.

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

373. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (91), 20-Июн-26, 03:37 
>Просто больше половины не ставит своих обработчиков.

ОЙ
>В данном конкретном случае, мне, как пользователю, хочется продолжения работы браузера с обычным сообщением об ишибке

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

Для того, чтобы не допустить выхода за пределы буфера/утечки памяти/ещё чего-то.
>Пока вы с ним сношаетесь

Вам тоже пора начинать, и желательно сразу на языке с зависимыми типами. А то иначе, вы тоже будете дыры делать, как в nginx, xorg, linux, freebsd и далее по списку.
>никак не помогает достичь результата.

Ваш результат - испорченная память?
>не могу писать большимы красными буквами чтобы до вас дошло.

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

Если вы пишите про себя, то я с вами полностью согласен.

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

377. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 20-Июн-26, 22:17 
> Работа программы на сбойном процессоре невозможно

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


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

Это у вас такая конечная цель при программировании? :)


> Ваш результат - испорченная память?

Мой результат - то для чего пишется конкретная программа, а именно для какой то пользы, а не просто чтобы там ошибак/уизвимастей не было.
И любой бизнесс предпочтёт сегодня рабочую программу чем через 2 года идеальную.

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

338. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 19-Июн-26, 03:22 
> А что касается кода патча - оно сумеет продолжить работу или аварийно завалит весь процесс при ошибке на любом этапе в цепочке?
> Если да - то грош этому цена, ибо я говорил про продолжение работы при таких некритичных ошибках.

Чел, что ты несешь? У тебя буквально железо поломано на уровне выполнения инструкций, а ты поешь про "некритичные" ошибки?

Объясни, по какой логике это является "некритичной ошибкой" и каким образом ты себе представляешь "продолжение работы" в такой ситуации?

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

362. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Ivan_83 (ok), 19-Июн-26, 16:17 
Чувак, ты вообще читать умеешь?

ВСЁ ЖЕЛЕЗО ПОЛОМАНО!!!
Вообще всё!
Понимаешь!?

Иди почитай ErrATA на процы и топики в LLVM чтобы осознать.
Это так было с самого начала индустрии.
Все (ну кто считает себя хоть как то причастным к индустрии) должны были слышать про ошибку в пнях когда они float иногда неправильно считали.
А помимо этого там ещё была куча всего, на что наступали реже.
Но никто не озывал железо, не бегал со своим растом и не бился в истерике, просто пропатчили софт.


Здесь не критическая ошибка, от того что zlib не смог декодировать ответ присланный сервером ничего страшного для юзера не произошло, максимум что заслужил юзер в случае адекватного софта это сообщение об ошибке: не удалось декодировать ответ сервера.
Никак не выпадание процесса в корку.

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

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

168. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (167), 17-Июн-26, 19:15 
> безопасность с трансляцией в LLVM-IR - это фигня, если ржавый сам не компилирует свой код в ассемблер.
> Достаточно найди багу в LLVM-бекенде

Вы уверены, что в самописном велосипедном компиляторе было бы меньше багов?

И при чем тут "бага в LLVM", если в новости говорится о баге в конкретном CPU? Причем баге, выловленном именно благодаря средствам безопасности в Расте (в данном случае - банальной проверкой на границы), которые, по вашим, словам, якобы "фигня"? То ли вы и вправду не видете тут противоречий, то ли просто дешево набрасываете.

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

Ну и количество плюсиков вашему комментарию прекрасно показывает уровень технических знаний местных воинов против Раста.

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

242. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (48), 18-Июн-26, 01:55 
> И да, спешу вас огорчить, но любой компилятор использует ту или иную форму промежуточного представления, а не сходу компилирует "код в ассемблер".

Ты правда думаешь что я этого не знаю? Я как бы учился в ВУЗе еще в те стародавние времена, когда написание своего примитивного Си-компилятора это была просто лабораторная работа, а не что-то из ряда вон выходящее что аж на Хабре можно 10 статей написать.

> Ну и количество плюсиков вашему комментарию прекрасно показывает уровень технических знаний местных воинов против Раста.

Я тут не причем и даже не обращаю на это внимание.

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

249. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (245), 18-Июн-26, 02:29 
>> И да, спешу вас огорчить, но любой компилятор использует ту или иную форму промежуточного представления, а не сходу компилирует "код в ассемблер".
> Ты правда думаешь что я этого не знаю?

Я не просто думаю - я в этом на 100% уверен, ибо ваш первый комментарий тому абсолютное подтверждение.

> Я как бы учился в ВУЗе еще в те стародавние времена, когда написание своего примитивного Си-компилятора это была просто лабораторная работа

Извините, но после драки кулаками не машут. В следующий раз пишите это пафосное заявление ДО того, как петь про "компиляцию кода в ассемблер" и т.п.

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

272. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (91), 18-Июн-26, 12:51 
>Ты правда думаешь что я этого не знаю? Я как бы учился в ВУЗе еще в те стародавние времена, когда написание своего примитивного Си-компилятора это была просто лабораторная работа, а не что-то из ряда вон выходящее что аж на Хабре можно 10 статей написать.

Это не аргумент. Во-первых, написание компилятора, это немножко больше чем лабораторная работа. Тот факт, что вы этого не знаете, говорит о том, что либо вы его писали не с нуля или не до конца, что крайне маловероятно, либо то, что вы этот аргумент на ходу выдумали. Во-вторых, десяток другой статей, посвящённых компилятору, это как раз правильный объём, чтобы человек понимал как сделать правильно, и почему.

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

262. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Совершенно другой аноним (?), 18-Июн-26, 11:43 
> Причем баге, выловленном именно благодаря средствам безопасности в Расте

почитайте внимательней, эту ошибку обнаружили до того, и не благодаря средствам безопасности в Расте (https://fgiesen.wordpress.com/2025/05/21/oodle-2-9-14-and-in.../).

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

287. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 18-Июн-26, 15:31 
>> Причем баге, выловленном именно благодаря средствам безопасности в Расте
> почитайте внимательней, эту ошибку обнаружили до того, и не благодаря средствам безопасности в Расте

В Firefox этот баг обнаружили именно тогда, когда обнаружили - и именно благодаря проверке Раста.

При чем здесь то, как и когда с ней столкнулись в коде Unreal?

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

291. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Совершенно другой аноним (?), 18-Июн-26, 16:30 
>>> Причем баге, выловленном именно благодаря средствам безопасности в Расте
>> почитайте внимательней, эту ошибку обнаружили до того, и не благодаря средствам безопасности в Расте
> В Firefox этот баг обнаружили именно тогда, когда обнаружили - и именно
> благодаря проверке Раста.

ещё раз перечитайте текст исходный текст комментария. Если это так, как Вы говорите, то он вообще не имеет смысла, т.к. получается, что багу который проявлялся на коде на Расте обнаружили благодаря Расту. А на чём должны были?

Плюс, надеюсь, что Вы понимаете, что в данном случае это случайность, если-бы значения CH и CL, например, не сильно различались по значению, то и вряд-ли это смогли обнаружить.

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

301. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (245), 18-Июн-26, 20:48 
> ещё раз перечитайте текст исходный текст комментария. Если это так, как Вы говорите, то он вообще не имеет смысла, т.к. получается, что багу который проявлялся на коде на Расте обнаружили благодаря Расту. А на чём должны были?

Исходный комментарий имеет смысл, если ты бы не выравал его из контекста, а увидел, что он писался в ответ на конкретное утверждение:

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

...на что и был ответ, что РАСТОВОМ коде благодаря РАСТУ выловился тот самый баг.

В ответ на это ты всплываешь со ссылкой на баг в левом C++ проекте и искренне не понимаешь, при чем тут Раст. Я извиняюсь, с тобой там все хорошо?

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

306. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 21:09 
В левом С проекте это нашли сильно раньше, успели запатчить, написать статью, пообщатся с вендором (интелом), и наверное уже забыли про это.
И тут растовщики такие расчехлились и открыли америку, в 2026 году.
Ответить | Правка | Наверх | Cообщить модератору

311. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 18-Июн-26, 21:29 
> И тут растовщики такие расчехлились и открыли америку, в 2026 году.

Когда растовый zlib внедрили - тогда и нашли. Об это в новости написано, не?

Или ты вообще не соображаешь, что у FF и Unreal разный код?

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

325. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 23:32 
Ошибку в проце нашли раньше и не благодаря расту.
Растбои повторили героический подвиг только спустя год.
Ответить | Правка | Наверх | Cообщить модератору

339. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (245), 19-Июн-26, 03:29 
> Ошибку в проце нашли раньше и не благодаря расту.
> Растбои повторили героический подвиг только спустя год.

А как, по твоему, в FF ее могли найти ДО того, как внедрился код, при котором эта ошибка в CPU выстреливала? Раскрой свою мысль, пожалуйста.

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

363. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 19-Июн-26, 16:20 
Капец ты.
В фф не было ошибки с оригинальным zlib, и когда они нашли - они откатились на оригинал.

В чём вообще суть твоего вопроса?
В том что в ФФ должны искать ошибки в процах вместо того чтобы делать браузер?

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

45. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –2 +/
Сообщение от King_Carloemail (ok), 17-Июн-26, 14:15 
Intel уже давно негодный эмулятор процессоров AMD. Интел покупают только люди глубоко не сведущие, введённые в заблуждение алчными продавцами.
Ответить | Правка | Наверх | Cообщить модератору

54. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (365), 17-Июн-26, 14:27 
Следите за новостями про железо, вот например тесты 250K Plus:
https://3dnews.ru/1142277/
Ответить | Правка | Наверх | Cообщить модератору

93. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от аноним12345 (?), 17-Июн-26, 15:30 
270k жрёт в 2 раза больше Ryzen 9700x, а попугаев сверху только десятки %.
Ответить | Правка | Наверх | Cообщить модератору

105. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (365), 17-Июн-26, 15:54 
Так это вы ещё новый 9950X3D2 не видели:
https://3dnews.ru/1143504/
Ответить | Правка | Наверх | Cообщить модератору

165. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (165), 17-Июн-26, 18:49 
Ты цену его погляди для начала. Зачем на него смотреть? Процессоры не для этого.
Ответить | Правка | Наверх | Cообщить модератору

169. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (365), 17-Июн-26, 19:21 
Да нет, это к вопросу, что там жалуется на 270K Plus, а 9950X3D2 жрёт ещё больше и ничего им нравится.
Ответить | Правка | Наверх | Cообщить модератору

166. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –2 +/
Сообщение от Аноним (165), 17-Июн-26, 18:53 
У тебя тоже непонимание происходящего. Красные камни просто разогнаны, а синие в большинстве задач без AVX512 работают далеко не на пределе, а контроль напряжений и андервольт надо к ним применять, чего псевдотехноблоггеры не освоили и орут какие процессоры печки. И тридэ нюхи тоже неосиляторы на самом деле. Они в тестах кастомную водянку суют и фиксом максимум балуются. Напряжения для них слишком сложны оказались. Вот тут подробно про андервольт для тех у кого все в голове в кашу превратилось из-за неосиляторов.

https://rutube.ru/video/260ba74f43ced776f527315231094d5d/

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

231. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 00:20 
> Красные камни просто разогнаны, а синие в большинстве задач без AVX512 работают далеко не на пределе, а контроль напряжений и андервольт надо к ним применять, чего псевдотехноблоггеры не освоили и орут какие процессоры печки.

А вот если бы...

На самом деле всё сильно зависит от методики измерения.
Лично я против турбобубсов, и за то чтобы мерить на фиксированных базовых частотах да ещё и андервольтинг делать. Но так никто не делает - не заплят ибо цифры будут как 5 лет назад, и перестанут давать новые процы на погонять. А фанбои завалят навозом ибо: "любимку унижают, она может в хххххх раз быстрее!!!".

Так то, процы что интел что амд нынче примерно равны по производительности на Ватт, и меня лично больше интереуют другие потребительские характеристики:
- как долго живёт платформа
- какие доп фичи есть в проце (особенно на старте АМ4 когда туда навалили и ядер и ECC)
- как часто оно ломается

AVX512 интел обещало в потребительских процах ещё году в 2015-2016. И я про обычные процы не те топ-про-премиу-мега-утра-супер сегмент за чемоданы денег. Сейчас 2026 год и AVX512 ещё только заходит в софт типа кодеков и прочего.

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

239. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (365), 18-Июн-26, 01:36 
>AVX512 интел обещало в потребительских процах ещё году в 2015-2016.

Вот уж не знаю кто вам, что обещал, но AVX-512 у Интела появился задолго до появления в АМД.
И в потребительских тоже был, и в десктопных Rocket Lake и в ноутбучных Tiger Lake, Ice Lake:
https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#AVX...

В Nova Lake перейдут на AVX10.2

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

289. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 16:26 
Вы сами то ту табличку видели?
Intel Cannon Lake (2018) - какой то кастрированный набор.
Это спустя год после того как амд выпустило свои процы где было тупо ядер/потоков в 2-4 раза больше за теже деньги.

А обещал этот самый AVX-512 интел давно, и скорее всего и 2018 его бы отрезали, если бы не приспичло хоть что то противопоставлять амд.

Интел теперь может переходить куда угодно, это всё малоинтересно.

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

379. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Tron is Whistling (?), 27-Июн-26, 00:03 
Прикол знаешь в чём? У синих десктопных камней вообще больше нет аппаратного AVX512.
Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

141. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 17-Июн-26, 17:20 
Даром нинада: потом материнку фиг найдёшь через 5 лет к нему.
И топ за свои деньги - такое себе, жене вон 2300U хватает с запасом, зачем ей бы такой проц?
Мне 5950х тоже большую часть времени занять нечем, читай 99% времени он деньги не отрабатывает :)
Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

144. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (365), 17-Июн-26, 17:33 
>потом материнку фиг найдёшь через 5 лет к нему

А вы сначала покупаете процессор, а через 5 лет материнку к нему ?
p.s.:
Даже на 775 сейчас можно купить новую материнку.

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

221. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 17-Июн-26, 23:46 
775 как и 370 - это "старые добрые", да и то весьма относительно, учитывая что у 370 специально ломали совместимость чтобы новый проц на старых матерях не стартовал. Но если приложить руки с паяльником то стартовал и прекрасно работал.
А в 775 тоже было примерно 3 поколения на одном сокете, первое уже все как то забыли на 9хх чипсетах, где коредубы не заводились. Но иногда удавалось завести перепрошивкой бивиса. А оставшиеся 2 на 3х, 4х (5х?) уже были совместимы между собой.

Вы попробуйте найти матери которые после 775 сокета были.
А вот для АМ4 спустя 10 лет после выхода продаются НОВЫЕ процы и матери.
К 2016-2017 году для интела 775 был давно сгнившим трупом.

И таки да, я иногда покупаю спустя 5 лет и процы и материнки.
Вот в 2023 купил 5950х и кажется 1 или 2 5750G, а материнки к ним были куплены если правильно помню в 2020-2021 годах, хотя они прекрасно будут работать и на тех матерях что я покупал в 2018-2019 годах.
Я бы и сейчас не отказался взять за не дорого что то топовое под ам4, но честн говоря пока хватает того что есть :)

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

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

259. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от фняк. (?), 18-Июн-26, 11:05 
Новую в смысле пролежавшую на складе 15+ лет?
Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

261. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (261), 18-Июн-26, 11:28 
> Новую в смысле пролежавшую на складе 15+ лет?

Думаю китайцы до сих пор выпускают какие-то копии 775.
Типа как переходники на процессоры, материнки ddr3 + ddr4, всякие ксеоны и тд.

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

280. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (365), 18-Июн-26, 13:44 
GIGABYTE GA-G41M-Combo
https://www.dns-shop.ru/product/ab821385234eed20/materinskaa.../
Ответить | Правка | К родителю #259 | Наверх | Cообщить модератору

380. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Tron is Whistling (?), 27-Июн-26, 00:05 
Вот да. 5950X есть чем занять далеко не всегда. Поэтому линейку с DDR5 можно лениво пропустить - она ущербная вся. У штеуда баг на баге, амд роняет частоты на AVX512 (но оно хотя бы есть), память глючнобитая уже с завода и без внутреннего ECC не работает, и т.п.
Ответить | Правка | К родителю #141 | Наверх | Cообщить модератору

71. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –4 +/
Сообщение от Аноним (57), 17-Июн-26, 14:48 
то есть амд, которая создана на деньги интел это молодцы, а интел это фуфуфу, тоесть то что амд подарили технологию и архитектуру и это одно и тоже, это пофиг, хейтить интел это особый вид психоза похоже, логика отсутсвует
Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

86. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (86), 17-Июн-26, 15:13 
"У вас ус отклеился".

Кто там кому и когда технологии внутреннего RISC-образного ядра передавал? А текущую 64битную архитектуру? Подложки для кристаллов, когда у Intel были форменные тормозные утюги по сравнению с? Фактически принудил к отказу от такого мощного решения, как RAMBUS?..

Не, там и обратное кросслицензирование идет во всю.

С укорителем процессов в лице местных антимонопольщиков в тяжелых случаях. :-)

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

52. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –2 +/
Сообщение от Аноним (53), 17-Июн-26, 14:26 
Что за бред, тогда бы проц совсем не работал.
Ответить | Правка | Наверх | Cообщить модератору

66. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (86), 17-Июн-26, 14:44 
С очевидностью: очень сильно не все используют совместимость "64-с-32-с-16-с-8 бит" и адресацию восьмибитных регистров.

Как-то масками и сдвигами обходятся.

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

260. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от фняк. (?), 18-Июн-26, 11:06 
Да вы что? А как по вашему мнениюэти сильно не все пишут по-байтово в память?
Ответить | Правка | Наверх | Cообщить модератору

278. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (278), 18-Июн-26, 13:38 
Примерно никто, если речь про ОЗУ.

Пословно, постранично, еще и в несколько каналов.

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

315. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от snvoronkov (ok), 18-Июн-26, 22:07 
Почитайте Таненбаума.

На уровне CPU реально нигде не делается. В микроконтроллерах есть побайтовая адресация и в/в, но в топике речь не про них.

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

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

176. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Скотобаза (?), 17-Июн-26, 19:58 
Ну видимо редко эмитируемая инструкция. У интелоидов кстати это не первый косяк с 8битными регистрами.

Интересно как же через жеппу у них декодеры сделаны если там есть такие косяки. Я просто сам проц разрабатываю и сделал свой набор команд в который 99% команд х86 транслируются байт в байт. Там такое невозможно потому что микрокода нет в принципе. Смотрел описание коры7, и вроде там есть быстрые декодеры и декодеры микрокода для всего не быстрого. Быстрый декодер просто копирует и пересовывает биты. Подозреваю что дело в SIB, быстрый декодер не может выдать больше одной микроинструкции. А тут SIB то есть сложение добавляется. А работало все потому что компиляторы оптимизируют под использование простых инструкций где только можно

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

378. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Tron is Whistling (?), 26-Июн-26, 23:44 
Да нет, скорее всего косяк где-то в переименовании регистров, оно достаточно сложное.
Тем не менее.
Ответить | Правка | Наверх | Cообщить модератору

64. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от a2yemail (?), 17-Июн-26, 14:41 
Как это меня умиляет.
Ошибка железа, но как всегда виноваты программисты :-)
Ответить | Правка | Наверх | Cообщить модератору

68. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (365), 17-Июн-26, 14:46 
Да тут на самом деле до конца не понятно т.к. это бы всплывало везде, а Raptor Lake появился осенью 2022.
Плюс:
>Генерация проблемной инструкции замечена в LLVM 22 (в находящейся в разработке ветке LLVM 23 она не генерируется)
Ответить | Правка | Наверх | Cообщить модератору

72. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (72), 17-Июн-26, 14:48 
Угадай, кто написал программу для железа.
Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

197. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от a2yemail (?), 17-Июн-26, 21:31 
Угадал. Но это не отменяет того, что при переносе кода на кремний, именно на кремнии была допущена ошибка
Ответить | Правка | Наверх | Cообщить модератору

70. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (70), 17-Июн-26, 14:47 
Ох уж эти кратно возросшие скорости в старых библиотеках... Ждем ZIP-bomb, path overwrite в реализации или что-то такое.
Ответить | Правка | Наверх | Cообщить модератору

77. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Tron is Whistling (?), 17-Июн-26, 15:00 
mov [reg+reg+imm],ch писал cl?
Красиво. Процы у штеуда вообще ногами деланы. Мысль не связываться с таковыми года с 2005 так была верной.
Ответить | Правка | Наверх | Cообщить модератору

79. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –3 +/
Сообщение от Аноним (365), 17-Июн-26, 15:03 
На что перешли, на Эльбрусы ? Потому, что на АМД ситуация ничем не лучше:
https://www.opennet.ru/keywords/amd.html
Ответить | Правка | Наверх | Cообщить модератору

87. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (48), 17-Июн-26, 15:14 
Да в амуде аналогичные баги. Скринь этот твит, скоро будет похожая новость про них. А не, уже были и до сих пор есть (но ты о них пока не знаешь) - https://www.opennet.ru/opennews/art.shtml?num=33278
Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

161. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Tron is Whistling (?), 17-Июн-26, 18:25 
Далеко не аналогичные - сложность не та совершенно.
Да и аналогов meltdown так и не нашлось.
Ответить | Правка | Наверх | Cообщить модератору

247. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (236), 18-Июн-26, 02:22 
> Ошибка проявлялась примерно раз в два дня только на полностью загруженном 48 ядерном сервере

Странное сравнение со 100% ошибкой простого мувика.

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

309. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 18-Июн-26, 21:14 
Честно говоря до райзенов производительность на Ватт у амд была так себе.
Для маложручих процов - конкурентов атома во всяких mATX это было норм за счёт расширенной переферии, а х2 потребление там не заметно.
А для десктопа было как то грустно.
Я периодически (раз в пару лет) пробовал АМД и каждый раз было как то не очень.
Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

381. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Tron is Whistling (?), 27-Июн-26, 00:08 
Яхз, после PIII все процы были AMD. Особых нареканий нет.
Да, кипятильники были ещё те, и FPU всегда был откровенно слабым (правда конкретно в моих задачах - и на фиг не нужным), но с линейкой Ryzen всё изменилось.
Ответить | Правка | Наверх | Cообщить модератору

78. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (78), 17-Июн-26, 15:02 
> переход с zlib на zlib-rs привёл к заметному повышению производительности - в проведённых тестах ускорение составило от 3.3 до 32.5 раз при единичных операция декодирования и от 2.7 до 10.86 раз при декодировании непрерывного потока.

Аж системдой пахнуло! "С системдой теперь загрузка 2 секунды! У кого нет системды, тот башпортной!"

Скоро будем наблюдать в-crate-й бисер crate-й, навайбслопенный п-rust-офилями.

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

84. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +2 +/
Сообщение от Аноним (84), 17-Июн-26, 15:09 
> Аж системдой пахнуло! "С системдой теперь загрузка 2 секунды! У кого нет  системды, тот башпортной!"

Не знаю чем у тебя там пахнуло, может тебе просто стоит помыться.

> Скоро будем наблюдать в-crate-й бисер crate-й, навайбслопенный п-rust-офилями.

Ну пока вайбкодеры утирают сопли дидам которые то ли Copy Fail'ы, то ли Dirty Fag'и.

ps а по поводу тестов и ускорения, у тебя надеюсь есть опровержения?
или ты просто навалил кучу в комменты без каких-то доказательств?

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

137. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (123), 17-Июн-26, 17:09 
Статью их открой и почитай, что с чем сравнивали. Взяли кодовую базу zlib-ng, навайбкодили её а расте (причём с приколами типа "мы переписывали-переписывали, пока компилятор нужные инструкции не выдал, а под какими флагами он выдаёт ненужные инструкции мы вам не скажем") и сравнивают теперь с проектом, который судя по таймингам скомпилировали с -O1 -gddb, который скомпилировали... а на чём они скомпилировали то классический zlib?
Ответить | Правка | Наверх | Cообщить модератору

196. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (193), 17-Июн-26, 21:28 
> а на чём они скомпилировали то классический zlib?

На Clang, у которого под капотом тот же LLVM, что и Rust. Азазазаза!

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

204. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (123), 17-Июн-26, 21:48 
Пробовали на gcc скомпилировать?
Ответить | Правка | Наверх | Cообщить модератору

216. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (216), 17-Июн-26, 23:02 
> Ну пока вайбкодеры утирают сопли дидам

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

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

83. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +2 +/
Сообщение от ктото (?), 17-Июн-26, 15:09 
растеры переписывают всё на пермиссивные лицензии. идёт атака на GPL.

под предлогом скорости и безопасности, крышеватели раста и llvm атакуют Сталлмана!

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

124. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (124), 17-Июн-26, 16:45 
>под предлогом скорости и безопасности, крышеватели раста и llvm атакуют Сталлмана!

GNU это знает. Нас им не победить. Потому-что мы непобедимые.

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

140. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (129), 17-Июн-26, 17:18 
> растеры переписывают всё на пермиссивные лицензии.

Вот и отлично - код становится свободным, а не запретительным.

> идёт атака на GPL.

Сомнительно. GPL и так уже подыхает.

> под предлогом скорости и безопасности,

Судя по новости это не "предлог".
Тут и скорости добавили, и ошибку в проце нашли.

> крышеватели раста и llvm

Т.е примерно те же кто разрабатывает ядро линукс.

> атакуют Сталлмана!

А чего атаковать этого латентного п-фила?
Он уже отработанный ресурс, старый и никому не нужный.

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

162. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (162), 17-Июн-26, 18:26 
>Вот и отлично - код становится свободным, а не запретительным.

Раз начал говорить договаривай до конца. Код стал свободным для манипуляций со стороны корпорастов и проприетарщиков. А копилефт сразу дал бы им больно по рукам.

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

257. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (257), 18-Июн-26, 08:25 
GPL никак не мешает пользователям, только корпорациям
Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

258. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (258), 18-Июн-26, 10:18 
Программист который хочет использовать код в свободном проекте.
Но раковая лицензия ему не позволяет...

И нет, речь не про корпораций, а про драйвера Tuxedo.
Написанные по глупости под ЖПЛ-3 и теперь не совместимые с ядром линукс.

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

344. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (123), 19-Июн-26, 08:35 
> про драйвера Tuxedo.

Написанные по глупости под ЖПЛ-3 и теперь не совместимые с ядром линукс.

Бред. Ничто не мешает дистрибутиву пропатчить ядро GPL3 патчем, пока юзеру дают все исходники. Баш существует под ведроидом, хотя там абсолютно всё переписано гулагелом и нихера работать не будет без пропатченного гуглом/самсунгом/квалкомом ядра.

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

121. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от Аноним (124), 17-Июн-26, 16:43 
А ха-ха! Не зря Линус перешёл на компьютер с процессором AMD. Чувствовал видимо что-то неладное. Американский брак монополиста стал заметен.
Ответить | Правка | Наверх | Cообщить модератору

139. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 17-Июн-26, 17:16 
Всё просто: интел жмотился а АМД раздавал ядра, кучу памяти, ECC по ценам даже ниже интела без всего этого.
Выбор для делающих его головой был очевиден.
Ответить | Правка | Наверх | Cообщить модератору

148. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (365), 17-Июн-26, 17:45 
>а АМД раздавал

https://www.tomshardware.com/pc-components/cpus/amd-silently...

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

222. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ivan_83 (ok), 17-Июн-26, 23:49 
А я ничего про шифрование памяти не писал, мне эта фича не очень нужна, мягко говоря.
Вот ECC надо.
Ответить | Правка | Наверх | Cообщить модератору

256. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (257), 18-Июн-26, 08:23 
Я же фин теперь авторитет в этом вопросе. Он еще на видюху интел перешел, налетай
Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

263. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (263), 18-Июн-26, 11:43 
>Он еще на видюху интел перешел, налетай

Врешь, не переходил он на видюху. Просто снялся у ютуб-блогера.

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

134. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (123), 17-Июн-26, 17:04 
> We change the algorithms that are used at the different compression levels (in a way that is consistent with zlib-ng, but inconsistent with stock zlib), so the exact output bytes and output length can change slightly.
> The Firefox test suite tested for the exact output bytes in some cases, and for the (rough) output length in more. This is a good fail safe against messing up the compression configuration, but now these tests all needed to be updated.

Т.е. заменили zlib на zlib-ng, но навайбкодили на расте и сравнивают теперь с совсем другой кодовой базой как-будто это заслуга языка.

> To work around LLVM emitting this particular instruction, we use a tiny bit of unsafe code (LLVM is clever, so this was the simplest way we've found to have it generate the right thing):

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

Причём ниже же

> It turns out that LLVM 23 no longer emits the offending instruction, although I believe that is serendipitous and not deliberate. When we bump our MSRV to a version that requires LLVM 23 (e.g. for custom allocators and c-variadic functions) we can drop this workaround.

Т.е. фикс уже есть в новой версии компилятора, и нету никаких гарантий что старые версии компилятора (а не те, которые были у разрабов в данный момент установлены) выдают ломающуюся в интуле инструкцию. Но код уже переписали, чё коммитам пропадать.

И умозаключение

> So why go through all of this trouble? Because zlib-rs is faster. Much faster. Especially on linux x86_64 the speedup is almost silly. These benchmarks from zlib-py compare stock zlib versus zlib-rs:

Опять же, сравнили жопу с пальцем и радуются.

> Compression is also faster, but harder to compare because the difference in compression ratio.

Say no more

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

135. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –2 +/
Сообщение от Аноним (135), 17-Июн-26, 17:04 
Надо переписать на JavaScript потому он асинхронный а значит очень быстрый, самый быстрый и никогда не блокируется. Кроме того в JavaScript революционная реализация ООП. А ещё много людей знают JavaScript поэтому всегда найдутся те кто сможет подхватить разработку.
Ответить | Правка | Наверх | Cообщить модератору

150. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +2 +/
Сообщение от Аноним (150), 17-Июн-26, 17:52 
Сплошные баги ... в Firefox'е, в Rust'е ... в LLVM ... Intel-процессор ... остановите поезд, я сойду.  То есть не  надо использовать эту связку
Firefox-Rust-LLVM-Intel
Ответить | Правка | Наверх | Cообщить модератору

244. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (236), 18-Июн-26, 02:15 
в GCC таких проблем нету.
Ответить | Правка | Наверх | Cообщить модератору

192. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от fidoman (ok), 17-Июн-26, 21:22 
Зачем такие инструкции использовать? Это же чтение из памяти слова и потом запись обратно (хорошо если оно в кэше, но кэш тоже не бесконечный). Неужели нет варианта накопить полный регистр и сразу скинуть.
Ответить | Правка | Наверх | Cообщить модератору

350. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (350), 19-Июн-26, 15:42 
> Это же чтение из памяти слова и потом запись обратно

Это легко сказать. Чтобы читать 32 бита из памяти эффективно надо чтоб адрес выравнен был на 4 байта, то есть надо сначала прочитать до трёх байт по байту/по два. И потом ещё "хвост" так же дочитать. То есть, всё придётся иметь код, который читает по байту, а значит и шансы наступить на грабли с этим movb %ch, чтототам.

> хорошо если оно в кэше

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

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

209. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  –1 +/
Сообщение от zionist (ok), 17-Июн-26, 22:09 
Ну а исправление в микрокоде будет/было или что?
Ответить | Правка | Наверх | Cообщить модератору

211. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +1 +/
Сообщение от Аноним (365), 17-Июн-26, 22:17 
Да скорее всего было исправлено и всплывает у тех, кто не обновлял биос.
Доля Raptor Lake заметная: https://data.firefox.com/dashboard/hardware
Ответить | Правка | Наверх | Cообщить модератору

235. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (123), 18-Июн-26, 00:28 
Микрокод подгружается даже на том этапе, когда операционка читает файловую систему и видит файлик intel-ucode.img в efi разделе. Причём тут биос?
Ответить | Правка | Наверх | Cообщить модератору

237. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (365), 18-Июн-26, 01:17 
>Причём тут биос

А обновления микрокода откуда будут ?
https://ru.msi.com/Motherboard/PRO-Z790-A-MAX-WIFI/support

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

243. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от zionist (ok), 18-Июн-26, 02:08 
Нормальный дистрибутив Linux так же умеет загружать обновлённый микрокод процессора. BIOS - далеко не единственный вариант.
Ответить | Правка | Наверх | Cообщить модератору

252. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Ю.Т. (?), 18-Июн-26, 07:28 
"И не успел ещё выехать из автомагазина, как сэкономленный бензин стал выливаться из бензобака".
Ответить | Правка | Наверх | Cообщить модератору

255. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (257), 18-Июн-26, 08:20 
12я серия была последней нормальной у intel
Ответить | Правка | Наверх | Cообщить модератору

270. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от pic (??), 18-Июн-26, 12:49 
А ещё для версий iOS в браузер добавляется _встроенный_ блокировщик рекламы. Расширения постепенно вытесняют.
Ответить | Правка | Наверх | Cообщить модератору

271. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от pic (??), 18-Июн-26, 12:51 
>...Несмотря на эти нововведения и выход версии Firefox 152, доля компании на десктопном рынке упала с 5,88 % в мае 2025 года до 3,79 % в мае 2026 года по данным Statcounter.

Ну что ж.

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

348. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от MSN (-), 19-Июн-26, 12:08 
Всего-лишь год спустя...
https://www.msn.com/en-us/news/technology/after-a-year-firef...
Ответить | Правка | Наверх | Cообщить модератору

368. "При переводе Firefox на zlib-rs разработчики натолкнулись на..."  +/
Сообщение от Аноним (368), 19-Июн-26, 18:43 
>к незаметному повреждению данных

Контрольные суммы такие "ну да, пошли мы на хутор"

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

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

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




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

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