The OpenNET Project / Index page

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



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

Оглавление

70% проблем с безопасностью в Chromium вызваны ошибками при ..., opennews (ok), 24-Май-20, (0) [смотреть все]

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


176. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  –1 +/
Сообщение от FixingGunsInAiremail (ok), 24-Май-20, 20:32 
4 слова: С++ in a nutshell

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

Даже в CLR, если бы на нём написали движок, было бы меньше дыр.

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

218. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/
Сообщение от Аноним (222), 24-Май-20, 21:09 
шарпик в unsafe позволяет долбится в указатели не хуже крестов
Ответить | Правка | Наверх | Cообщить модератору

221. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/
Сообщение от FixingGunsInAiremail (ok), 24-Май-20, 21:17 
> шарпик в unsafe позволяет долбится в указатели не хуже крестов

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

Реализовав банальный IDispose нормально, можно большинство таких проблем избежать.

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

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

227. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  –1 +/
Сообщение от Аноним (222), 24-Май-20, 21:26 
Так и я про это же, что не нужно превращать шапр в кресты, если есть кресты, у шарпа своя огромная ниша
Ответить | Правка | Наверх | Cообщить модератору

407. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/
Сообщение от коржик (?), 25-Май-20, 18:32 
n лет пишу под дотнет, ни разу в unsafe не вляпался. Ни разу не напоролся на UB, разве что только численное переполнение и многопоточка. Но это другая история.

Вот сейчас сижу и думаю, как люди вообще живут с UB. Какие нервы нужно иметь чтобы бороться с ним.

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

413. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/
Сообщение от FixingGunsInAiremail (ok), 25-Май-20, 20:15 
Вы так говорите, словно, если представить сферическую реализацию движка в вакууме на C#, без unsafe в более чем половине классов, этого сделать нельзя.
Ответить | Правка | К родителю #227 | Наверх | Cообщить модератору

375. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +/
Сообщение от Аноним (375), 25-Май-20, 11:37 
А класс Marhall тебе зачем, тогда?
Ответить | Правка | К родителю #221 | Наверх | Cообщить модератору

265. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +/
Сообщение от Аноним (243), 24-Май-20, 22:31 
Как будто в Rust нет unsafe.
Ответить | Правка | К родителю #218 | Наверх | Cообщить модератору

283. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  –1 +/
Сообщение от JL2001 (ok), 24-Май-20, 23:08 
> Как будто в Rust нет unsafe.

в Java тоже есть и в C# - только все прикладники и весь энтерпрайз его в жизни не встречал, и в rust так же будет

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

287. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/
Сообщение от Аноним (222), 24-Май-20, 23:12 
ну так товарищ выше не шарит шо есть низкоуровневые либы которые пишутся на сях и крестах, а есть высокоуровневые ЯП которые их юзают через стандартные обвязки, иначе говоря прикладник практически никогда не будет копаться в кишках либ, а только их юзать
Ответить | Правка | Наверх | Cообщить модератору

282. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  –1 +/
Сообщение от Аноним (282), 24-Май-20, 23:07 
А че хаять ручное управление памятью? При нем хотя бы высвобождение аллоцированного в хипе участка детерминировано, в отличие от "сборки мусора". У C++ прописана в стандарте memory model и выработана куча бестпрактисов, как работать с ним так, чтобы не подрываться каждые 5 минут. Если выработана привычка работать с ресурсами через RAII и набита рука на смартпоинтерах, то все не так плохо, как тут пишут. Уж точно лучше, чем ситуация на работе, когда Teamcity CI после суток аптайма мог уйти в denial of service на 15-20 минут в разгар рабочего дня. Спрашиваем у дево псов, че такое, отвечают что у JVM GC случится stop-the-world, чет-то там собирает, ждите. Тьфу. А если говорить про Rust, то бесспорно, у него есть 2 ништяка - это borrow checker и named lifetimes, но memory model стандартизированной пока нет, что плохо. Да и работу пока найти сложно на нём. Но очевидно, что еще лет через 5-10, при наличии полноценной спеки, его будут требовать знать в каждой подворотне, где пишут что-то околосистемное. Уж больно круто, когда zero-cost abstractions действительно такие и большинство вещей можно поймать в compile-time.
Ответить | Правка | К родителю #176 | Наверх | Cообщить модератору

293. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  –1 +/
Сообщение от Аноним (222), 24-Май-20, 23:33 
Просто растоманы не понимают, что для каждой сферы свой инструмент... Нужно тебе постоянно общаться с си-кодом напрямую без магических unsafe бери C++, хочешь писать быстро и выдавать производительный код бери Java/C#, хочешь писать еще быстрее, но более медленный код, бери пистон или пых(МИНЗДРАВ НЕ РЕКОМЕНДУЕТ), хочешь писать скрипты для линух бери bash, но ни как не C++, а если тебе нужно таблички почекать бери awk
Ответить | Правка | Наверх | Cообщить модератору

422. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +/
Сообщение от Аноним (340), 26-Май-20, 08:51 
и получается 100500 зависимостей по библиотекам, которые, по сути, детают одно и тоже.
Ответить | Правка | Наверх | Cообщить модератору

299. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +/
Сообщение от JL2001 (ok), 24-Май-20, 23:43 
> Уж точно лучше,
> чем ситуация на работе, когда Teamcity CI после суток аптайма мог
> уйти в denial of service на 15-20 минут в разгар рабочего
> дня. Спрашиваем у дево псов, че такое, отвечают что у JVM
> GC случится stop-the-world, чет-то там собирает, ждите.

чёт мне подсказывает, что ваши девопсы вам напиз^w обманули

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

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

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

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




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

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