The OpenNET Project / Index page

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



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

"Проект TrapC развивает Си-подобный язык, безопасно работающий с памятью"  +/
Сообщение от opennews (??), 12-Ноя-24, 22:51 
Стартап Trasec развивает язык программирования TrapC, представляющий собой диалект языка Си, обеспечивающий безопасную работу с памятью. Для блокирования ошибок при работе с памятью, таких как выход за границы выделенного буфера, в TrapC применяется фундаментально иной способ работы с указателями и специальный механизм обработки ошибок. Заявлено, что особенности работы с указателями по возможности не будут нарушать привычный уклад и будут реализовываться на этапе  компиляции. Исходный код компилятора для TrapC планируют открыть в 2025 году...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62224

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

Оглавление

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


53. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +10 +/
Сообщение от solardiz (ok), 13-Ноя-24, 02:14 
Спросил автора Fil-C об отличиях проектов, вот его ответы:
https://x.com/solardiz/status/1856433226849628551
Filip Jerzy Pizło @filpizlo
The presentation is light on hardcore details and only has super simple examples, while Fil-C can run real big stuff (CPython, OpenSSH, etc). So, it’s not clear how it compares. Worth noting Fil-C is freely available today rather than sometime in the future!
The article says it’s a fork of the language and for example doesn’t allow unions at all. So, I think the biggest difference is that TrapC really is a different language. Fil-C, on the other hand, is just C (and unions are allowed, and they’re made safe).
Ответить | Правка | Наверх | Cообщить модератору

81. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +3 +/
Сообщение от Аноним (-), 13-Ноя-24, 08:16 
> Спросил автора Fil-C об отличиях проектов, вот его ответы:

А можете еще спросить...
1) Не хочет ли он нормальные типы с конкретными битностями по умолчанию, в том числе в препроцессоре, для избежания UB/vuln/кучи багов от "не того размера" int который себе представлял програмер? В хрусте очень правильно это сделали, имхо. И в C99 тоже, но пороху нормально сделать не хватило. И препроцессор например - грабель кусок. А 1, 1U, 1UL, и 1ULL это 4 довольно разные вещи.

2) Может, запретить к хренам signed как индекс массивов? Отрицательные индексы - ведут чаще всего к залетам.

3) Как насчет ЭНФОРСА (желательно компилтайм) значений в enum и bool? Сейчас enum совершенно бесполезен - мало того что хрен знает какого он типа, так еще если тип переменной enum, реально на вход функции можно любую труху давать - и как бы все ок.

4) Покажите ему MISRA C и Embedded C Coding standard. Может часть из этого стоило бы взять в оборот?

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

92. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +1 +/
Сообщение от Жироватт (ok), 13-Ноя-24, 09:06 
> 1) Не хочет ли он нормальные типы с конкретными битностями по умолчанию,

Тогда уж для всех платформ унифицировать примитивные типы по длине. А не как в стандарте и реализациях: для 32х бит int у нас 4 байта, для 64х бит int может быть как скрытой макрозаменой для int64 (8 байт), так и для int32 (4 байта), так и для int16 (2 байта), так и отдельным типом, который при флаге "--собирай-х64" неявно подставляется в таблицу символов и по нему уже выделяет память.

> 2) Может, запретить к хренам signed как индекс массивов? Отрицательные индексы - ведут чаще всего к залетам.

+1 шаг - отмаппить реальный диапазон массива на "безопасный" [0; N], что иногда неприемлемо с точки зрения оптимизации и понимания кода. Хотя бы для тех же координат.

> 3) Как насчет ЭНФОРСА (желательно компилтайм) значений в enum и bool? Сейчас enum совершенно бесполезен

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

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

107. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (-), 13-Ноя-24, 10:16 
> Тогда уж для всех платформ унифицировать примитивные типы по длине.

Ну так uint8_t из (>= C99) и аналогичных плюсов - везде и должен быть 8 битов ака 1 байт. И uint64_t - именно 64 бита а не что-то еще.

И это было бы прекрасно. Но тут на сцену выходит препроцессор. В котором тоже есть математика. И даже можно им делать вычисления. А теперь попробуйте угадать какие там разрядности и что оно РЕАЛЬНО будет делать.

Это же касается инициализаторов переменных. Особенно опосля препроцессора.

А с enum вообще мрак. Какой у него формально тип - да Ктулху бы его знает! Более того - никаких проверок что на вход функции хотевшей enum дали ессно нет.

Пример:


typedef my_t enum {
    VAL1 = 1,
    VAL2 = 2;
} my_t;

void something(my_t input) {
...
}

something(VAL1); // valid
something(VAL2); // valid
something(10); // WTF but who cares?!

> А не как в стандарте и реализациях: для 32х бит int у нас
> 4 байта, для 64х бит int может быть как скрытой макрозаменой
> для int64 (8 байт)

Ну так я про то и говорю. Вон то ведет к множеству залетов при портировани кода. Поэтому те кому важна стабильность, качество и безопасность, предсказуемые доступы и проч, скажем фирмвары мк и проч - юзают типы конкретного размера. Но вооооон то добро в препроцессоре и рядом - активно мешается на этом пути. Да, представляете конструкции типа (1 << 30), (1 << 61) и проч - выглядит вроде безобидно, но является куском грабель. С топоорм на ручке.

> +1 шаг - отмаппить реальный диапазон массива на "безопасный" [0; N], что
> иногда неприемлемо с точки зрения оптимизации и понимания кода. Хотя бы
> для тех же координат.

Компилер сам может прекрасно оптимизнуть такие вещи. А дереференс левых bounds это такая очень характерная трабла сей. Я тут как-то рефакторил старый код, который при определенном input радостно уходил в минуса по индексу и радостно телепал там хзчто в оперативе. При том это remotely triggerable было. Круто, да?

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

