Страуструп реагирует на критику безопасности C++

Поясните для непрограммиста. Вот в безопасном rust есть unsafe. Это ли не является тем самым «профилем»? Добавить в C++ профиль safe и он станет таким же безопасным, как и rust. Или это другое?

Плюс в rust есть pkexec, из которого дёргается всякое. Это ведь тоже небезопасно.

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

Перефразируя,

Если создать полностью безопасный язык, то только безопасник и станет таким пользоваться

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

Что касается указателей в C++, прямая совместимость с C - это одна из киллер-фич плюсов, из за неё можно использовать множество библиотек на С без изменений, и, например, API к системе, во всех системах для компов общего назначения со времён UNIX в терминах С, потому что сами системы написаны на С. Т.е. придется кому-то решать проблему с обертками над «безсишными плюсами», чтобы можно было непосредственно взаимодействовать с ОС.

C++ нужен новый синтаксис (вроде https://github.com/hsutter/cppfront), работающие в компиляторах и популярных библиотеках модули, переосмысление exceptions -> panics, переработка libstdc++ на что-то похожее на abseil, переосмысление ABI на подобие Swift, стандарт code style, UB-free подмножество языка с проверкой компилятором, sane defaults для линтеров. Тогда норм язык будет.

Стал бы, но у него лапки.

Я с самого начала всячески выступал за гораздо более строгую систему типов в C++

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

если в них есть способ вызвать C или C++, они уже не безопасные

А уж если код можно запустить на процессоре со Spectre… Расслабляемся, поцоны: безопасности не существует, всё уже и так хорошо.

можно ограничиться … можем почти гарантировать … можно опираться … можно определить …

Напоминает анекдоты про математиков с их «решение существует!». Всё хорошо, проблем нет.

Необходимо запретить разрабам компиляторов использовать UB как предлог для оптимизации

Наверно, лучшее, что действительно можно сделать. Только проблемы с оптимизацией - они не только от UB, вспоминаем выкидывание memset на буфер с паролем.

Мне вот что интересно.

Почему в новых стандартах C++ не сделают компилятор строже вплоть до того, чтобы старый код с небезопасными конструкциями переставал компилироваться с флагом -std=с++24? Не в первый раз ломают компиляцию (вспоминаем -fcommon) и не в последний, давно бы уже надели крестик.

И почему они в стандарте не детерминируют все UB? То есть если раньше было i++ + ++i а хрен знает что там выдаст, то в C++24 это будет детерминировано и так для каждого UB случая.

Все эти UB давно уже исследованы, по оптимизациям с их использованием набрана огромная статистика и т. д. Что мешает детерминировать большинство UB и пофиксить эти косяки стандарта?

Тем более все экзотические архитектуры окроме x86{_64}, arm и riscv по сути вымерли, как и BigEndian. Все эти «а вот на нашей системе байт не 8 бит, а 16 бит» для которых и были оставлены лазейки UB для оптимизации – тоже. Пусть разработчики компиляторов под экзотику страдают с детерминированым стандартом и изощряются делая свои подмножества C++ с UB, но каким хреном весь остальной мир прикладных и системных программистов вот уже 30 с гаком лет шагает по граблям UB потому что в какой-то там мёртвой экзотической архитектуре байтик можно сэкономить?

Если создать полностью безопасный язык, то только безопасник и станет таким пользоваться

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

Безопасность - это внутренне противоречивое понятие.

Необходимо запретить разрабам компиляторов использовать UB как предлог для оптимизации;

ОООООЧЕНЬ хочется какого-нибудь -Werror-ub

Я сталкивался с тем, что шланг на О3 вырезал уб из одной древней библиотеки. И тестировать абсолютно весь древний 3rdPqrty код под ubsan у меня нет ни времени, ни желания.

Тогда норм язык будет.

Тогда другой язык будет.

Люди, не понимающие, что система типов никак не относится к безопасности, реагируют на высказывания Страуструпа.

А вообще, сложился консенсус: мы пишем небезопасные приложения на небезопасных языках, зато в них есть котики и модные стикеры. И пока мы можем зарабатывать на котиках и модных стикерах, все вопросы безопасности мы будем решать потом, по мере возникновения. Ну, как решать? Подпирать костылями.

Люди, не понимающие, что система типов никак не относится к безопасности,

Чойта? Запретить указатели и строки с массивами нефиксированной длины - и куча уязвимостей закроется. Другое дело, что на таком ЯП только хелловорлд написать и получится.

система типов никак не относится к безопасности

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

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

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

Почему бы не набраться смелости и не

засадить двоечку интервьюеру с криком КОМУ ЗДЕСЬ ЕЩЕ ПОЯСНИТЬ ЗА БЕЗОПАСНОСТЬ?

Запретить указатели и строки с массивами нефиксированной длины -

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

в це-пе-пе плохо задействованы символы @` (собачка и обратная кавычка). Надо это дело срочно исправлять

ЗЫ. при наличии инвестиций в PR это сильно улучшает безопасность кстате.

Добавить в C++ профиль safe и он станет таким же безопасным

В rust ещё есть lifetimes, которые позволяют больше кода подогнать под рамки «профиля» safe. Если их реализовать в C++, то языкы по большей части станут эквивалентны – не считая мелких деталей, библиотек и синтаксиса. А вообще язык не может быть «безопасным», это просто маркетинговый термин, обозначающий подстиланную соломку около возможных граблей системного ЯП.

в це-пе-пе плохо задействованы символы @

Они были зашкварены в Objective-C.

Меня раздражает, когда люди говорят о каком-то C/C++, это мифический ЯП, его не существует;

Где он увидел людей, которые считают, что такой язык существует? Обычно это упоминается в контексте опыта человека в разработке и означает, что есть какие-то знания и какой-то опыт на обоих языках (какой именно — вопрос уже десяты), либо же в контексте обсуждения какой-то конкретной фичи, которая реализована в обоих совершенно языках одинаково.

другия ЯП, которые утверждают, что они безопасные и у них нет небезопасного кода… если в них есть способ вызвать C или C++, они уже не безопасные;

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

Необходимо запретить разрабам компиляторов использовать UB как предлог для оптимизации;

Как он собирается это делать? И что должен по стандарту делать компилятор, если там UB? Как бог на душу положит? Ну так это ничем не отличается и от оптимизации под предлогом UB. А если не как бог на душу положит, а как-то стандартно для всех, то behavior внезапно становится очень даже defined, а не undefined. Короче, бессмыслица какая-то.

Как-то всё неубедительно, короче. На покой пора старичку¹.

¹ Понимать под «старичком» Страуструпа или его детище — на усмотрение читателя.

Все эти UB давно уже исследованы

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

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

Carbon? :)

Меня раздражает, когда люди говорят о каком-то C/C++, это мифический ЯП, его не существует;

Где он увидел людей, которые считают, что такой язык существует?

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

Давно видно, что С++ движется к тому, чтобы стать Python-ом без GIL и интерпретатора

Движется скорее к Cobol-у, когда новый код уже не пишут, но старый надо как-то поддерживать.

Выглядит довольно слабо. С самого начала был выбран небезопасный C

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

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

На 36й минуте маэстро говорит: «[…] Ada, which is probably the best language for certain forms of […] they don’t mention it»

когда новый код уже не пишут

Это не так. Даже переписывают с Питона на С++.

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

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

Тем более все экзотические архитектуры окроме x86{_64}, arm и riscv по сути вымерли, как и BigEndian

Мейнфреймы IBM использующие big endian передают привет.

В D добавили профиль safe…

https://dlang.org/spec/memory-safe-d.html

Не весь UB можно поймать в compile-time, тот же signed integer overflow

() -> T = {

ббблллдджээааддъъъ...

Если ты считаешь это слабыми аргументами

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

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

с совсем дерьмом мамонта не сталкивался, но сталкивался с кодом двадцатилетней выдержки

Мейнфреймы IBM использующие big endian передают привет.

С чего это вдруг они используют Big-Endian в 2023 году? Разве что в bootloader’е где-то, местном аналоге UEFI. А так у них там давным давно Little-Endian во все поля и от Bie-Endian хлама они избавляются:

Which Linux distributions support little endian on Power

All three Linux on Power partners – Canonical, Red Hat, and SUSE – offer little endian distributions.

However, customers running big endian distributions would be wise to begin planning their transitions to little endian distributions as their applications become available and time permits.

IBM remains committed to transitioning the Linux on Power application ecosystem from big endian to little endian in an expeditious manner. Most IBM products have completed the transition and new products have started as little endian only.

Источник: https://developer.ibm.com/articles/l-power-little-endian-faq-trs/

Если посмотреть вендоров ПО – везде тоже предлагают только LE: https://ubuntu.com/download/server/power

Так и за каким хреном тогда в современном стандарте С++ сохранять UB под различные Big-Endian оптимизации, если Big-Endiand отвсюду выкинули?

Я не про PowerPC, я про z/Architecture (в Линуксе известна как s390x).

() -> T = {

ббблллдджээааддъъъ…

ббблллдджээааддъъъ это

template<class T>
std::enable_if<SomeFkInClass::SubTypeA, ...> SomeFkInClass::foo(T) const noexcept { ... }

template<class T>
decltype(auto) SomeFkInClass::bar(T) -> derive<T> { ... }

Modern C++ код уже читается как речь гопника, если заменять все auto на какое-нибудь матное слово.

Можно жизнь посвятить критике Си и C++.
Другой путь с их использованием разработать хорошие проекты.

В c++ как напишешь, так и будет.

Перефразируя,

C++ – это «болгарка».
Ада – это сабельная пила.

«IT-пильщики» платят безопасностью за эффективность.

Можно и так, но пила не должна быть «тупой».

это маловероятно, C++ развивается и эволюционирует, поэтому в среднесрочной перспективе уведание ему не страшно, а после выкрутасов Rust Foundation, является самой лучшей альтернативой

Мне идеи Zig импонируют (теоретически). Но его популяризация выглядит маловероятной.

const Allocator = @import("std").mem.Allocator;
const assert = @import("std").debug.assert;

const RingBuffer = @This();

data: []u8,
read_index: usize,
write_index: usize,

pub const Error = error{Full};

Разве это не ужасно?

data теперь не какая-то локальная переменная, а RingBuffer.data.

Запретить указатели и строки с массивами нефиксированной длины - и куча уязвимостей закроется.

Не закроется, а переместится на другой уровень абстракции, который программисты на этих языках уже не понимают. Именно поэтому выстрелы в ногу по NPE так распространены в языках «без указателей», но со «ссылочными типами» (т.е. неявно использующими указатели). Та же фигня с «чистыми функциями», точнее, притворяющимися таковыми, имея в основании полный побочных эффектов низкоуровневый код. Это не «решение», а «заметание под ковер».

Это не консенсус, а погоня за «тайм ту маркет», когда «решения» и «продукты» диктуются не программистами, а продажниками. Соответственно результаты отличаются от качественных программ, как «кефирный продуткт»(тм) от кефира.