The OpenNET Project / Index page

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

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


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

Оглавление

Уязвимости в ядре Linux, позволяющие поднять свои привилегии через nf_tables и ksmbd, opennews (??), 27-Мрт-24, (0) [смотреть все]

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


57. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +2 +/–
Сообщение от ProfessorNavigator (ok), 27-Мрт-24, 13:39 
Чем дольше живу, тем более странным мне кажется отказ от использования С++ в ядре. Я не знаю, что там было, когда всё это начиналось. Вполне возможно, что существовали веские причины. Но сейчас, по крайней мере с технической точки зрения, всё это выглядит, мягко говоря, глупо. С++ позволяет многое делать в разы проще (для программиста). При этом, там где нужно написать что-то в условном С стиле - никаких проблем. Опять же есть ассемблерные вставки. Но вместо С++ зачем-то начали пихать Rust. Который якобы позволяет избегать ошибок с памятью. Хотя С++ позволяет делать ровно тоже самое, при правильном использовании. Одновременно оставляя возможность работать на более "низком уровне". Причём, с Rust ещё и лицензионные заморочки могу возникнуть, насколько я понимаю.
Ответить | Правка | Наверх | Cообщить модератору

59. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +2 +/–
Сообщение от Аноним (-), 27-Мрт-24, 13:45 
> Я не знаю, что там было, когда всё это начиналось. Вполне возможно, что существовали веские причины.

А поискал бы лучше. Там был убогий "си с классами".
Который никаких плюсов (бадумтц) не давал, но добавлял нехилый оверхед в те темные времена первопней.

> Хотя С++ позволяет делать ровно тоже самое, ...

Нет, нельзя. С++ лучше по memory management чем си, но до раста ему топать и топать.
В плюсах то что раст рассчитывает во время компиляции переносится в рантайм, а то что раст проверяет в рантайме в плюсах и так там живет.

> ... при правильном использовании.

А это вторая (или может быть даже первая?) проблема.
Ты можешь использовать плюсы неправильно... и тебе за это ничего не будет.
Ну может ворнинг вылезет.

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

64. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от ProfessorNavigator (ok), 27-Мрт-24, 14:09 
> А поискал бы лучше. Там был убогий "си с классами".

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

> В плюсах то что раст рассчитывает во время компиляции переносится в рантайм,
> а то что раст проверяет в рантайме в плюсах и так
> там живет.

Ну во-первых, лично мне например и нужно, чтобы это было в рантайме, т.е. под моим, как программиста, контролем. Во-вторых, по итогу всё преобразуется в одни и те же машинные инструкции. При этом в случае с Rust - это дольше в разы, а выигрыш весьма сомнительный. В том плане, что его позиционируют, как более безопасный. Но на поверку - это лишь маркетинговая уловка. Потому что можно или самому код соответствующим образом писать, или добавить дополнительный модуль к компилятору того же С++, с ровно теми же функциями. Сделав при этом его опциональным. Однако вместо этого видим пропихивание Rust. С его мутными лицензионными ограничениями. Не говоря уж о том, что для того же С++ существуют международные стандарты. Которые до некоторой степени гарантируют, что программа будет вести себя +/- одинаково при использовании разных компиляторов. Или при компиляции для разных архитектур.

> А это вторая (или может быть даже первая?) проблема.
> Ты можешь использовать плюсы неправильно... и тебе за это ничего не будет.
> Ну может ворнинг вылезет.

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

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

72. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +3 +/–
Сообщение от Аноним (-), 27-Мрт-24, 14:27 
> Важно то, что имеем сегодня.

А сегодня мы имеем монстроспеку на 2к+ страниц))

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

И жрет лишние время проца и оперативу.

> При этом в случае с Rust - это дольше в разы, а выигрыш весьма сомнительный.

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

> Но на поверку - это лишь маркетинговая уловка.

Голословное утверждение без пруфов которое подается как факт.
Всё как я и люблю на опеннете))

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

Но таких модулей еще нет. Вот когда появятся, тогда и поговорим.

> Сделав при этом его опциональным

И все будут его отключать потому что "а чаво оно ругается!"

> С его мутными лицензионными ограничениями.

Пруфы в студию. Уже второй раз пишешь про это.

> программа будет вести себя +/- одинаково при использовании разных компиляторов

Ахаха)) Ваши +/- это +/- километр.
А потом люди спрашивают в интернетах "почему один и тот же код посла gcc и clang выдает различный результат"
А потому что стандарт овно.
"для того же С++ существуют международные стандарты" - и что, помогли они тебе?))

А у раста один компилятор. Который гарантировано будет работать как... как он сам. Круто же?))

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

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

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

И решения тут условно два - или упрощать софт (что малореально), или автоматизировать валидации.

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

82. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  –1 +/–
Сообщение от ProfessorNavigator (ok), 27-Мрт-24, 15:21 
> А сегодня мы имеем монстроспеку на 2к+ страниц))

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

> И жрет лишние время проца и оперативу.

А при использовании Rust не жрёт? Машинные инструкции в конечном итоге одни и те же. А то, что можно проверить при компиляции, и так проверяется.

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

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

> Голословное утверждение без пруфов которое подается как факт.
> Всё как я и люблю на опеннете))

Эм... Ну ладно)) "Гляжу в книгу - вижу фигу". Точнее то, что удобно. "Умные" указатели, вектора и тип std::array с их итераторами - нет не оно? Ну ладно.    

> Но таких модулей еще нет. Вот когда появятся, тогда и поговорим.

Их не "ещё" нет, а их просто нет. За ненадобностью. Были бы нужны - давно бы уже написали.

> И все будут его отключать потому что "а чаво оно ругается!"

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

> Пруфы в студию. Уже второй раз пишешь про это.

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

> Ахаха)) Ваши +/- это +/- километр.
> А потом люди спрашивают в интернетах "почему один и тот же код
> посла gcc и clang выдает различный результат"

А "пруфы" (пользуясь вашей же терминологией) будут?)) Впрочем, можете не приводить. И так понятно, что в 99% случаев использовали специфичные для компилятора вещи, а потом оказалось, сюрприз - они для другого компилятора не работают.

> А потому что стандарт овно.

Откровенный бред. Стандарты как раз нормальные (по крайней мере те, что я видел). Весь вопрос в реализации.
> "для того же С++ существуют международные стандарты" - и что, помогли они
> тебе?))