Выше характерный пример enum. Где он как бы есть, но реально - толку с него фиг. кто такой something(10) этом выражении? Была бы чуть менее тупая система типов - и компилер бы ЭТО поймал. Спросив что есть something(10) когда в том enum никогда не было задано число 10 и это явно невалидный вызов. Ибо callee имеет все основания ожидать только значения из того enum'а, согласно такой декларации, но сие никак не форсится. И это глупо - все инфо для этого в декларации есть. Если нечто рантайм-вычисляемо и в компиле не удается просчитать, сделать квалификатор типа constexpr'а, которым можно затребовать компилтайм просчет и фэйл если это не удалось.

> Бул? А зачем тащить в С бул, если уже написано куча BOOL-макросов
> и пользовательских структур?

В сях и так есть bool. Хотя в C23 его выпилили в пользу bit-exact, так что пристегните ремни. Зачем нужно?


uint8_t my_var = 255 + 1;
bool my_var2 = 255 + 1;

if (my_var) ..  // Вероятно програмер хотел сюда.
else ...        // А вы точно ожидали оказаться ТУТ булевской логикой?
if (my_var2) .. // А вот тут все нормально
else ...


(и все назначения крупнее 1 насколько я помню обрубаются до 1)
Ответить | Правка | Наверх | Cообщить модератору

116. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +1 +/
Сообщение от Жироватт (ok), 13-Ноя-24, 11:02 
А, понял. Ты про статическую проверку выборки индекса поля в enum'е. Ну, попутал с union, бывает, давно не работал. Ну тогда да.
Ответить | Правка | Наверх | Cообщить модератору

121. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (121), 13-Ноя-24, 11:41 
> А, понял. Ты про статическую проверку выборки индекса поля в enum'е. Ну,
> попутал с union, бывает, давно не работал. Ну тогда да.

Это как в том анекдоте - "и упаси тебя перепутать хиппи с толкиенистом". В случае сишника - ну я б еще понял struct и union перепутать (весьма чревато, как в анекдоте), но вот с enum - как?!

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

132. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +2 +/
Сообщение от Жироватт (ok), 13-Ноя-24, 14:57 
> Это как в том анекдоте - "и упаси тебя перепутать хиппи с толкиенистом".

Утро, кофе еще не до конца пошло по венам, разнося живительные молекулы по организму

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

100. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +1 +/
Сообщение от Совершенно другой аноним (?), 13-Ноя-24, 09:34 
Вроде с типом enum в C23 решили вопрос, можно задавать его базовый тип:

enum E1 : short { m11, m12 };

или Вы про другое?

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

108. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +2 +/
Сообщение от Аноним (-), 13-Ноя-24, 10:21 
> Вроде с типом enum в C23 решили вопрос, можно задавать его базовый
> тип:
> enum E1 : short { m11, m12 };

Это уже чуть лучше  чем было - но...

> или Вы про другое?

... я таки про - несколько другое. См выше пример с функцией получающей на вход enum, но реально можно вызвать something(10) коего в enum нет.

При том в сорце ЕСТЬ все аннотации намерений. И _можно_ определить в компилтайме что something(10) это нечто совершенно левое. Но нет. В лучшем случае это отловит какой-нибудь сильно отдельный статический анализатор.

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

142. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Совершенно другой аноним (?), 13-Ноя-24, 17:17 
> См выше пример с функцией получающей на вход enum, но реально можно вызвать something(10) коего в enum нет.

Да, согласен с Вами этого сильно не хватает. В C++ попытались решить эту проблему введя enum class, но в C, пока, на эту тему подвижек нет.

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

169. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +1 +/
Сообщение от Аноним (-), 14-Ноя-24, 07:52 
> Да, согласен с Вами этого сильно не хватает. В C++ попытались решить
> эту проблему введя enum class, но в C, пока, на эту
> тему подвижек нет.

Ну я и не понимаю - в чем прикол сделать перечисляемый тип, но вообще совсем никаких проверок не сделать, никак и нигде как mandatory в стандарте? Ведь 90% фичи - как бы есть. Но без остальных 10% толку то с нее такой? Гряблями по морде получить лишний раз? :)

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

175. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (175), 14-Ноя-24, 13:57 
enum это способ задать константу 100% без выделения памяти.
Ответить | Правка | Наверх | Cообщить модератору

176. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (176), 14-Ноя-24, 16:40 
> enum это способ задать константу 100% без выделения памяти.

Так ее можно и #define задать например. И даже в случае const - ниоткуда не следует что новая декларация ведет к новой аллокации. Какой-нибудь LTO вообще может иметь очень сильно свое мнение на этот счет. Сделав с кодом такое что вам и не снилось.

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

181. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (-), 14-Ноя-24, 21:52 
> И даже в случае const - ниоткуда не следует что новая декларация ведет к новой аллокации. Какой-нибудь LTO

Это он сейчас может, а когда C разрабатывался, const переменная означала статически выделенную память под эту переменную. Плюс const это всё же иное. Например, const обладает адресом. Const переменная рассматривается компилятором как lvalue, он может запрещать присвоение такому lvalue, но ты сам посмотри, он генерирует ошибки с другим текстом. Плюс эти запреты не столь строгие, и их можно обойти при желании.

> Так ее можно и #define задать например.

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

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

182. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (-), 14-Ноя-24, 22:03 
Та эта довольно просто. Если ты задумаешься как можно сделать не 90% фичи, а 100% фичи, то ты увидишь, что оставшиеся 10% сложнее первых 90%. Можно отгрызть 5% добавив статических проверок значений, которые кладутся в переменные типа enum, но это сработает только для случаев, когда статически известно, что кладётся недопустимое значение. А в случаях когда это неизвестно, что делать? Добавлять рантайм проверки? Допустим, но и что делать, если рантайм проверка провалилась? И одоление этих остающихся 5% потребует принятия спорных решений, например паник в рантайме, если в enum кладётся недопустимое значение. Или, например, добавление к каждому enum'у специального значения DefaultValue (или может его лучше назвать InvalidValue?) которое будет класться в enum вместо любого недопустимого значения. Придётся какие-то костыли изобретать.

