Димыч писал(а):
Запустил vostok на маке под Clang.
Код:
+#if ... || defined(__APPLE__)
ЗдОрово, про мак я совсем забыл
Димыч писал(а):
Clang, похоже, очень трепетно относится к именам файлов, поэтому тест MathTest не собирается, ругается на -Wnonportable-include-path
Довольно странно, на моей памяти файловая система на макоси регистрозависимая, и тогда не должно было быть проблемы с
Код:
#include "Math.h"
На WINE тоже была проблема - из-за регистронезависимости было пересечение со стандартным math.h, но добавив явные определения стандартных функций, я решил эту проблему. Изначально она, вообще, решалась тем, что math и Math считались особыми словами и отображались в math_.h и Math_.h. Надо будет ещё подумать над этой проблемой в свете новой информации.
Цитата:
Переименованы файлы для компиляции с помощью CLANG
singularity/implementation/Math.c → singularity/implementation/O7Math.c
singularity/implementation/Math.h → singularity/implementation/O7Math.h
Непонятно за счёт чего такое переименование помогло пройти тесту. Обероновский модуль Math отображается на сишные Math.[hc] и транслятор подключает при трансляции соответствующие файлы. O7Мath.[hc] должны быть проигнорированы. Если это не так, то надо разбираться почему.
Цитата:
Кроме того, собирал так:
Код:
make test SANITIZE:=-std=c99
Похоже, что используется старая версия clang. В новых версиях и >=С99 стоит по умолчанию, и опции *sanitize* доступны. Или же это связано с тем, что clang в sanitize режиме некорректно отрабатывает как неопределённое поведение
Код:
((P*)NULL)->a
где а лежит по 0-му смещению
Это не принципиально, но с точки зрении задумки структуры Makefile, корректней запускать так:
Код:
make test SANITIZE:= OPT:=-std=c99
Также, я теперь больше использую для сборки модуль make.mod, написанный на самом Обероне, так как он работает и в WINE, и, наверно, в Windows, в отличии от Makefile.
Цитата:
Дополнительно изменил функции, связанные с undefined double и undefined float.
Как я понял, memcpy используется для записи в предоставленную ячейку значения, которое соответствует IEEE 754 NaN, но для этого в C99 есть соответствующая функция nan(), что я и использовал.
Не совсем. Это сигнальная неопределённость, то есть, такая, что должна приводить к АВОСТ при попытке работать со значением. Я хотел по максимуму использовать стандартные возможности. Стандарт упоминает о ней, но компиляторы на неё не обращает внимания, работая как с обычной неопределённостью, поэтому приходится делать проверку явно. Я придерживаю эту возможность для более продвинутых компиляторов, которые, возможно, появятся в будущем или, может, даже есть, к примеру, для Эльбруса. Я видел более цивилизованный способ задать битовое содержимое double, но упустил его из виду и руки пока не дошли. Также, я стараюсь использовать возможности более современных стандартов так, чтобы не блокировать возможность сбора под старый.
Цитата:
Попробую теперь собрать под Windows в Visual Studio, благо никаких сверхъестественных особенностей языка и ОС не используется.
Спасибо, у меня самого нет прямой возможности, а её создать мне не хватает желания.