Ещё как, вы не поверите. Поэтому кое-какие мои программы например работают как под Linux, так и под Windows.

> А у раста один компилятор. Который гарантировано будет работать как... как он
> сам. Круто же?))

Ложь. Для Rust уже больше одного компилятора.

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

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

> И решения тут условно два - или упрощать софт (что малореально), или
> автоматизировать валидации.

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


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

88. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +1 +/–
Сообщение от Аноним (-), 27-Мрт-24, 16:17 
> Если хотите, чтобы всё было просто - добро пожаловать в каменный век.

Не передергивайте. Мы сравниваем потенциальные плюсы и минусы замены сишки на один из двух языков.
Мы как раз не хотим попасть в каменный век из-за одного залетевшего дятла.

> А при использовании Rust не жрёт? Машинные инструкции в конечном итоге одни и те же.

Нет, инструкции разные. Просто чтобы добиться эквивалентного кода в с++ вы напр. должны присвоить переменной null  после освобождения памяти, чтобы потом не сделать double free.
А в расте эту проверку сделает компилятор, который гарантирует что вы не сделаете double free. И присваивание не потребуется. И так еще в куче мест.

> как уже написал выше - машинные инструкции везде одни и те же.

То что вы так написали выше совсем не значит что инструкции одни и те же))

> "Умные" указатели

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

> Впрочем, можете не приводить.

Ну чего же вы так! Мне не сложно привести примеры))
codeproject.com/Questions/5331052/Cplusplus-different-output-on-different-compilers
learn.microsoft.com/en-us/answers/questions/119430/different-results-in-different-compilers-c
stackoverflow.com/questions/5158014/why-do-different-c-compilers-give-different-results-for-this-code
qna.habr.com/q/1320980
ru.stackoverflow.com/questions/1508112/%D0%9F%D0%BE%D1%87%D0%B5%D0%BC%D1%83-%D1%80%D0%B5%D0%B7%D1%83%D0%BB%D1%8C%D1%82%D0%B0%D1%82-%D1%80%D0%B0%D0%B7%D0%BD%D1%8B%D0%B9-%D0%BF%D1%80%D0%B8-%D0%BE%D0%B4%D0%B8%D0%BD%D0%B0%D0%BA%D0%BE%D0%B2%D1%8B%D1%85-%D1%81%D1%82%D0%B0%D0%BD%D0%B4%D0%B0%D1%80%D1%82%D0%B0%D1%85-%D1%8F%D0%B7%D1%8B%D0%BA%D0%B0-%D0%A1
и тыщщи их

А всё потому, что в распрекрасный стандарт с++ напихали undefined behaviour и implementation defined behaviour. Что гарантировано стреляет на лобой маломальски большой программе.
Кроме того, погромисту нужно учить не только стандарт, но и все безумные реализации конкретных компиляторов.
Вот поэтому стандарт плохой.

> Для Rust уже больше одного компилятора.

Насколько я знаю - нет.
gccrs только разрабатывают и он еще не релизился.
mrustc еще не релизился и это не generic compiler, а просто чтобы бустрапит раста.
Ferrocene просто надстройка для rustc.

> Всё можно, было бы желание.

Значит у сишников нет желания?))

> любая автоматическая проверка тоже написана людьми.

Да, но проверка будет занимать напр. 1000 строк кода. И проверять сотни тысяч строк с одинаковым качеством.
А теперь посади погромиста вычитывать 100к сорцов. Посмеемся))

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

116. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  –1 +/–
Сообщение от ProfessorNavigator (ok), 27-Мрт-24, 17:13 
> Не передергивайте. Мы сравниваем потенциальные плюсы и минусы замены сишки на один
> из двух языков.
> Мы как раз не хотим попасть в каменный век из-за одного залетевшего
> дятла.

Так не я передёргиваю, а вы. Речь шла о том, что в С++ большой объём документации. Или я вас неправильно понял? Тогда - поясняйте, что имеете ввиду.

> Нет, инструкции разные.

Интересно, каким образом. Или я чего-то не знаю о работе процессоров?))

> Просто чтобы добиться эквивалентного кода в с++ вы напр.
> должны присвоить переменной null  после освобождения памяти, чтобы потом не
> сделать double free.

Зачем? Я просто ничего не буду присваивать. Совершенно сознательно. И, затем, совершенно сознательно не сделаю double free. Как раз сэкономив те самые такты процессора. Что на компиляции, что во время исполнения.

> То что вы так написали выше совсем не значит что инструкции одни
> и те же))

Ну т.е. один и тот же процессор способен выполнять... непредусмотренные изначально инструкции? О_о

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

Ну и? Где нужно, я совершенно сознательно использую std::atomic или std::mutex и иже с ними. При этом опять же совершенно сознательно, где нужно (а бывает и такое), для ускорения работы не буду использовать примитивы синхронизации. Зачем мне лишние проблемы с слишком "умным" компилятором и лишние нагромождения скомпилированных инструкций?

> Ну чего же вы так! Мне не сложно привести примеры))
> codeproject.com/Questions/5331052/Cplusplus-different-output-on-different-compilers
> learn.microsoft.com/en-us/answers/questions/119430/different-results-in-different-compilers-c
> stackoverflow.com/questions/5158014/why-do-different-c-compilers-give-different-results-for-this-code
> qna.habr.com/q/1320980
> ru.stackoverflow.com/questions/1508112/%D0%9F%D0%BE%D1%87%D0%B5%D0%BC%D1%83-%D1%80%D0%B5%D0%B7%D1%83%D0%BB%D1%8C%D1%82%D0%B0%D1%82-%D1%80%D0%B0%D0%B7%D0%BD%D1%8B%D0%B9-%D0%BF%D1%80%D0%B8-%D0%BE%D0%B4%D0%B8%D0%BD%D0%B0%D0%BA%D0%BE%D0%B2%D1%8B%D1%85-%D1%81%D1%82%D0%B0%D0%BD%D0%B4%D0%B0%D1%80%D1%82%D0%B0%D1%85-%D1%8F%D0%B7%D1%8B%D0%BA%D0%B0-%D0%A1
> и тыщщи их

По вашей ссылке - пустота.

> А всё потому, что в распрекрасный стандарт с++ напихали undefined behaviour и
> implementation defined behaviour.