> Ну и я и не понимаю - в чем прикол сделать перечисляемый тип

Я в школе не понимал в чём прикол enumeration в паскале. В C ты просто даёшь названия интересующим тебя int'ам, и потом работаешь с ними как с int'ами. Это делает код читаемее не создавая ненужных сложностей. В паскале же какие-то кошмарные сложности преобразовать значение enumeration в integer и обратно. Ну и я не понимал зачем такие enumeration нужны, когда проще насоздавать констант.

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

2. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от nc (ok), 12-Ноя-24, 23:01 
Самое главное непонятно - в чем именно заключается "фундаментально иной способ работы с указателями и специальный механизм обработки ошибок". Жирные указатели как в Cyclone?
Ответить | Правка | Наверх | Cообщить модератору

77. Скрыто модератором  +1 +/
Сообщение от помпезный (?), 13-Ноя-24, 07:37 
Ответить | Правка | Наверх | Cообщить модератору

84. Скрыто модератором  +/
Сообщение от Аноним (84), 13-Ноя-24, 08:50 
Ответить | Правка | Наверх | Cообщить модератору

96. Скрыто модератором  +1 +/
Сообщение от помпезный (?), 13-Ноя-24, 09:14 
Ответить | Правка | Наверх | Cообщить модератору

85. Скрыто модератором  +1 +/
Сообщение от Аноним (-), 13-Ноя-24, 08:57 
Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

98. Скрыто модератором  +2 +/
Сообщение от помпезный (?), 13-Ноя-24, 09:16 
Ответить | Правка | Наверх | Cообщить модератору

109. Скрыто модератором  –1 +/
Сообщение от Аноним (-), 13-Ноя-24, 10:24 
Ответить | Правка | Наверх | Cообщить модератору

114. Скрыто модератором  +1 +/
Сообщение от помпезный (?), 13-Ноя-24, 10:35 
Ответить | Правка | Наверх | Cообщить модератору

122. Скрыто модератором  +/
Сообщение от Аноним (-), 13-Ноя-24, 11:52 
Ответить | Правка | Наверх | Cообщить модератору

4. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +11 +/
Сообщение от Аноним Анонимович Анонимов (?), 12-Ноя-24, 23:07 
На моей памяти это уже не первая попытка исправить, «оберткой», чужой, прямо скажем, говнокод.

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

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

70. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +8 +/
Сообщение от Bottle (?), 13-Ноя-24, 06:09 
Зная говноделов в комитете, этот стандарт будут внедрять ещё один десяток лет, а софт нужно писать уже сейчас.
К тому же, обязательно напишут про implementation-defined behaviour. Т.е. стандарт опять окажется нерабочим дерьмом из разряда "А вот тут как хотите так и делайте. Кроссплатформенная арифметика? Нет, не слышали".
Ответить | Правка | Наверх | Cообщить модератору

133. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (133), 13-Ноя-24, 15:09 
Вроде всего третья попытка A, B+ и вот теперь C++
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

6. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +2 +/
Сообщение от Аноним (6), 12-Ноя-24, 23:12 
> Вместо malloc в TrapC используется похожий на C++ вызов new. Вызовы free и delete отсутствуют, так как за освобождение памяти отвечает компилятор, что защищает от ошибок, приводящих к утечке памяти.

И каким образом? Линейными типами? Ну я бы посмотрел, как они в С их добавят. ГЦ? Даже произносить смешно. Автофри, а-ля как в Vlang? Ну так он и работает только для примитивных случаев. Что-то сложнее уже сделать не получится (я пытался), разве что уговаривать компилятор, что ты мамой клянёшься, что освободишь память в конце. Ну, то есть, как ансейф в расте. Собственно, вопрос: а зачем тогда, а главное, на кой?

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

20. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  –1 +/
Сообщение от Аноним (20), 12-Ноя-24, 23:57 
В свифте сделали же автоматическое управление памятью без гц. И никаких боровов чекать не надо.
Ответить | Правка | Наверх | Cообщить модератору

30. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +1 +/
Сообщение от Аноним (30), 13-Ноя-24, 00:29 
> В свифте сделали же автоматическое управление памятью без гц.

Сделали, ага. Просто поменяли терминологию и (громко, во всех форумах и теле-инстаграмчиках) объявили "ARC - это не GC, вот!"

правда, на реальность это как-то не повлияло ...

https://docs.swift.org/swift-book/documentation/the-swift-pr.../
> How ARC Works
> Every time you create a new instance of a class, ARC allocates a chunk of memory to store information about that instance. This memory holds information about the type of the instance, together with the values of any stored properties associated with that instance.
> ...
> To make sure that instances don’t disappear while they’re still needed, ARC tracks how many properties, constants, and variables are currently referring to each class instance.

https://www.cs.cornell.edu/courses/cs6120/2019fa/blog/unifie.../
> Tracing and reference counting are normally viewed as the two main, completely different approaches to garbage collection.
>

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

49. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +3 +/
Сообщение от Аноним (49), 13-Ноя-24, 01:48 
Ну так в C++ тоже есть shared_ptr который делает то же самое. И никто не говорит что это GC. В р@сте тот же самый подход есть, аналог плюсовых shared_ptr и unique_ptr.
Ответить | Правка | Наверх | Cообщить модератору

161. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (30), 13-Ноя-24, 22:21 
> Ну так в C++ тоже есть shared_ptr который делает то же самое.
> И никто не говорит что это GC.

Как же вы, неучи-фанаты-ябла с альтернативной терминологией, надоели:
https://cplusplus.com/reference/memory/shared_ptr/
> Manages the storage of a pointer, providing a limited garbage-collection facility, possibly sharing that management with other objects.
>

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

79. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +1 +/
Сообщение от Пользователь (?), 13-Ноя-24, 07:59 
Как выше указали, ARC это подобие shared_ptr от Apple, в целом никакой магии.

Стоит отметить что в Swift активно агитируют использовать структуры везде где только можно

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

88. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (-), 13-Ноя-24, 08:59 
>> В свифте сделали же автоматическое управление памятью без гц.
> Сделали, ага. Просто поменяли терминологию и (громко, во всех форумах и теле-инстаграмчиках)
> объявили "ARC - это не GC, вот!"

Зашибись, а оверхед и непредсказуемость они под ковер как сныкали? :)

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

162. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (30), 13-Ноя-24, 22:26 
> Зашибись, а оверхед и непредсказуемость они под ковер как сныкали? :)

Оверхед - никак (у них там компилятор вставляет Inc_Ref(X)/Dec_Ref(X)), а вот с предсказуемостью у RC-сборщиков как раз все в полном порядке - вполне пригодны для RT-задач.

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

156. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (156), 13-Ноя-24, 21:11 
Ага, с утечками памяти при циклических ссылках
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

9. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от ijuij (?), 12-Ноя-24, 23:19 
Ну и зачем это? Уже пилят Safe C++: https://safecpp.org/
Ответить | Правка | Наверх | Cообщить модератору

66. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +12 +/
Сообщение от Аноним (66), 13-Ноя-24, 04:48 
initializer_list([T; dyn]^/a data) noexcept safe

using F4 = void/(a, b where a : b, b : a)(int^/a, int^/b) safe;

struct Pair/(T0.0.0, T1.0.0)<string_view/T0.0.0, string_view/T1.0.0>

П/ож/алуйст/а, не н/ад^о^

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

89. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +7 +/
Сообщение от Аноним (-), 13-Ноя-24, 09:01 
>
initializer_list([T; dyn]^/a data) noexcept safe 
> using F4 = void/(a, b where a : b, b : a)(int^/a,
> int^/b) safe;
> struct Pair/(T0.0.0, T1.0.0)<string_view/T0.0.0, string_view/T1.0.0>

> П/ож/алуйст/а, не н/ад^о^

Они, кажется, всерьез решили зарубиться с хрустиками на тему кто получит почетный титул брейнфак-2.0 :)

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

13. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  –4 +/
Сообщение от Аноним (13), 12-Ноя-24, 23:27 
Rust на минималках.
Ответить | Правка | Наверх | Cообщить модератору

134. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  –1 +/
Сообщение от Аноним (133), 13-Ноя-24, 15:10 
Совместимый по памяти и рантайму без этих всяких жужжаний про safe не safe
Ответить | Правка | Наверх | Cообщить модератору

32. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +4 +/
Сообщение от Аноним (32), 13-Ноя-24, 00:32 
"Answers the call from NSA, white house, fbi..."

Яснопонятно. Это кого надо инициатива, дед тут как Линус с Столманом - для ширмы

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

48. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  –1 +/
Сообщение от нах. (?), 13-Ноя-24, 01:13 
А, знач - хорошие сапоги, надо брать!

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

87. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  –1 +/
Сообщение от Аноним (84), 13-Ноя-24, 08:58 
Сапоги от NSA - лучше сапоги!

PS А от отечественного тащ майора ещё лучше.

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

135. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от VladSh (?), 13-Ноя-24, 15:13 
> // darpa_tractor.c

DARPA...

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

36. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  –1 +/
Сообщение от Аноним (36), 13-Ноя-24, 00:38 
Будет смешно, если из-за академичности и известности автора все эти zig и им подобные выставят на мороз и будут забыты.
Ответить | Правка | Наверх | Cообщить модератору

37. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +3 +/
Сообщение от Вы забыли заполнить поле Name (?), 13-Ноя-24, 00:41 
> академичности

Aкадемка обычно к успеху обычно не приходит. Из более-менее используемого ocaml. Всякие си, питоны и жс простите не из академки ни разу.

>  и известности

Настолько известный, что пришлось писать кто он и чем занимался.

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

60. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +2 +/
Сообщение от HyC (?), 13-Ноя-24, 03:16 
> Aкадемка обычно к успеху обычно не приходит. Из более-менее используемого ocaml. Всякие си, питоны и жс простите не из академки ни разу.

И все как на подбор кривые как турецкий ятаган.

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

67. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Вы забыли заполнить поле Name (?), 13-Ноя-24, 04:53 
>> Aкадемка обычно к успеху обычно не приходит. Из более-менее используемого ocaml. Всякие си, питоны и жс простите не из академки ни разу.
> И все как на подбор кривые как турецкий ятаган.

Чтож поделать. Взлетает почему-то именно такое.

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

91. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (-), 13-Ноя-24, 09:04 
> Чтож поделать. Взлетает почему-то именно такое.

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

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

95. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  –1 +/
Сообщение от Анониссимус (?), 13-Ноя-24, 09:13 
Во-первых, миллионы мух. А во-вторых, уж очень велик соблазн взять что-то из пары костылей, скреплённых дерьмом, но которое работает здесь и сейчас, вместо того чтобы доделывать более качественное решение.
Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

51. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Вася Пупкин (?), 13-Ноя-24, 01:51 
В языке сейчас важно сообщество и экосистема, не считая корневой идеи где он может быть удобно применен. Синтаксис и имя автора лишь могут немного поспособсвовать их становлению.
Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

97. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Анониссимус (?), 13-Ноя-24, 09:16 
Самое важое в любом языке -- это количество библиотек, которые можно использовать. Если там действительно можно использовать си-либы без всяких проблем, то пользоваться этим можно будет и с минимальным сообществом и экосистемой.
Ответить | Правка | Наверх | Cообщить модератору

73. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (73), 13-Ноя-24, 07:17 
Ну если предположить, что Си не из академки, то впоследствии стал использоваться академкой и много чего академического на нем было написано. Так что можно считать, что Си - академка.
Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

82. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Жироватт (ok), 13-Ноя-24, 08:26 
Удобно перехватил.
Ответить | Правка | Наверх | Cообщить модератору

124. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (124), 13-Ноя-24, 12:20 
>Так что можно считать, что Си - академка.

Т.е. C взял академический отпуск... от академиков.

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

118. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (118), 13-Ноя-24, 11:15 
Известности ноль. И уже есть Carbon.
Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

136. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (133), 13-Ноя-24, 15:13 
Carbon нихрена не собрать не затаoив половину Google к себе на домашний серверный шкаф из 40 серверов с дисковым массивом - шутка про Java и Gradle артефакты доставаемые гигабайтами какое-то невероятное зависимое говны.

Пока они не освоят хотя бы CMake не о чем говорить

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

143. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (143), 13-Ноя-24, 17:30 
Релиз в 27-м году. Осталось только подождать, затяните пояса.
Ответить | Правка | Наверх | Cообщить модератору

52. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +1 +/
Сообщение от htmldevelob (?), 13-Ноя-24, 01:51 
а вообще по теме мне кто то может пояснить что за вечная проблема с памятью ? в си и си++ и наверно в ассемблере нету такой проблемы ? а если есть может кто то тогда ассемблер сделает получше?
Ответить | Правка | Наверх | Cообщить модератору

58. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +4 +/
Сообщение от Йцукенг (?), 13-Ноя-24, 03:00 
Просто прочитайте, что такое переполнение буфера, висячие указатели, переполнение стека.

Программы на Си, на Си++ и, тем более, на ассемблерных языках имеют такие проблемы. Для борьбы с ними программист, который пишет на этих языках, должен вручную прописывать в коде дополнительные проверки и очень хорошо понимать, как его программа будет работать с памятью. И он должен нигде не ошибиться. Это трудно.

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

Про безопасные ассемлерные языки: В начале 2000-х был создан язык Сиклон (Cyclone), в котором часть проблем языка Си была устранена. Некоторые из авторов Сиклона участвовали также в работе над типизированным ассемблером TAL — Typed Assembly Language. Информация в сети есть.

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

78. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  –4 +/
Сообщение от Аноним (78), 13-Ноя-24, 07:39 
> В других языках такие проверки и работу с памятью обеспечивают компиляторы.

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

Это верно.

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

158. Скрыто модератором  +/
Сообщение от Аноним (156), 13-Ноя-24, 21:16 
Ответить | Правка | Наверх | Cообщить модератору

119. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +5 +/
Сообщение от Аноним (-), 13-Ноя-24, 11:20 
Основная проблема с памятью, что тебе надо дёрнуть free/delete на кусок памяти тогда и только тогда, когда этот кусок памяти перестаёт быть доступным для программы. Но языки программирования предлагают массу способов осложнить доказательство того, что кусок памяти перестаёт быть доступным. Указатель может где-нибудь сохраниться, в какой-нибудь структуре, допустим в каком-нибудь ивенте, который в какой-то очереди дожидается, когда он будет обработан. Динамические подходы к управлению памятью почти решают эту проблему, но даже они не идеальны, потому что программа может "забыть" обнулить какой-нибудь указатель, и динамические подходы к сборке мусора будут рассматривать это как наличие способа для программы поработать с данным куском памяти. Кроме того, не все сборщики мусора precise, часто производительности ради они действуют в разной степени консервативно и вычищают не весь мусор, только то, про что легко доказать, что это мусор. Счётчики ссылок же дополнительно создают проблем с циклическими ссылками. Впрочем, в языках со сборкой мусора, утечки памяти всё же редкость, потому что требуется довольно специальные условия, чтобы такое произошло. А use-after-free виртуально не существуют в них, потому что для этого нужен бажный сборщик мусора.

Есть простые способы эти проблемы одолевать статически, но эти простые способы ограничивают программиста. Например, можно делать free на кусок памяти всегда в той же функции, в которой этот кусок был выделен при помощи malloc. В таком случае проблема редуцируется к тому, чтобы не забывать на каждый malloc иметь free, и... ну прям скажем, даже это для программистов часто оказывается проблемой, но всё же это может сильно упростить жизнь. Точнее оно упрощает управление кучей, но усложняет жизнь другими способами, потому что например такой подход (если его применять строго) запрещает паттерн конструктора, который многократно дёргает malloc, и собирает какой-то сложный объект, допустим, берёт массив строк и делает red-black tree из строк: для такого дерева вызовы free для отдельных нодов дерева будут находится в других функциях, не в конструкторе.

Поэтому следующий напрашивающийся ход, начать усложнять простые способы, чтобы они всё же в меньшей степени ограничивали бы программиста. Например, мы можем создать класс функций-конструкторов, и класс функций деструкторов, и вместо того, чтобы отслеживать чтобы на каждый malloc был бы free, следить за тем, чтобы на каждый конструктор был бы деструктор. Таким образом мы можем обойти одну конкретную сложность с одним конкретным паттерном. Но паттернов больше, и если мы начнём со всеми паттернами так обходится, то мы получим что-нибудь типа раста, который начинает говорить об овнершипе и борровинге, присыпая это unsafe, потому что модель управления памятью в расте, вообще-то не позволяет реализовать даже такую простую штуку как динамический массив, приходится unsafe задействовать. Поэтому раст довольно сложно даётся C/C++ программистам, им приходится ломать привычки и отказываться от некоторых паттернов, которыми они пользуются не задумываясь.

> в си и си++ и наверно в ассемблере нету такой проблемы ?

