LINUX.ORG.RU
ФорумTalks

Бьёрн Страуструп призвал стандартизировать профили C++ для безопасной работы с памятью

 , , ,


0

2

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

Бьёрн Страуструп (Bjarne Stroustrup), создатель языка C++, призвал комитет WG21, отвечающий за разработку стандартов для языка C++, предпринять меры для сохранения актуальности C++ в условиях активного продвижения инициатив по переходу на языки, обеспечивающие безопасную работу с памятью. Страуструп считает, что язык С++ уже содержит все возможности, необходимые для безопасной работы с памятью. Остаётся только предоставить средства, гарантирующие, что код написан с использованием только безопасных возможностей.

По мнению Страуструпа, времени осталось очень мало и необходимо до 2026 года успеть предпринять какие-то меры, так как Агентство по кибербезопасности и защите инфраструктуры США и ФБР стали более активно продвигать среди производителей ПО идею перехода на языки, безопасного работающие с памятью. До 2026 года производителям ПО рекомендовано разработать план по применению в своих продуктах технологий, защищающих от ошибок при работе с памятью, или переходу на использование языков, безопасно работающих с памятью.

Стандартизация возможностей для безопасной разработки на C++ позволит сохранить интерес к языку С++, особенно с учётом того, что разработчики существующих проектов на С и C++ смогут постепенно наращивать безопасность своих продуктов, не прибегая к инициативам по переписыванию на другом языке. В частности, проекты на C можно преобразовать в код С++, а за тем поэтапно переводить код на безопасные конструкции, следуя рекомендациям из руководства «C++ Core Guidelines».

Для обеспечения разработки безопасного кода Страуструп предлагает стандартизировать систему профилей C++, вводящих дополнительные требования к коду. Профили близки к применению флагов -Wall и -Wextra при компиляции, но в отличие от них работают на уровне запрета применения определённых возможностей языка. К реализации предлагаются профили для безопасных типов, контроля времени жизни объектов, работы с допустимыми диапазонами значений и целочисленной арифметики. Привязку к профилям можно задавать не только для проекта и файлов (например, [[profile::enforce(type)]]), но и включать/отключать на уровне отдельных конструкций (например, [profile::suppress(lifetime))] this->succ = this->succ->succ;).

Работа по повышению безопасности будет сводится к включению профиля для определённого кода и переписыванию частей, использующих небезопасные возможности языка, охватываемые выбранным профилем. Например, использование профилей поможет уйти от применения в коде сырых указателей и массивов, избавиться приведения типов и защититься от обращений к неинициализированным объектам. Вместо сырых указателей можно использовать, например, умные указатели std::unique_ptr и std::shared_ptr с отслеживанием владения. При наличии в коде циклов «for», перебирающих отдельные элементы Си-массива, потребует заменить данные циклы на вариант с обработкой диапазонов for(type variable : vector), использующий std::vector.

Предложены следующие профили:

  • type – каждый объект должен быть инициализирован, не допускается приведение типов.
  • lifetime – запрещены ссылки на освобождённые или неиспользуемые области памяти, разыменование указателей, явный вызов new/delete.
  • bounds – требуется проверка допустимых диапазонов при работе с указателями, запрещены арифметические операции с указателями.
  • arithmetic – блокируются целочисленные переполнения, запрещены знаковые/беззнаковые преобразования, изменяющие значение.
  • concurrency – исключает операции, приводящие к взаимным блокировкам и состояниям гонки.
  • RAII (Resource Acquisition Is Initialization) – требует проверки владения для каждого ресурса.

Гарантии, реализуемые при использовании профилей:

  • Обращение к объекту допускается только в соответствии с типом, под которым этот объект был определён.
  • Каждый объект должен быть корректно создан и освобождён.Каждый объект должен быть корректно создан и освобождён.
  • Каждый указатель должен указывать на корректный объект или нулевой указатель.
  • Каждая ссылка через указатель не должна переходить по нулевому указателю.
  • Каждое обращение через индексированный указатель должно находиться в пределах допустимого диапазона.
★★★★★

Последнее исправление: dataman (всего исправлений: 1)
Ответ на: комментарий от sparkie

Видимо и Линуса заставляют двигаться. Как то не верится что С++ он ненавидит, а Rust ему прям очень понравился.

MOPKOBKA ★★★★★
()

предпринять меры для сохранения актуальности C++

«Поздно пить боржоми…»

quickquest ★★★★★
()