Что-то я их там особо не видел, за исключением тех случаев, когда речь идёт о работе того, что напрямую завязано на особенности железа. Это раз. А два - собственно, в чём проблема то? Ну раз поведение не определено, значит нужно действовать по-другому. У меня за плечами уже не одна сотня тысяч строк кода на С++, и что-то каких-то особых проблем с этим я не видел. Т.е. - это очередная маркетинговая уловка, не более того.

> Насколько я знаю - нет.
> gccrs только разрабатывают и он еще не релизился.
> mrustc еще не релизился и это не generic compiler, а просто чтобы
> бустрапит раста.
> Ferrocene просто надстройка для rustc.

Ну... Я под Rust не писал и не собираюсь, так что вам виднее. Но gccrs на сколько я знаю, может и не готов для "повседневного" использования, но в принципе уже рабочий.

> Значит у сишников нет желания?))

Именно так. Любой ЯП - это просто инструмент. Как вы его используете, зависит полностью от вас. И речь опять таки изначально шла не про С, а про С++ - просьба не менять тему.

> Да, но проверка будет занимать напр. 1000 строк кода. И проверять сотни
> тысяч строк с одинаковым качеством.
> А теперь посади погромиста вычитывать 100к сорцов. Посмеемся))

А чего смеяться то? Можно и не вычитывать, а запустить и посмотреть - где валится. И работать уже по месту. Тем более, что тестировать всё равно надо, независимо от ЯП. Или вы валите всё в релиз без тестирования?))


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

123. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +1 +/–
Сообщение от Аноним (-), 27-Мрт-24, 17:47 
> в С++ большой

Стандарт. Плюс он написан так, что часть вещей просто UB, часть отдана на откуп реализатором компиляторов.
Это всё нужно держать в голове при написании даже самого просто кода.
И на это тратится время и внимание (которое тоже ресурс) программиста.

> И, затем, совершенно сознательно не сделаю double free.

О, как самоуверенно.
Ну или у нас тут человек, который не совершает ошибок.
Или кто-то что-то недоговаривает.

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

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

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

А как вы гарантируете что к этой переменной не будет обращения с другого потока?
Дайте угадаю - вы просто все продумали и пришли к выводу что эта ситуация невозможна? (т.е. по факту "мамой клянусь!")
Но тут есть ваш коллега, у которого другое мнение на этот счет))
А потом Сaptain "That should never happen" strikes! Again...
и у нас очередная уязвимость из-за гонки.

> может и не готов для "повседневного" использования, но в принципе уже рабочий.

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

> По вашей ссылке - пустота.

По всем четырем?? Надо же.
Вот тогда вам еще одна stackoverflow.com/questions/71010294/different-results-between-clang-gcc-and-msvc-for-templated-constructor-in-base-c
Результат работы msvc отличается от gcc и clang.
Получается вы берете рабочий код, компилируете под другую платформу и он начинает работать неправильно.
Странно что вы не видите в этом проблемы.

> У меня за плечами уже не одна сотня тысяч строк кода на С++

Вы же понимаете, что личный опыт так себе аргумент.

>  И речь опять таки изначально шла не про С, а про С++ - просьба не менять тему.

Да, простите. С++ники тоже не сделали такой инструмент.
Может потому что им нравится делать, а потом исправлять уязвимости (мозила и хром передают).
А может потому что они не видят в этом проблемы.
А может задача слишком сложная с теми вольностями что позволяют плюсы.
Кто знает.

> а запустить и посмотреть - где валится. И работать уже по месту.

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

Несмотря на то что сейчас я не с++ программист, мне доводилось исправлять такие баги. И больше не хочется))

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

133. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от ProfessorNavigator (ok), 27-Мрт-24, 19:18 
> Стандарт. Плюс он написан так, что часть вещей просто UB, часть отдана
> на откуп реализатором компиляторов.
> Это всё нужно держать в голове при написании даже самого просто кода.

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

> И на это тратится время и внимание (которое тоже ресурс) программиста.

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

> О, как самоуверенно.
> Ну или у нас тут человек, который не совершает ошибок.
> Или кто-то что-то недоговаривает.

Всё куда проще. Я в своё время тоже напрыгался с подобными вещами. А потом просто выработал для себя несколько простых правил, которые позволяют подобных ошибок избегать. В частности например, "пишешь delete - дважды проверь, что именно". Пока что работает. Иными словами, смысла в Rust нет никакого на мой взгляд, потому что всё, что преподносится, как его преимущество, в С++ достигается применением определённого стиля программирования. При этом всегда остаётся возможность поступить как-то иначе, если вдруг в этом возникнет необходимость.

> Вы ушли куда-то далеко. Мы говорим про инструкции самой программы.

А какая собственно разница, что там в инструкциях программы? Меня интересует, сколько и на что будет потрачено тактов процессора. Всё. Остальное - значения не имеет никакого.

> А как вы гарантируете что к этой переменной не будет обращения с
> другого потока?
> Дайте угадаю - вы просто все продумали и пришли к выводу что
> эта ситуация невозможна? (т.е. по факту "мамой клянусь!")

Нет, на такие вещи я не полагаюсь никогда. А вот на знание, как именно работает моя программа - да, полагаюсь. И не просто так, а протестировав предварительно все возможные варианты.

> А потом Сaptain "That should never happen" strikes! Again...
> и у нас очередная уязвимость из-за гонки.

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

> По всем четырем?? Надо же.
> Вот тогда вам еще одна stackoverflow.com/questions/71010294/different-results-between-clang-gcc-and-msvc-for-templated-constructor-in-base-c

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

> Вы же понимаете, что личный опыт так себе аргумент.

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

>>  И речь опять таки изначально шла не про С, а про С++ - просьба не менять тему.
> Да, простите. С++ники тоже не сделали такой инструмент.
> Может потому что им нравится делать, а потом исправлять уязвимости (мозила и
> хром передают).
> А может потому что они не видят в этом проблемы.
> А может задача слишком сложная с теми вольностями что позволяют плюсы.
> Кто знает.

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

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

Мне тоже доводилось. Грамотное применение дебагера чаще всего помогает))