В ассемблере нет, но если ассемблер применять так, как это принято нынче. То есть исключительно для того, чтобы оптимизировать "узкие" циклы. Если в цикле есть malloc/free, то это уже не узкий цикл, это уже гарантированно тормозной цикл, и переписывать его на ассемблере бессмысленно. Но зато, в ассемблере, могут возникать гораздо более забавные проблемы, когда ты в цикле делаешь push/pop, чтобы временно освободить регистр от значения, и в процессе рефакторинга кода нечаянно получаешь ситуацию с pop без соответствующего push, или наоборот, push без pop. Спектр возможных последствий такого неограничен, хотя в современных системах с memory management'ом, как правило всё завершается унылым сегфолтом. В DOS'е и win9x было гораздо интереснее по таким граблям ходить. Никогда не угадаешь, что получится.

Впрочем, я подозреваю, что современный ассемблер и push/pop не использует, они были полезны в древности, когда 360k памяти хватало для всех, и пара однобайтовых инструкций, позволяющая временно освободить дефицитный регистр для чего-то, была очень полезна.

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

171. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Анониматор (?), 14-Ноя-24, 08:02 
Никакой проблемы насамом деле нет. Сын учится в вышке, учат кондовый С на указателях и маллоках, причём всего за пару месяцев уже сильно далеко за пределами моего понимания. Любые утечки которые сдают студенты препод сразу видит. Дело в квалификации мне кажется.
Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

61. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  –1 +/
Сообщение от Аноним (61), 13-Ноя-24, 03:17 
> бывший профессор компьютерных наук

что за ...?

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

75. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (78), 13-Ноя-24, 07:23 
Карабас-Барабас - профессор кукольных наук. Всё нормально.
Ответить | Правка | Наверх | Cообщить модератору

83. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +1 +/
Сообщение от Жироватт (ok), 13-Ноя-24, 08:29 
Помнишь такого вот кривого доцента с кафедры АСУП, САПР или ВТ? Который в жизни не написал ничего реально применимого, но очень гордящегося своим алгоритмом подсчёта синуса от количества усов на морде среднестатистического кота? Такое же, только англоязычное.

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

101. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от eugene_martein (ok), 13-Ноя-24, 09:36 
Типа, как Зуев, который один год писал синтаксическое AST-дерево для несостоявшегося отечественного компилятора C++ в 90-ых, но получил такую психотравму, что по сей день орёт, что отечественный компилятор есть.
Ответить | Правка | Наверх | Cообщить модератору

115. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Жироватт (ok), 13-Ноя-24, 10:57 
Таких у нас вагон и полная тележка сверху.
Не пониманию я этого наяривания на "академичность". Хотя зубров, вроде Кнута, стоит исключить, там где серьёзный стык высшей математики и алгоритмов - от них и от их изысканий есть реальная польза, но вот остальное...
Ответить | Правка | Наверх | Cообщить модератору

138. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (138), 13-Ноя-24, 15:49 
> Не пониманию я этого наяривания на "академичность".

Она нужна тем кто хочет быть "услышен", а за других говорят их "дела".


> Хотя зубров, вроде Кнута, стоит исключить

Говорят, математика это язык природы, просто словарь этого языка переполнен "словами паразитами" ввиде имен всяких "профессоров".

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

69. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +1 +/
Сообщение от Аноним (69), 13-Ноя-24, 05:33 
Вообще интересно, но пока ещё сыро и не опенсорс.
Ответить | Правка | Наверх | Cообщить модератору

80. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +1 +/
Сообщение от КО (?), 13-Ноя-24, 08:11 
Пока сыро - это всё состояние опенсорса, так что вполне подходит
Ответить | Правка | Наверх | Cообщить модератору

105. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (78), 13-Ноя-24, 09:59 
> Пока сыро - это всё состояние опенсорса, так что вполне подходит

Неочевидно. GCC - опенсорс, но не сыро.

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

140. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (140), 13-Ноя-24, 16:11 
Как говорится, ничто не вечно, ничто не закончено и ничто не совершенно.
Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

145. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (145), 13-Ноя-24, 17:37 
А я бы стал утверждать, что программа достигает совершенства к ... концу развития. После чего выбрасывается, и всё начинается сначала. Потребуются примеры? Ну, NC и NU под MS-DOS, да и сама MS-DOS.
Ответить | Правка | Наверх | Cообщить модератору

164. "Проект TrapC развивает Си-подобный язык, безопасно..."  +/
Сообщение от arisu (ok), 13-Ноя-24, 23:25 
NC достиг совершенства в VC. ;-)

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

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

172. "Проект TrapC развивает Си-подобный язык, безопасно..."  +/
Сообщение от Incorporated (?), 14-Ноя-24, 08:05 
NC достиг совершенства в MC. ;-)
Cтаричок до сих пор живее всех живых с далекой середины 90-x!
И продолжает активно сопровождаться, в отличии от того же FAR
есть еще TC - но это оффтопик
Так что даже в деле классических файловых менеджеров семейства NC движуха идет и они показали свою востребованность сообществом
Ответить | Правка | Наверх | Cообщить модератору

173. "Проект TrapC развивает Си-подобный язык, безопасно..."  +/
Сообщение от arisu (ok), 14-Ноя-24, 08:35 
а MC не надо сопровождать никуда. последнее хорошее, что с ним случилось — это mc^2. который, естественно, в апстрим не взяли, и продолжают там заниматься ерундой. я этот самый mc^2 спокойно использую, и за восемь лет отсутствия очень необходимых сопровождений и обновлений весьма доволен.

была ещё, кстати, очень крутая штука — x northen captain. уже иксовая, но ещё приличная. жаль, что померла. я как-то думал её оживить, но традиционно заленился.

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

99. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +4 +/
Сообщение от Аноним (-), 13-Ноя-24, 09:32 
> Заявлено, что особенности работы с указателями по возможности не будут нарушать привычный уклад и будут реализовываться силами компилятора.

Ой не верится, что это возможно.

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