Ох как дедуля стал выплясывать, когда его носом стали тыкать в его же поделие. Торвальдс и тот оказался хитрее, он публично Раст стал в ядро затягивать, типа смотрите, какие мы клиентоориентированные. :)

Xintrea ★★★★★
()

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

Тонны легаси могут быть аргументом, но могут и не быть, поскольку добавление аннотаций к старому коду может приводить к необходимости серьёзного рефакторинга, на фоне которого переписывание с нуля с использованием общественных наработок последних лет может оказаться не такой уж существенной ценой.

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

unC0Rr ★★★★★
()
Последнее исправление: unC0Rr (всего исправлений: 1)

Вместо сырых указателей можно использовать,

Вот когда вместо «можно» будет «нужно», тогда и стоит говорить что-то про безопасность.

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

WatchCat ★★★★★
()
Ответ на: комментарий от WatchCat

Вот когда вместо «можно» будет «нужно», тогда и стоит говорить что-то про безопасность.

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

MOPKOBKA ★★★★★
()
Ответ на: комментарий от unC0Rr

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

да ладно. как раз все покушения в этой сфере и были на с++. начиная с java.

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

alysnix ★★★
()
Ответ на: комментарий от unC0Rr

Тонны легаси могут быть аргументом, но могут и не быть, поскольку добавление аннотаций к старому коду может приводить к необходимости серьёзного рефакторинга

Никто вроде и не собирался добавлять аннотации к старому коду. Добавлять будут к новому.

MOPKOBKA ★★★★★
()
Ответ на: комментарий от MOPKOBKA

Угу и большинство будут класть большой и толстый на эти профили.

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

WatchCat ★★★★★
()
Ответ на: комментарий от WatchCat

Компилятор будет выдавать ошибку если профиль нарушен. Иначе как еще интерпретировать слово «запрет»?

многие будут писать код напохрен

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 3)
Ответ на: комментарий от unC0Rr

Любой твой код через 5 минут после написания == легаси. Хватит уже насиловать этот «термин», предполагая какой то мифический одинразинавсегда написанный код. Ты либо «привет миры» каждый раз переписываешь, либо поддерживаешь кодовую базу.

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 2)
Ответ на: комментарий от MOPKOBKA

пишут, unsafe

Слухи о количестве unsafe в Rust значительно преувеличены «любителями» Rust.

Что же насчёт как оно будет в плюсах ещё не до конца понятно. И этого точно не будет C++26.

WatchCat ★★★★★
()
Ответ на: комментарий от WatchCat

И этого точно не будет C++26.

Откуда ты это высосал, ты нам конечно же не расскажешь?)

PRN
()
Ответ на: комментарий от WatchCat

Слухи о количестве unsafe в Rust значительно преувеличены «любителями» Rust.

Ну вот например, 1 unsafe на каждые 20 строк, https://android.googlesource.com/platform/frameworks/native/ /refs/heads/main...

Много кода который я видел от Google, и который на Rust, покрыт весь unsafe.

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

Что же насчёт как оно будет в плюсах ещё не до конца понятно

Да.

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 3)

Попомните моё слово: в итоге С и раст будут соревноваться кто лучше и быстрее внедрит концепцию variable/function/block scopes и эталоном реализации на который оба будут тайно оглядываться будет… JS. Таким образом, колесо Сансары совершит очередной оборот.

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

Obezyan
()
Последнее исправление: Obezyan (всего исправлений: 1)
Ответ на: комментарий от unC0Rr

Вау, в ffi ансейф, открытие века, спешите видеть!

это говорит о том, что есть предметные области, где в принципе ваши «обещания» безопасного кода не работают.

а там где они работают, там можно вполне безопасно писать и без раста.

alysnix ★★★
()

The new US administration has removed everything from the White House web site and fired most of the CISA people who worked on memory safety…

Расходимся.

rupert ★★★★★
()
Ответ на: комментарий от MOPKOBKA

Ну, за Торвальдса ничего не скажу — не знаю. А Страуструп всё-таки крупный учёный, целый доктор наук.

sparkie ★★★★★
()
Ответ на: комментарий от MOPKOBKA

От того что там ffi, unsafe не перестает быть unsafe

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

red75prim ★★★
()
Ответ на: комментарий от red75prim

за гарантии правильности кода вместо

Гарантии разные бывают. Я не знаток С++, но у него контракты к С++26 готовятся, с pre()/post() синтаксисом в определении функции, и концепты уже есть. Такого в Rust за пределами unsafe нету. Это продвигает его ближе к SPARK: https://docs.adacore.com/spark2014-docs/html/ug/en/source/subprogram_contract...

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 1)
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)