Ну и для избежания дальнейшего непонимания - резюмирую свою позицию. Rust - это по факту чуть более высокий вид абстракции, что на мой взгляд не нужно совершенно. В ядре я имею ввиду (с чего собственно весь разговор начался). Для прикладных задач - да пожалуйста, пользуйтесь сколько угодно. Это ваше личное дело. Если получится что-то годное - лично я только за. Для себя же лично особого смысла в нём не вижу - меня не напрягает внимательно проверять свои delete (за пределы массива в С++ выйти - это ещё постараться надо). Напрягает же что Rust пихают усиленно везде, где только можно и нельзя, хотя  на поверку все его расписываемые достоинства оказываются не такими уж и достоинствами. Потому что всё это легко достигается в других ЯП просто применением соответствующего стиля программирования. А вот недостатки вполне просматриваются - например отсутствие стандартизации или явно бОльшее количество инструкций как на этапе компиляции, так и на этапе исполнения. Пропихивание же говорит, что это кому-то надо. Зачем? Ну... Мы сегодня живём при капитализме. Пропихивают, значит кто-то увидел свой личный денежный интерес (на самом деле там чётко понятно, кто, что и зачем, но достоверных данных у меня нет, искать - лень, поэтому будем считать это моими домыслами). Если бы это было хоть как-то оправдано с технической точки зрения - я бы ещё понял. Но в нынешнем виде - извините, но нет.


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

148. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +1 +/–
Сообщение от Аноним (-), 27-Мрт-24, 23:59 
Ворвусь как я в тред, если никто не против)

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

Можно ли считать, что "согласно стандарту C++ порядок вычисления аргументов функции не специфицирован" это баг, или просто недоработка?
Я беру одинаковый код, но на разных компиляторах я получаю разный результат.
Можно ли говорить о корректности кода и "стандартизованности" стандарта.

> Программист для того и существует, чтобы тратить своё время именно на такие вещи.

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

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

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

> Иными словами, смысла в Rust нет никакого на мой взгляд, потому что всё, что преподносится, как его преимущество, в С++ достигается применением определённого стиля программирования.

Да, но для этого нужно очень большая дисциплина (что в опенсорсном проекте вообще редкость).
Я видел как люди уходили из открытых проектов просто по причине "я не хочу ждать пока на пулл реквесте пробегут автотесты! я же профи, ты что не доверяешь мне?!"

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

Как и в расте.
Магическое слово unsafe открывает дверь в волшебный мир "делаю что хочу")

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

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

> Нет, на такие вещи я не полагаюсь никогда. А вот на знание, как именно работает моя программа - да, полагаюсь. И не просто так, а протестировав предварительно все возможные варианты.

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

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

Гораздо хуже, когда программист не видит UB)
Т.к запомнить все особенности всех компиляторов.
Можно конечно говорить "нам нужны люди с 20 годами опыта, вот тогда и приходите", но работает это плохо.

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

Но к сожалению в ядре у нас, не современный С++, с умными указателями и прочими благами цивилизации, а С11, причем на него они перешли только ЕМНИП в 22году.

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

К сожалению он для совсем прикладных приложение не очень подходит, тк UI на нем писать непросто.

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

Люди всегда мечтают от серебрянной пуле, даже если она немного ржавая)

> хотя  на поверку все его расписываемые достоинства оказываются не такими уж и достоинствами. Потому что всё это легко достигается в других ЯП просто применением соответствующего стиля программирования.

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

> А вот недостатки вполне просматриваются - например отсутствие стандартизации или явно бОльшее количество инструкций как на этапе компиляции, так и на этапе исполнения.

По стравнению с ASM любые языки высокого уровня генерировали "лишние" инструкции.
Но на них почему-то перешли. Особенно если время компиляции стоит N денег, а 10 часов поиска EXC_BAD_ACCESS стоят M денег, и при этом N < M.

> Пропихивание же говорит, что это кому-то надо. Зачем? Ну... Мы сегодня живём при капитализме. Пропихивают, значит кто-то увидел свой личный денежный интерес

Напомню что СИ был разработан как потомок языка Би (который разработали AT&T, корпорация кстати) и был сделан в лаборатории Bell Labs (тоже корпорация) для абсолютно денежного интереса.
И в этом (для меня) нет ничего плохого.
Ада писалась по заказу Министерства обороны США. И плохим это ее не сделает

А раст для меня похож на токарник с ЧПУ, он умеет часть вещей делать автоматически, но если нужно - можно управлять им в ручном режиме.
И сейчас программист - это почти как слесарь или инжинер в 70-80 (куча народу работает над )
На дороге человек тоже может ехать аккуратно, но ему зачем-то вешают знаки, светофоры и даже ставят отбойники.
А техника безопасности, например электрики (которая ПУЭ) вообще написана кровью.
Так что я за вещи, которые позволят сделать код надежнее.

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

158. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от n00by (ok), 28-Мрт-24, 08:04 
> Ворвусь как я в тред, если никто не против)
>> Если же конечный результат не соответствует ожиданиям - то это уже проблема конкретной реализации, а не стандарта. Т.е., иными словами - баг, или просто недоработка.
> Можно ли считать, что "согласно стандарту C++ порядок вычисления аргументов функции не
> специфицирован" это баг, или просто недоработка?

Тут не считать, а понимать надо, от чего именно так сделано.

Понимать, что такое ABI и конвенции вызовов. Иметь представление, что на одном процессоре аргументы передаются через стек, в таком случае естественный порядок вычисления оказывается - справа налево. В другой архитектуре аргументы передаются через регистры процессора, при этом при вызове функций одни регистры сохраняются, а другие нет; здесь с порядком возникают неоднозначности. Отсюда следует вывод - в стандарте в этом случае поступили совершенно верно.

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

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

165. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от Аноним (-), 28-Мрт-24, 12:43 
> Отсюда следует вывод - в стандарте в этом случае поступили совершенно верно.

А вот и нет.
Всё звучит логично если бы не маааленький нюанс: Eval order в стандарте undefined behavior только до C++17.
https://en.cppreference.com/w/cpp/language/eval_order

А потом ВНЕЗАПНО это поведение стандартизировали!
Как же так получилось, что все предыдущие версии оно жило как UB, а потом вдруг это смогли пофиксить?
Может это таки проблема в стандарте, а фича?)


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

169. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от n00by (ok), 28-Мрт-24, 14:03 
>> Отсюда следует вывод - в стандарте в этом случае поступили совершенно верно.
> А вот и нет.
> Всё звучит логично если бы не маааленький нюанс: Eval order в стандарте
> undefined behavior только до C++17.
> https://en.cppreference.com/w/cpp/language/eval_order
> А потом ВНЕЗАПНО это поведение стандартизировали!