Чтобы это работало бы, компилятор должен знать про каждый выходящий из области видимости указатель, держит ли код овнершип на этот указатель, или получил его в результате борроуинга. В некоторых случаях это понятно: если код сделал malloc, и не передавал указатель никуда, то код владеет указателем. Но если код передавал указатель? Может он передал овнершип? Может указатель где-то сохранён? Или если код получил указатель через аргументы функции, ему его дали попользоваться, или отдали навсегда?

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

> Все создаваемые переменные и буферы явно инициализируются или заполняются нулями компилятором.

Rust тоже думал, что это ок. Что типа можно на кривой козе объехать накладные расходы на инициализацию памяти в тех случаях, когда она не нужна. Сейчас же в расте есть MaybeUninit, на те случаи, когда забить на накладные расходы нельзя и кривая коза не сработала. И прям скажем, MaybeUninit не для слабонервных.

И я отмечу, расту пришлось выкручиваться так, несмотря на то, что он value-oriented язык, он может "создать переменную" не выделяя/инициализируя память под неё, потому что память увязана со значениями, а не с переменными, и может передаваться из одной переменной в другую при присваивании. Здесь же, судя по лексике, язык остаётся variable-oriented, память ассоциируется с переменными, а это значит, что если я написал `int x;`, то семантически была выделена память плюс ещё и проинициализирована.

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

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

102. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +1 +/
Сообщение от Данные в так называемом поле Name (?), 13-Ноя-24, 09:39 
Я когда был маленький, мне казалось что мир информационных технологий огромен. Казалось, что на каждую, даже самую бредовую репу найдётся орда энтузиастов. Сейчас мнение поменял на прямо противоположное. Индустрия едет по рельсам, которые прокладывают некоторые сверх богатые компании. Смотрю как Oracle пыхтит пытаясь жабу тащить и как ему не хватает силёнок, чего уж говорить об энтузиастах? Короче, не знаю на что рассчитывает "бывший профессор", но безумству храбрых поём мы славу!
Ответить | Правка | Наверх | Cообщить модератору

111. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним55 (?), 13-Ноя-24, 10:26 
Увидел иронию в словах "бывший профессор". Но с другой стороны, когда в новом сезоне шоу под названием "университет", видимо для экономии средств, мне предложили из доцентов перейти в старшие преподаватели, наши пути в науке разошлись. Кто его знает, что там произошло.
Ответить | Правка | Наверх | Cообщить модератору

170. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (-), 14-Ноя-24, 07:55 
> Увидел иронию в словах "бывший профессор". Но с другой стороны, когда в
> новом сезоне шоу под названием "университет", видимо для экономии средств, мне
> предложили из доцентов перейти в старшие преподаватели, наши пути в науке
> разошлись. Кто его знает, что там произошло.

В смысле - что? По сторонам посмотри, прфоессор. Увидишь куда идут ломовые выплаты.

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

157. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (156), 13-Ноя-24, 21:13 
>Смотрю как Oracle пыхтит пытаясь жабу тащить и как ему не хватает силёнок, чего уж говорить об энтузиастах?

Можно подробнее?

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

103. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +1 +/
Сообщение от Аноним (103), 13-Ноя-24, 09:53 
А зачем тогда вообще Си? Открою секрет. Си изобрели, чтобы на ассемблере не писать. Еще тогда если вы хотели не скорости и компактности, а надежности и безопасности - могли писать на басике или паскале.
Ответить | Правка | Наверх | Cообщить модератору

141. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  –1 +/
Сообщение от Аноним (141), 13-Ноя-24, 16:28 
> Си изобрели, чтобы на ассемблере не писать

Your computer is not a fast PDP-11

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

155. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от нах. (?), 13-Ноя-24, 20:28 
>> Си изобрели, чтобы на ассемблере не писать
> Your computer is not a fast PDP-11

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

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

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

106. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Додо (ok), 13-Ноя-24, 10:13 
Глядя на примеры использования кажется, что их писал человек, который не понимает принципы работы с памятью вообще - но вместо того, чтобы учиться, он надеется на "безопасный" компилятор. На крайняк можно использовать любой статический анализатор - он подсветит нужные места и даст советы по исправлению.

// darpa_tractor.c

   int main(int argc,char* argv[])
   {  
           const size_t buff_size = 8; // Зададим размер буфера тут, чисто чтобы не пользоваться sizeof(buff) везде.
           char buff[buff_size];
           int success = 0;
           strncpy(buff, argv[1], buff_size); // Тут используем strncpy вместо strcpy.
           // Тут проверим последний элемент буфера.
           // Если при вызове strncpy исходная строка поместилась в буфер целиком,
           // то буфер будет заполнен нулями до конца. Если нет - то последний элемент будет не 0.
           // А вообще тут strcmp никогда не вернёт 0, потому что размер сравниваемой строки
           // больше размера буфера (если учитывать нулевой байт на конце).
           if(buff[buff_size - 1] == 0 && !strcmp(buff,"s3cr8tpw"))
           {      
                success = 1;    
           }    
           if(success) // TrapC blocked strcpy overwrite, success good    
           {      
                printf("Welcome!\n");    
           }      
           return !success;
   }

   // trapc_ptr.c

   int main()
   {  
           const char* ptr = "Hello World";
           // Тут просто меняем while на for (хотя лучше завести отдельную переменную для итерирования).
           for(; *ptr; ptr++)
           {      
                printf("%c",*ptr);
           }
           return 0;
   }

   // trapc_array.c

   int score[10];
   for (int i = 0; ; i++) {
        printf("%d", i);
        if (i == INT_MAX) break; // Переписываем цикл, вынося условие сюда.
   }

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

168. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Ivan_83 (ok), 14-Ноя-24, 02:31 
> const size_t buff_size = 8; // Зададим размер буфера тут, чисто чтобы не пользоваться sizeof(buff) везде.

По мне sizeof(buff) удобнее константы.
Хотя вероятно машинный код будет идентичный.


