OberonCore

Такая фича есть в OO2C (с ограничениями).

Кстати, Александр. Я переписал Вашу утилиту ImportGraph при помощи Ofront+, теперь она может работать и под Linux, и под 64 бит. Это как пример, иллюстрирующий мой подход.

https://github.com/Oleg-N-Cher/OfrontPlus/blob/master/Mod/ImportGraph.cp

Внедрил в Ofront+ поддержку системных функций SYSTEM.THISRECORD, SYSTEM.THISARRAY и SYSTEM.TYP:

• https://github.com/Oleg-N-Cher/OfrontPlus/issues/104

Но я склоняюсь сейчас к тому, чтобы сократить THISRECORD / THISARRAY до THISREC / THISARR.

Из минусов — потеряется совместимость с BlackBox, но из оправданий — данные функции даже не документированы, а полной совместимости с BlackBox у Ofront'а+ не будет, т.к. я наверное всё-таки не планирую внедрять мета-информацию в модули, как делает это BlackBox. К тому же, в BlackBox есть флажок [callback], который в Ofront+ называется [stdcall], я считаю это более выразительным. Буду рад услышать ваши комментарии, особенно в пользу сокращения. Тем более, что в BlackBox уже есть ANYREC (а не ANYRECORD).

В целях автоматизации пересборки Ofront+ освоил онлайн-сервис Travis-CI. Теперь я делаю изменения в Ofront'е+, заливаю их в гитхаб, а трэвис сам скачивает себе проект и автоматически собирает для Linux, macOS и FreeBSD, а потом собранные бинари тоже заливает в гитхаб. Так что теперь появился реп специально для бутстрапных Си-файлов и собранных бинарей:

• https://github.com/Oleg-N-Cher/OfrontPlus-bootstrap

Здесь будет самый свежий набор раскруточных файлов, из которых можно получить сборку для Linux, macOS и FreeBSD любой разрядности. Но на трэвисе, к сожалению, из ходовых поддерживаются только архитектуры AMD64 и aarch64, но нет ни x86, ни armv7.

Для раскрутки (получения сишников) используется пилотная сборка Ofront+ для Win32, но я предпочитаю собирать её локально и руками, т.к. бывают нюансы. Версию для Win64 собрать тоже можно — соответствующие скрипты в репе имеются, но в этом нет особого смысла.

А из плюсов?

Из плюсов - более коротко. Ну и не ломает традицию: INTEGER, но SHORTINT (а не SHORTINTEGER). RECORD, но ANYREC (а не ANYRECORD).

Это не слишком широко используемые функции, до сих пор Ofront+ без них обходился.

Строковые операции в Ofront+ улучшены для повышения надёжности.

Ofront+ реализует бо́льший набор строковых операций, чем Ofront/voc. В частности, в Ofront+ есть системный тип POINTER TO ARRAY [untagged] OF CHAR, который является указателем на Си-строку, заканчивающуюся 0X (без сохранённой длины). Над такими строками можно делать ряд небезопасных операций: небезопасное вычисление длины, присвоение небезопасной строки безопасной строке, присвоение безопасной строки небезопасной строке. Всё это полезно для работы со сторонними библиотеками, разработанными на Си и других языках.

Улучшения:

Вместо __STRLEN для небезопасных Си-строк, завершающихся 0X, теперь используется функция __CSTRLEN. __STRLEN стала безопасной и получила второй параметр — максимальную длину строки. И теперь она проверяет наличие 0X в строке, а в случае его отсутствия будет трап.

В сообщении о языке Оберон чётко сказано, что строки всегда должны завершаться 0X.


Таким образом, если на вход LEN поступила строка без 0X, значит это не строка, а просто массив символов, для которого операция LEN не имеет смысла. И эту проблему важно диагностировать на как можно более ранней стадии разработки.

Дополнительные аргументы функций __STRLEN, __STRCOPY и __STRAPND — имя модуля и позиция в тексте для быстрого поиска ошибки.

Вот картинки, которые иллюстрируют, насколько операции со строками теперь безопаснее в Ofront+ по сравнению с CPfront:







На данный момент я считаю работу над строковыми операциями завершённой. Что ещё планируется — поддержка двухбайтового типа CHAR.

Библиотека Artemis Роберта Дойла (Robert Doiel), о которой он недавно писал в рассылке ETH, успешно собрана при помощи Ofront+.