Где стандартизировали и что? Мне по этой ссылке самому надо искать?

"The initialization of a parameter ... is indeterminately sequenced"

ISO/IEC JTC1 SC22 WG21 N 4860

7.6.1.2 Function call

1 A function call is a postfix expression followed by parentheses ...
...
8 The postfix-expression is sequenced before each expression in the expression-list and any default argument. The
initialization of a parameter, including every associated value computation and side effect, is indeterminately
sequenced with respect to that of any other parameter. [Note: All side effects of argument evaluations are
sequenced before the function is entered (see 6.9.1). — end note]

> Как же так получилось, что все предыдущие версии оно жило как UB,
> а потом вдруг это смогли пофиксить?
> Может это таки проблема в стандарте, а фича?)

Что "оно"? Сначала я посмотрел последний черновик стандарта, потом написал комментарий #158. Мне пора качать новый черновик?

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

166. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от Аноним (-), 28-Мрт-24, 12:53 
> Тут не считать, а понимать надо, от чего именно так сделано.

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

> Понимать, что такое ABI и конвенции вызовов. Иметь представление, что ... здесь с порядком возникают неоднозначности.
> Отсюда следует вывод - в стандарте в этом случае поступили совершенно верно.

Я об этом в курсе, но в примере с которого все началось, человек запускает один и тот же код, на одной машине с одним процессором. (stackoverflow.com/questions/5158014/why-do-different-c-compilers-give-different-results-for-this-code)
И получает разный результат.
Потому что создатели компилятор решили сделать по разному.

Это говорит о том, что для того чтобы программа работала предсказуемо, нужно фиксировать тип компилятора и даже его версию.
А ситуация "вот вам код, найдите именно GCC и версию компилятора 7.1.5 тк оно гарантировано работает только на нем" это просто дрмовая ситуация.
Но вполне укладывается в Stable is nonsense идеологию.

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

И кто тогда будет писать ядро? Будем делать экзамен на проф пригодность?
Попросим корпов нанимать только самых лучших, а что если они скажут 'неа, нам лучшие нужны себе'?
А других программеров у тебя просто нет)

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

170. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от n00by (ok), 28-Мрт-24, 14:26 
>> Тут не считать, а понимать надо, от чего именно так сделано.
> Понимание мне никак не поможет в случае "а в этом компиляторе разработчики
> захотели выпендрится"
> Придется читать доку на каждую версию каждого компилятора в надежде, что в
> мире есть хоть где-то стабильность.

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

>> Понимать, что такое ABI и конвенции вызовов. Иметь представление, что ... здесь с порядком возникают неоднозначности.
>> Отсюда следует вывод - в стандарте в этом случае поступили совершенно верно.
> Я об этом в курсе, но в примере с которого все началось,
> человек запускает один и тот же код, на одной машине с
> одним процессором. (stackoverflow.com/questions/5158014/why-do-different-c-compilers-give-different-results-for-this-code)
> И получает разный результат.
> Потому что создатели компилятор решили сделать по разному.

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

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

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

> А ситуация "вот вам код, найдите именно GCC и версию компилятора 7.1.5
> тк оно гарантировано работает только на нем" это просто дрмовая ситуация.
> Но вполне укладывается в Stable is nonsense идеологию.
>> А кто не знает, что такое конвенция вызовов - тому в ядре делать вообще-то и нечего. Сотня таких разнесут проект к чертям.
> И кто тогда будет писать ядро? Будем делать экзамен на проф пригодность?

Этот вопрос к чему? Писать будут те, кого посчитают нужным принимающее решение.

> Попросим корпов нанимать только самых лучших, а что если они скажут 'неа,
> нам лучшие нужны себе'?
> А других программеров у тебя просто нет)

Софтскиллзами так и прёт.

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

167. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от ProfessorNavigator (ok), 28-Мрт-24, 13:46 
> Ворвусь как я в тред, если никто не против)

Площадка публичная, почему кто-то должен быть против?))

> Можно ли считать, что "согласно стандарту C++ порядок вычисления аргументов функции не
> специфицирован" это баг, или просто недоработка?
> Я беру одинаковый код, но на разных компиляторах я получаю разный результат.
> Можно ли говорить о корректности кода и "стандартизованности" стандарта.

Стандарт такой, какой он есть. Если он кому-то не нравится - нужно вносить предложения  по изменению (если таковой механизм доступен) или создавать альтернативу. "На разных компиляторах" в случае с С++ обычно выливается в "а на MSVC не так". Что как бы намекает, что проблема отнюдь не в стандарте...

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

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

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

Не то чтобы прям большой, но кое-какой имеется. И не так уж много людей нужно на самом деле. У вас скорее всего такое впечатление сложилось из-за геймдева. Над играми действительно работает много народу, но далеко не все они - программисты. Большинство там всякие художники, сценаристы, дизайнеры, аниматоры и т.д. Когда пишется что-то прикладное, то там обычно много людей не нужно. Особенно, если им обеспечить нормальные условия труда и грамотно распределить задачи.  

> Да, но для этого нужно очень большая дисциплина (что в опенсорсном проекте
> вообще редкость).
> Я видел как люди уходили из открытых проектов просто по причине "я
> не хочу ждать пока на пулл реквесте пробегут автотесты! я же
> профи, ты что не доверяешь мне?!"

А без дисциплины - никуда. Окружающей реальности нет дела до наших проблем. Потому что она неживая. И действует по своим законам. Мы или можем ей противостоять, и под неё подстраиваться, либо умираем. Подобные проблемы на самом деле сегодня актуальны вообще во всех сферах человеческой деятельности. Просто потому, что мы подошли к условной кризисной точке в своём развитии. И либо мы изменим своё отношение буквально ко всему, либо вымрем. C'est la vie.

> Как и в расте.
> Магическое слово unsafe открывает дверь в волшебный мир "делаю что хочу")

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

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

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

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

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

> Гораздо хуже, когда программист не видит UB)
> Т.к запомнить все особенности всех компиляторов.
> Можно конечно говорить "нам нужны люди с 20 годами опыта, вот тогда
> и приходите", но работает это плохо.

Зачем вам запоминать всё? Документацию как раз и придумали на такие вот случаи. Не знаю, как и чему учили вас, нас же учили так: "Ты можешь чего-то не знать. Но где это можно найти - ты знать обязан". Правда я по образованию ни разу не программист)) Что, впрочем, не отменяет верность описанного выше принципа для любых ситуаций.