> strncpy(buff, argv[1], buff_size);

А кто будет проверять что argc >= 1?)

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

110. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  –1 +/
Сообщение от YetAnotherOnanym (ok), 13-Ноя-24, 10:25 
> Вызовы free и delete отсутствуют

Ну и зря.

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

120. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  –3 +/
Сообщение от X86 (ok), 13-Ноя-24, 11:26 
Это все пустое. Еще пара лет и нейронки смогут сделать простой и более безопасный язык программирования, взяв лучшее из Питонов и Си, разработать к нему понятную документацию и т.д.
Возможно, даже готовые бинари сразу из чатгпт можно будет скачивать)
Ответить | Правка | Наверх | Cообщить модератору

126. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (124), 13-Ноя-24, 12:36 
>Возможно, даже готовые бинари сразу из чатгпт можно будет скачивать)

Да, такие бинари, что всякие NSA курят в сторонке.

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

131. Скрыто модератором  +/
Сообщение от Аноним (131), 13-Ноя-24, 13:23 
Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

125. Скрыто модератором  +/
Сообщение от Аноним (-), 13-Ноя-24, 12:25 
Ответить | Правка | Наверх | Cообщить модератору

127. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +1 +/
Сообщение от Алексей (??), 13-Ноя-24, 12:40 
Проект конечно странный. Какие цели он проследует не понятно. По итогу это новый язык программирования с максимально похожим синтаксисом к C. И созданием данного языка они якобы решают проблему с памятью. Но в таком случае почему бы не пойти дальше улучшить в C еще что нибудь (и получить новый Zig, GO, V lang и тд и тп)?! Ведь по сути я не смогу взять TrapC и скомпилировать (без пердолинга) на нем кучу кода C получив при этом безопасные программы (а вот Fil-C вполне себе позволить это сделать хоть и в ущерб скорости)! Отсюда возникает вопрос: какая аудитория будет пользовался данным языком?! Трушные C/C++?! Так они не боятся утечек памяти и переполнения буфера и не будут переходить на TrapC. Всякие кому нравится C подобный синтаксис?! Так есть же 100500 C подобных языков без проблем с памятью (всякие Zig, Swift и тд и тп). Получается что они создают язык для себя чисто по фану. Ну, может конечно еще кто обзарится! Можно только пожелать им удачи в их трудном но интересном занятии.
Ответить | Правка | Наверх | Cообщить модератору

129. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +2 +/
Сообщение от Аноним (129), 13-Ноя-24, 13:03 
Зиг улучшил так улучшил, даже многострочные комменты вырезали
Ответить | Правка | Наверх | Cообщить модератору

146. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от anonimous (?), 13-Ноя-24, 17:54 
Цель понятная и они не не скрывают - найти инвесторов. Спрос есть? Будет и предложение!
Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

128. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (129), 13-Ноя-24, 13:02 
Стыдно признаваться будет, что используешь язык с таким названием
Ответить | Правка | Наверх | Cообщить модератору

137. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (133), 13-Ноя-24, 15:16 
Вы свои проблемы из Java не тащите.
Всем давно известно корреляция обратная.
Ответить | Правка | Наверх | Cообщить модератору

147. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +3 +/
Сообщение от Аноним (147), 13-Ноя-24, 18:00 
Кстати, интересная видеопрезентация, посмотрите кто не смотрел.
Ответить | Правка | Наверх | Cообщить модератору

151. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  –1 +/
Сообщение от Аноним (-), 13-Ноя-24, 18:22 
Есть безопасный диалект чистого Си, называется Cyclone. Последний стабильный релиз вышел в 2006 году. Диалект разрабатывали в стенах AT&T labs.

Разработчики TrapC велосипедят? Если уж на то пошло, взяли бы готовые наработки "Циклона".

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

159. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +1 +/
Сообщение от Аноним (156), 13-Ноя-24, 21:18 
>Как именно достигается подобная защита не поясняется.

Можно расходится, чуда не будет

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

160. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (156), 13-Ноя-24, 21:19 
Сколько уже языков изобретено, например тот же ATS? Осталось дело за малым - убедить погромистов на них писать.
Ответить | Правка | Наверх | Cообщить модератору

163. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +/
Сообщение от Аноним (163), 13-Ноя-24, 22:55 
Чем его РуСи Терехова не устроил?
Ответить | Правка | Наверх | Cообщить модератору

166. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +1 +/
Сообщение от _kp (ok), 13-Ноя-24, 23:42 
>>Вместо malloc .. new.. за освобождение памяти отвечает компилятор

Не понял шутку, типа еще на этапе компиляции виднее когда объект не будет нужен.

Тут, или не будет работать, или не освобождается память.
Более иого,даже со сборщиком мусора, ну не верится что оно будет предвидеть возникающие события, при которых надо освободить объект ;)

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

И изюминка на торте...
А зачем Си, почему не С++?
Что то низкоуровневое или высокопроизводительное все равно писать на обычных C и С++, а для более высокоуровнего кода С++ удобней.

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

178. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +1 +/
Сообщение от Аноним (-), 14-Ноя-24, 17:57 
>А зачем Си, почему не С++?

Ну так ты сам пиши на плюсах! Зачем других агитируешь-то?

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

167. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."  +1 +/
Сообщение от Ivan_83 (ok), 14-Ноя-24, 02:28 
> Все создаваемые переменные и буферы явно инициализируются или заполняются нулями компилятором.

Уже минус производительности.
Дебажные сборки С такое же делают, и кажется флаг для этого есть отдельный компелятору.


> Вызовы free и delete отсутствуют, а за освобождение памяти отвечает компилятор, что защищает от ошибок, приводящих к утечке памяти.

И откуда компелятору знать нужна мне эта память или уже нет?
Типа ссылки по указателям посчитать? - так а мне потом бегать всё занулять чтобы он память освободил?


Странное в общем оно.

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

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

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




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

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