Artemis разработана на Oberon-07.

• https://github.com/rsdoiel/Artemis/issues/2

На второй картинке в левом окне (то, что "сгенерировано Ofront+"), есть потенциально опасный код.

При объявлении

Код:

char* s ... ;

, стрОки

Код:

s = "11111111";
__MOVE("1111111", s, ...);

дадут ошибочное поведение или нарушение защиты на ряде систем.

Причина: литеральные строковые значения, навроде "111111111", обычно, располагаются компиляторами в области констант. И, опять-таки, обычно, это всё располагается в read-only memory областях. В правильных системах это - либо сегменты с доступом только для чтения, либо - флэш-память. То есть, мы: либо вылетаем по неправильной операции, либо - по нарушению доступа, либо постоянно начинаем ресетиться, если нет обработчика такой операции в случае некоторых встроенных систем. Или получаем неожиданное поведение самой программы, когда чтение из s будет давать значение по адресу последнего присвоенного литерала, не смотря на все последующие __MOVE-ы... если до того не рухнет от их последствий.

Влад, этот код написан не для исполнения. Просто показано, что такие операции возможны. Вы же предположили, что вот это будет исполняться последовательно?


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

Операции опасные, некрасивые, но увы - часто нужные. И в BlackBox/CPfront они поддержаны в той же мере.

Между первой и второй строчкой может быть очень много других строчек и программист может не отследить ситуацию со способом объявления s.... А потом - сильно удивляться. ))) Два раза, причём...

прикольный чувак этот Дойел: в одном модуле (Chars) константа MAXSET = 31, в другом (DStrings) - MAXSET = 32...
Не, я, конечно, понимаю, что - "модульность", "сокрытие информации" и - всё такое...
Ещё прикольней, что к каждому объявлению, в этих модулях, почти дословное объяснение добавлено о причинах ввода этой константы...
Понятно, что, если есть "костыль", который полезен для кучи мест, то - вынеси в общий файл с подобными объявлениями вспомогательного всего, что ПОЧТИ ВСЕГДА использоваться, БУДЕТ. Так оно ещё и значения разные имеет...
И это - только то, за что сразу "глаз зацепился", без "вникания в творение", таксать...

Ага. Я не вникал особо в его код, только пересобрал, ибо интересуюсь допилить Ofront+ до приемлемой поддержки Оберона-07. Так что изредка пробую им что-то собирать.

Таких дублирований констант в разных модулях полно и в компиляторе ББ (как он называется, opc, что ли), и в компиляторе Фокс от A2. Возможно, что это зачем-то нужно. А то, что они не совпали - ну что же, не ошибается только тот, кто ничего не делает.

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

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

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

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

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

Смотрите: в связи с описанным, не следует ли в оберон-сообществе кому-то (кто заинтересуется или у кого будут на это время, желание и силы) начать работу над логическим анализатором проектов на предмет анализа подобных случаев и ввести набор "хинтов от компилятора", как это сделано в Дельфи, например. Это поможет уменьшить вероятность похожих ошибок и огрехов.

Получается интересная коллизия.
С одной стороны, у нас есть конкретная реализация модульности в некотором языке, одним из следствий которой является возможность сокрытия информации и ограничения доступа (+ локализация эффектов воздействия и использования).
С другой, - мы открываем возможность "множественности трактований смыслов и содержаний" сущностей с одним и тем же именем. В данном случае - констант.
Интересно, что подобные проблемы возникают и у пользователей языка Си(++). Только обусловлены они прямо противоположными подходами и способами организации текстов программ и - полным отсутствием поддержки модульности. ))))) правда, касаются они не столько констант, сколько - переменных.

Экспериментирую с отсутствием разделителя ";" в диалекте Оберон-3. Компилится такое:



Навеяно Oberon+

Перевод строки становится значим для компилятора (как в Го) или нет?

В A2 есть Lax-режим, который делает то же самое. Но я не знаю, как он работает и не пользовался им.

Не становится. Лично я против того, чтобы форматирование текста влияло на логику кода.

Как оказалось, разделитель в виде ";" Оберону не особо нужен - и выпилить его из OP2 можно парой несложных правок.

Но ";" я не выпилил совсем, пусть остаётся необязательным. В т.ч. и для совместимости.