> Но к сожалению в ядре у нас, не современный С++, с умными
> указателями и прочими благами цивилизации, а С11, причем на него они
> перешли только ЕМНИП в 22году.

Да не вопрос - если посмотрите, с чего всё началось, то я о том и говорил в общем-то. Мне реально странно видеть, что в ядре Линукс не используют С++. На заре появления языка вполне возможно, что для этого были объективные причины. Но в текущих реаиях с технической точки зрения подобное решение выгляди неоправданным. Опять же - я могу чего-то не знать. Но всё, что я видел по этому поводу от непосредственных участников проекта, выглядит, как глупое упрямство. Причём, не обязательно ведь переписывать всё и сразу. С++ благодаря своим свойствам позволяет сделать процесс постепенным.

> К сожалению он для совсем прикладных приложение не очень подходит, тк UI
> на нем писать непросто.

Вот собственно ещё один недостаток языка. Вполне объективный.

> Люди всегда мечтают от серебрянной пуле, даже если она немного ржавая)

Ну... Я об этом уже написал выше. Немного перефразирую сказанное - людям пора повзрослеть. И понять наконец, что магии не существует. Любые преимущества достигаются за счёт того, что в чём-то другом проседание. У всего есть свои преимущества и недостатки. Да, С/С++ позволяют допускать ошибки. Однако об этом известно (точнее - должно быть известно) любому, кто начинает с ними работать. И такое поведение необходимо учитывать. Но взамен мы получаем существенное снижение нагрузки на процессор и память как в процессе компиляции, так и в процессе работы программы. А также очень гибкий инструмент, позволяющий делать буквально всё, что угодно практически на любом оборудовании. И это главное. Недостатки Rust тут уже обсуждали, и не раз, поэтому повторяться не буду. Суть в том, что его применение с технической точки зрения - неоправданно. А все проблемы, которые он якобы решает, могут быть устранены уже имеющимися средствами, причём без особых на то усилий - достаточно лишь понимать, что происходит, и иметь желание сделать всё правильно.

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

Заставить кого-то делать что-то невозможно в принципе. Можно лишь чётко и внятно объяснить человеку, почему нужно поступать так или иначе. Чтобы он сам захотел делать вещи правильно. Или убить. Собственно именно поэтому я тут словоблудием и занимаюсь - до второго варианта доводить не хотелось бы)) Надеяться тоже ни на что не нужно. Нужно решать поставленную задачу в рамках имеющихся средств. Предварительно выработав общий план работ.

> По стравнению с ASM любые языки высокого уровня генерировали "лишние" инструкции.
> Но на них почему-то перешли. Особенно если время компиляции стоит N денег,
> а 10 часов поиска EXC_BAD_ACCESS стоят M денег, и при этом
> N < M.

Всё очень просто. Ассемблеров больше одного - они индивидуальны для каждой архитектуры процессоров. И в такой ситуации появление некой абстракции в виде языков более высокого уровня как раз вполне оправданно. Потому что позволяет разделить задачи: если делать всё по уму, то создатель процессора той или иной архитектуры должен вместе с ним выпустить спецификацию команд, а также компилятор для того или иного языка высокого уровня. Какого именно - тут опять же по уму нужно всем собраться и решить, что мы используем. Потому что любой ЯП высокого уровня - это просто текст, который преобразуется компилятором в команды. Компилятор можно настроить как угодно, поэтому здесь нужно смотреть на удобство и лаконичность именно текста. На мой взгляд С++ - в данном случае вполне оптимальный вариант. Но это уже решать не  только мне. При этом спецификация всего этого дела должна быть полностью открытой, чтобы любой мог создать нечто своё - вдруг получится лучше? Но при этом решение об использовании нового ЯП, как стандарта, должно приниматься ВСЕМИ УЧАСТНИКАМИ ПРОЦЕССА. Как программистами, так и пользователями. Потому что это затронет всех.

> Напомню что СИ был разработан как потомок языка Би (который разработали AT&T,
> корпорация кстати) и был сделан в лаборатории Bell Labs (тоже корпорация)
> для абсолютно денежного интереса.
> И в этом (для меня) нет ничего плохого.
> Ада писалась по заказу Министерства обороны США. И плохим это ее не
> сделает

Здесь нужно разбираться индивидуально по каждому случаю. Но при этом стоит учитывать несколько факторов. Первое - С/С++ стандартизированы на международном уровне, что сильно затрудняет любые попытки подмять всё это дело под себя для получения исключительно личной выгоды. Второе - для С/С++ существует открытый компилятор, который опять же с юридической точки зрения будет практически невозможно подмять под себя. О его качестве можно спорить, не суть, главное - он есть. Т.е. кому-либо будет достаточно сложно создать монополию. По крайней мере легально. Почему монополизация в условиях капитализма - это плохо, надеюсь, объяснять не нужно?

> А раст для меня похож на токарник с ЧПУ, он умеет часть
> вещей делать автоматически, но если нужно - можно управлять им в
> ручном режиме.
> И сейчас программист - это почти как слесарь или инжинер в 70-80
> (куча народу работает над )
> На дороге человек тоже может ехать аккуратно, но ему зачем-то вешают знаки,
> светофоры и даже ставят отбойники.
> А техника безопасности, например электрики (которая ПУЭ) вообще написана кровью.
> Так что я за вещи, которые позволят сделать код надежнее.

Надёжнее код может сделать только одно - повышение квалификации программистов. Никаких других путей для этого не существует.


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

108. Скрыто модератором  +/–
Сообщение от C00l_ni66a (ok), 27-Мрт-24, 16:47 
Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

124. Скрыто модератором  +1 +/–
Сообщение от Аноним (-), 27-Мрт-24, 17:54 
Ответить | Правка | Наверх | Cообщить модератору

131. Скрыто модератором  +/–
Сообщение от C00l_ni66a (ok), 27-Мрт-24, 19:10 
Ответить | Правка | Наверх | Cообщить модератору

134. Скрыто модератором  +/–
Сообщение от Аноним (-), 27-Мрт-24, 19:22 
Ответить | Правка | Наверх | Cообщить модератору

139. Скрыто модератором  –1 +/–
Сообщение от C00l_ni66a (ok), 27-Мрт-24, 20:25 
Ответить | Правка | Наверх | Cообщить модератору

