Стартап Trasec приступил к разработке нового языка программирования TrapC, представляющего собой эволюционную форму С и С++, сообщает The Register. Его главная особенность в безопасной работе с памятью, которая закроет хакерам простор для творчества.
Стартап Trasec приступил к разработке нового языка программирования TrapC, представляющего собой эволюционную форму С и С++, сообщает The Register. Его главная особенность в безопасной работе с памятью, которая закроет хакерам простор для творчества.
Авторы TrapC предложили свой метод защиты от ошибок при работе с памятью, выход за границы буфера и попытку работы с уже высвобожденной памятью. Идея заключается в пересмотре алгоритмов работы с указателями памяти и создании нового механизма перехвата ошибок.
Этот механизм они предлагают базировать на так называемом «обработчике исключений» (trap), что отражено в названии языка. Также ведётся работа над компилятором для него, код которого авторы в будущем хотят сделать открытым. По плану это должно произойти в следующем году, но точной даты пока нет.
Все новые алгоритмы и механизмы защиты будут реализованы непосредственно в компиляторе. Они будут строго следить за границами выделенных буферов памяти и за тем, что указатели ссылаются только связанные с ними области памяти. Помимо этого, компилятор будет следить за применением типов и «ругаться» на небезопасное, по его оценке, их использование.
Разработчики TrapC стремятся сделать язык более простым, чем С или С++. В частности, в нём нет конструктора malloc — используется конструктор new. Также были исключены вызовы free и delete, а компилятору в числе прочего поручено отвечать за высвобождение памяти. Такой подход дополнительно повышает защиту от утечек памяти. В TrapC намного меньше ключевых слов, чем в С и С++. Так, в нём отсутствует ключевое слово union, применяемое для определения объединений. В то же время этот язык разработан для совместимости с C, поскольку он использует тот же двоичный интерфейс приложения.
У истоков стартапа Trasec, как и языка TrapC, стоит бывший профессор компьютерных наук и бывший член многочисленных комитетов по развитию стандартов С и С++ Робин Роу. Он также известен как соавтор знаменитого опенсорсного графического редактора Cinepaint, который применялся при создании графики примерно для 20 известных фильмов, в том числе «Двойного Форсажа», «Планеты обезьян», «Человека-Паука» и всех фильмов про Гарри Поттера. Помимо этого, Роу разрабатывал POSIX-библиотеку libunistd для Windows. В Trasec он выполняет роль гендиректора. Сейчас стартап занимается поиском инвесторов и сбором средств.
За проблемы с памятью С и С++ в последние годы открыто и всё громче ругают программисты и чиновники. Специалисты призывают избавиться от обоих языков и перейти на их безопасных для памяти конкурентов, а также переписать все проекты на них. Чаще всего в качестве безопасной альтернативы С и С++ упоминается Rust. Его уже предложено использовать для ядра Linux, а Microsoft задумывается о переписывании на нём части своих продуктов. Впрочем, среди программистов пока ещё много тех, кто не собирается отказываться от С и С++ в пользу Rust.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.
А мужики-то не знают...
чего не знают?
Ясно. Очередной неосилятор. Нет этих проблем уже 100 лет в обед. Откройте стандарт.
так С или С++?
В С++ тоже нет "конструктора malloc", если вдруг они не знают. malloc это банально функция из рантайма.
Шта? Ничо что выделенное через new полагается освобождать через delete?
Уф... Сразу на помоечку, ибо писать что либо системное на таком поделии будет сплошная боль.
В общем как всегда, С++ простудится на похоронах очередного "убивцы С++".
Почитал оригинал и там ещё веселее.
Очередной "езыг" созданный теоретиками для теоретиков.
"Решили" уже много лет как не существующую проблему но создали туеву хучу новых.
Можно закапывать.
Вообще то delete это перегружаемый оператор, а не вызов. Реализация по умолчанию опирается на free. Память выделяется не в момент компиляции, в момент выполнения, как компилятор освободит память которая будет выделена и освобождена на совершенно другой технике и в другое время? Наверное так неуклюже назвали сборщик мусора. Тогда зачем нам ещё один язык со сборщиком мусора, чем Java или новомодный Go не подходит?
Да пофиг всем на утечки. Практически любой С или C++ код имеет утечки ресурсов в том числе памяти, особенно при обработке ошибок и исключительных ситуаций. Но, эти утечки - они в сотни раз меньше чем "неутечки" в языках со сборщиком мусора из-за его отложенного запуска. Кроме того много много современных приложений запускаются и быстро помирают, и ОС за ними всю память освобождает.
Пользователь отредактировал комментарий 16 ноября 2024, 02:56
Согласен с тем, что ещё одни безумцы решили увеличить зоопарк языков.
Но не все приложения работают по принципу один раз запустил и вышел. Сервисные приложения в Linux/Windows. Любые сетевые сервисы при высокой нагрузки никто не будет останавливать. И это ещё не говоря про Embedded, когда это какое-то критическое устройство, в транспорте, медицине. Даже у мобильных ОС можно тоже сделать сервисные приложения, хотя пытаются всякими Deep Sleep подрезать им возможность постоянно висеть.
По мне это хороший тон, когда приложение умеет нормально управлять своими ресурсами. Взять например те же потоки, они должны уметь в нормальное время останавливать свою работу (если конечно это не супер критичная задача, которую им прям кровь с носа надо завершить перед остановкой), чтобы не пришлось принудительно килять. По моим наблюдением раньше с gaceful прерыванием работы было ещё хуже, чем сейчас. А отдать подчищать память ОС, это как вот отдают это на откуп сборщику мусора. Только при долго работающих приложениях ОС не спасёт.
Чего только не выдумают люди, лишь бы Rust не учить...
А в c++ нету како-то линтера, что бы проверял все ли выделение памяти освобождается?
Если чо, в С++ давно уже вручную память освобождают разве что в глубинах какого нить framework. Всё всегда завёрнуто, с голыми указателями наперевес никто не ходит.
Чтоб в современной С++ проге память потекла - это нонсенс. Не надо пускать сишников писать на плюсах - они пишут С программу с "кусочками фруктов", со всеми болячками С.
Утечки происходят во время исполнения, а не компиляции. Так что есть инструменты типа валгринда или там электрикфенса. Они работают в момент исполнения приложения
Пользователь отредактировал комментарий 17 ноября 2024, 20:49
Похоже что обратная совместимость с C очень ограничена, старые исходники на этом языке не соберёшь. Не взлетит.
Пользователь отредактировал комментарий 17 ноября 2024, 22:45