Предложение по контролю неопределённого поведения в Си

Позволит ли это программистам на Си наконец перестать портить память?

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

Нинужно. Филейные части сишника должны страдать за его ошибки.

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

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

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

Нет.

Позволит ли это программистам на Си

Может и позволит. Но мы не захотим.

Что-то аналогичное поведению c++ в constexpr функциях нужно.
В constexpr правда всё реализуется в компилтайме, а для реализации подобного в рантайме потребуются рантаймовые проверки

Позволит ли это программистам на Си наконец перестать портить память?

Нет конечно, желающие насрать каким-нибудь UB всегда найдутся, даже если возможность это сделать запрячут за семью печатями. Чего стоит проект на rust, использующий DefaultHash в сетевом протоколе... Запретили им срать в память, они в логику насрали

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

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

Ну и ладно, зато программа просто сразу упадёт, а не насрёт мимо буфера. Это уже будет намного лучше.

Что-то аналогичное поведению c++ в constexpr функциях нужно.

Например… constexpr?

https://en.cppreference.com/w/c/language/constexpr

Он в сишечке уже есть. Правда, как и всё в Си, урезанное до полного убожества. Функции в си не могут быть constexpr, например. Только переменные.

Нет конечно, желающие насрать каким-нибудь UB всегда найдутся, даже если возможность это сделать запрячут за семью печатями. Чего стоит проект на rust, использующий DefaultHash в сетевом протоколе… Запретили им срать в память, они в логику насрали

А где там UB? Присунуть рандом по сети – это не UB, это просто тупняк.

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

Так оно ж тогда будет определённым.

Чего стоит проект на rust, использующий DefaultHash в сетевом протоколе

Вы б хоть объяснили шутку для тех, кто этот ваш раст трёхметровой палкой трогать не хочет

The internal algorithm is not specified, and so it and its hashes should not be relied upon over releases.

Шутки нет. Это просто тупой баг.

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

Сложение запрещается?

Я имею в виду поведение компилятора, когда он компилирует компилтаймовый вызов constexpr функции. В этом случае он не допускает никакие UB. Например, записать один член юниона, а прочитать другой нельзя. До c++20/23 не было способа получить битовое представление float/double - т.к все привычные способы это сделать - UB. Числовое значение указателя тоже нельзя получить, хотя указатели там есть. Доступ к массивам (в том числе через адресную арифметику) проверяется. Такой вот safe c++, жалко, только для constexpr

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

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

Обычное через +. Юзай ckd_add().

Что думаешь, ЛОРовец? Позволит ли это программистам на Си наконец перестать портить память?

Алгоритм будет примерно такой:

1. прописал MEMORY_SAFETY STATIC
2. запустил компиляцию
3. заплакал

Позволит ли это программистам на Си наконец перестать портить память?

Нет, конечно. UB причина не всех порч памяти. Я просто делаю баг с адресной арифметикой, и без всяких UB память переписывается где не надо. Или утечка памяти. Какое UB заставляет меня не освободить память в нужном месте?

Что-то мне кажется, что включение MEMORY_SAFETY для уже существующего проекта будет не менее интересным экспириенсом чем превращение того же проекта в MISRA-conform

Я просто делаю баг с адресной арифметикой, и без всяких UB память переписывается где не надо.

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

Или утечка памяти. Какое UB заставляет меня не освободить память в нужном месте?

Утечка памяти не приводит к порче.

и в рамках арифметики ты можешь только в пределах одного массива туда-сюда указатель катать

Или за пределами…

Утечка памяти не приводит к порче.

Хорошо, хрен с ней, утечкой. Как на счёт use-after-free?

Хорошо, хрен с ней, утечкой. Как на счёт use-after-free?

Это UB.

Причина не UB.

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