143. Скрыто модератором  +/–
Сообщение от Аноним (-), 27-Мрт-24, 21:30 
Ответить | Правка | Наверх | Cообщить модератору

173. Скрыто модератором  +/–
Сообщение от C00l_ni66a (ok), 29-Мрт-24, 15:04 
Ответить | Правка | Наверх | Cообщить модератору

175. Скрыто модератором  +/–
Сообщение от Аноним (-), 29-Мрт-24, 15:59 
Ответить | Правка | Наверх | Cообщить модератору

176. Скрыто модератором  +/–
Сообщение от C00l_ni66a (ok), 29-Мрт-24, 18:07 
Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

177. Скрыто модератором  +/–
Сообщение от Аноним (-), 29-Мрт-24, 18:56 
Ответить | Правка | К родителю #176 | Наверх | Cообщить модератору

185. Скрыто модератором  +/–
Сообщение от C00l_ni66a (ok), 30-Мрт-24, 16:07 
Ответить | Правка | К родителю #177 | Наверх | Cообщить модератору

70. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  –1 +/–
Сообщение от Аноним (40), 27-Мрт-24, 14:22 
Что значит неправильно использовать? Использовать так, как уместно в конкретном случае. Да, это вам не растофашизм.
Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

74. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +1 +/–
Сообщение от Аноним (-), 27-Мрт-24, 14:30 
> Использовать так, как уместно в конкретном случае.

Вот погромист из этой новости посчитал, что вполне уместно в том конкретном случае очистить память дважды.
Почему? А потому что ему так захотелось.

И в с++ можно сделать тоже самое.
Никто же не запретит. Это вам не растофашизм))

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

95. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  –1 +/–
Сообщение от Аноним (39), 27-Мрт-24, 16:29 
Раст ему никак не помешает сделать таких же unsafe глупостей. Без unsafe растовикр писать пока что не научились.
Ответить | Правка | Наверх | Cообщить модератору

100. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +1 +/–
Сообщение от Аноним (-), 27-Мрт-24, 16:32 
За unsafe тебя спросят на первом же кодревью.
Ты можешь пройтись поиском и легко найти все места где есть unsafe.
Это тебе сократит область поиска в десятки раз.

> Без unsafe растовикр писать пока что не научились.

Есть целая категория либ unsafe forbidden, где его вообще запрещено использовать.
Как же интересно они их написали?

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

111. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  –2 +/–
Сообщение от C00l_ni66a (ok), 27-Мрт-24, 16:53 
>Есть целая категория либ unsafe forbidden, где его вообще запрещено использовать.

Либы это, конечно, замечательно, а *софт* есть? Ну, то есть, тот, где меньше двух сотен лефтпадов и в этих лефтпадах тоже нет ансейфов?

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

144. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +1 +/–
Сообщение от Аноним (142), 27-Мрт-24, 21:50 
Андроид. В нем уже дофига раст-кода в системных компонентах
Ответить | Правка | Наверх | Cообщить модератору

174. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от C00l_ni66a (ok), 29-Мрт-24, 15:08 
А конкретнее? Что это за "системные компоненты"? Тебя про это уже вроде спрашивали, но ничего осмысленного ты не ответил, просто продолжил ссылаться на какую-то шизоагитку от гулага.
Ответить | Правка | Наверх | Cообщить модератору

92. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от Аноним (92), 27-Мрт-24, 16:25 
> но до раста ему топать и топать

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

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

112. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от C00l_ni66a (ok), 27-Мрт-24, 16:55 
Там даже не просто "написанным", сама хрустяшка дёргает именно ПЛЮСОВЫЙ фронтенд ллвм апи. Что как бы намекает.
Ответить | Правка | Наверх | Cообщить модератору

68. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от Пряник (?), 27-Мрт-24, 14:16 
Не всегда мудрость приходит с возрастом.
Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

69. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от Аноним (32), 27-Мрт-24, 14:20 
Плюсы сложнее сишки во всём, с чего это они должны быть в ядре? Лучше уж сишка, хоть и старьё.
Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

75. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +1 +/–
Сообщение от ProfessorNavigator (ok), 27-Мрт-24, 14:30 
> Плюсы сложнее сишки во всём, с чего это они должны быть в
> ядре? Лучше уж сишка, хоть и старьё.

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

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

85. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от Аноним (-), 27-Мрт-24, 16:03 
> это всё относительные понятия. Т.е. при их употреблении нужно сразу уточнять - для кого?

Именно! Не думал что скажу это, но согласен.
Напрмер Раст - он 'проще' для тех кто не сильно знаком с СИ или плюсами, и 'сложнее' для Сишников.
Он 'легче' в том смысле что у него меньше UB/IB и тд, но 'тяжелее' в том что нужно освоить новые концепции типа borrow.
Он 'лучше' для кода, тк практически убирает ошибки памяти и дает программерам возможность сосредоточиться на например логических, но при этом он убирает возможность сидеть на поддержке СИшного овнокода десятилетиями, и для программистов это 'хуже' тк согласно религии секты бородатой антилопы, зарабатывать деньги можно только на поддержке кода.

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

А вот тут не соглашусь.
Старые языки содержат в себе концепты и подходы своего времени.
И обычно приходится тянуть обратную совместимость, что не позволяет выкинуть весь старый хлам и добавить новые подходы.
Например создать класс Error и перестать прокидывать результат функции/ошибки интами.(положильными результат, отрицательными ошибки.. или наоборот? и не дай бор получить переполнение и сменить знак!).
Или добавить pattern matching.

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

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

91. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от ProfessorNavigator (ok), 27-Мрт-24, 16:23 
> Он 'лучше' для кода, тк практически убирает ошибки памяти и дает программерам
> возможность сосредоточиться на например логических, но при этом он убирает возможность
> сидеть на поддержке СИшного овнокода десятилетиями, и для программистов это 'хуже'
> тк согласно религии секты бородатой антилопы, зарабатывать деньги можно только на
> поддержке кода.

Извините, но чушь. Не валите всё в одну кучу. Зарабатывание денег можно обсудить в другой плоскости, и Rust снова проиграет, но уже совершенно по другим причинам. Но это разговор о-очень долгий и к IT относящийся лишь косвенно. И, если что, напомню - изначально речь шла о С++, а не о С.

> А вот тут не соглашусь.
> Старые языки содержат в себе концепты и подходы своего времени.
> И обычно приходится тянуть обратную совместимость, что не позволяет выкинуть весь старый
> хлам и добавить новые подходы.
> Например создать класс Error и перестать прокидывать результат функции/ошибки интами.(положильными
> результат, отрицательными ошибки.. или наоборот? и не дай бор получить переполнение
> и сменить знак!).
> Или добавить pattern matching.
> А если авторы таки решаются поломать совместимость, то это происходит ну очень
> болезнено и с кучей проблем.

Ну так всё описанное и есть технические особенности. Возраст тут совершенно ни при чём.


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

110. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от Аноним (-), 27-Мрт-24, 16:53 
> Извините, но чушь. Не валите всё в одну кучу. Зарабатывание денег можно обсудить в другой плоскости, и Rust снова проиграет, но уже совершенно по другим причинам.

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


> Ну так всё описанное и есть технические особенности. Возраст тут совершенно ни при чём.

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

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

122. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от ProfessorNavigator (ok), 27-Мрт-24, 17:47 
>> Извините, но чушь. Не валите всё в одну кучу. Зарабатывание денег можно обсудить в другой плоскости, и Rust снова проиграет, но уже совершенно по другим причинам.
> Ладно, давайте отложим тему денег,
> предположим что у нас есть заадча написать какой-то код, для простоты пусть
> это будет либа. Она будет работать на миллионах устройств и поэтому
> для нее есть требования "максимальной надежности".
> Какой язык программирования вы бы выбрали?

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


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

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


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

86. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от Аноним (86), 27-Мрт-24, 16:04 
Технические особенности плюсов таковы, что язык не востребован за пределами геймдева. И дальше дискуссию можно не продолжать.
Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

87. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от ProfessorNavigator (ok), 27-Мрт-24, 16:13 
> Технические особенности плюсов таковы, что язык не востребован за пределами геймдева. И
> дальше дискуссию можно не продолжать.

Да что вы говорите)) Настолько не востребован, что на нём аж компилятор gсс написан. Которым С программы собирают)) Это я уже молчу про кучу разного прикладного.


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

90. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +1 +/–
Сообщение от Аноним (-), 27-Мрт-24, 16:21 
Технические особенности сишки таковы, что на ней:
- или тянут древние проекты вроде ядра линукса, которым десятилетия.
- или используют для лютой ембедщины.

Потому что плюс для прикладного программирования лучше сишки во всем.
Особенно последние редакции от с++17 и выше.
А сишка вообще остановилась в развитии.

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

103. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +1 +/–
Сообщение от Аноним (-), 27-Мрт-24, 16:38 
Хмм.. а на чем там у соседей написан оффтопик?
Удивительно, но их графическая система написана таки на с++.

Самый популярный в мире браузер (и по совместительству самое популятное DE для ядра линукс) - chromium тоже написан на плюсах.

Я могу еще вспомнить фотошоп, но тк тут форум любителей полуфа/bрикатов, то скажу что гимп частично написан на плюсах.
А еще есть Open/LibreOffice, WxWidgets, 7-Zip и даже Haiku.
Тысячи их!

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

136. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от n00by (ok), 27-Мрт-24, 19:23 
Технические особенности плюсов таковы, что в неправильной ОС, где нужен "антивирус", большинство драйверов тех самых HIPS написано на плюсах. И некоторые из них помешали бы исполняться аналогу героя сегодняшней новости.
Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

179. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от Карлос Сношайтилис (ok), 29-Мрт-24, 23:41 
> С++ позволяет многое делать в разы проще

С[++] также позволяет и НЕ делать.

> Но вместо С++ зачем-то начали
> пихать Rust.

Если чего-то не понимаешь, то есть два варианта: попытаться разобраться или свалить на масонов.

> С++ позволяет ... при правильном использовании

Ну вот видишь, ты сам и разобрался в чём причина. Согласись, было просто.

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

180. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от ProfessorNavigator (ok), 30-Мрт-24, 00:08 
> С[++] также позволяет и НЕ делать.

Да. И?

> Если чего-то не понимаешь, то есть два варианта: попытаться разобраться или свалить
> на масонов.

А при чём здесь масоны?))

> Ну вот видишь, ты сам и разобрался в чём причина. Согласись, было
> просто.

Сказать то чего хотели, уважаемый?


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

183. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от Карлос Сношайтилис (ok), 30-Мрт-24, 14:12 
> Сказать то чего хотели, уважаемый?

Ты задал вопрос, сам же на него ответил. Я тебе на это указал.
Или надо расжевать?

Мне не сложно, давай.

Можно ли на расте писать безопасный код? Можно.
Можно ли на плюсах писать безопасный код? Можно.
Можно ли на расте писать небезопасный код? Можно.
Можно ли на плюсах писать небезопасный код? Можно.

Почему при этом когда выбирают Раст, аппелируют к безопасности?
Ты на этот вопрос ответил.

Теперь вопрос к тебе - зачем ты задаёшь вопрос, ответ на который тебе известен?

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

184. "Уязвимости в ядре Linux, позволяющие поднять свои привилегии..."  +/–
Сообщение от ProfessorNavigator (ok), 30-Мрт-24, 14:53 
>[оверквотинг удален]
> Или надо расжевать?
> Мне не сложно, давай.
> Можно ли на расте писать безопасный код? Можно.
> Можно ли на плюсах писать безопасный код? Можно.
> Можно ли на расте писать небезопасный код? Можно.
> Можно ли на плюсах писать небезопасный код? Можно.
> Почему при этом когда выбирают Раст, аппелируют к безопасности?
> Ты на этот вопрос ответил.
> Теперь вопрос к тебе - зачем ты задаёшь вопрос, ответ на который
> тебе известен?

Да, так стало немного яснее, но не до конца. Зачем вы пишите комментарий? Я так полагаю, чтобы выразить свою позицию и высказать мнение. И из ваших высказываний мне пока что непонятно - что конкретно вы пытаетесь до меня донести. Нужен/не нужен С++ в ядре? Нужен/не нужен Rust в ядре? Почему? Знаете ли вы конкретные причины, по которым C++ не используется в ядре, а Rust там появился? Может быть вы видели какие-то конкретные высказывания от самих участников проекта? Или быть может вы согласны с моей позицией по данному вопросу? Тогда не проще ли было так и написать? Чтобы не вызывать лишние вопросы.


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

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

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




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

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