Запись портативной программы C - который вещи рассмотреть?

Я писал утилиты C, которые затем поддерживал на 16- и 64-битных архитектурах, в том числе на некоторых 60-битных машинах. Они включали по крайней мере три разновидности "порядка байтов", разные форматы с плавающей запятой, разные кодировки символов и разные операционные системы (хотя преобладала Unix).

1. Оставайтесь как можно ближе к стандарту C. Для функций / библиотек, не входящих в стандарт, используйте как можно более широко поддерживаемую базу кода. Например, для сети используйте интерфейс сокетов BSD с нулевым или минимальным использованием опций сокетов низкого уровня, внеполосной сигнализацией и т. Д. Для поддержки большого количества разнородных платформ с минимальным персоналом вам придется остаться с простыми ванильными функциями.
2. Будьте очень внимательны к тому, что гарантируется стандартом, а не к типичному поведению реализации. Например, указатели не обязательно имеют тот же размер, что и целые числа, а указатели на разные типы данных могут иметь разную длину. Если вы должны сделать предположения, зависящие от реализации, тщательно задокументируйте их. Lint, или --strict, или любой другой аналог, имеющийся в вашем наборе инструментов разработки, здесь жизненно важен.
3. Заголовочные файлы - ваш друг. Используйте макросы и константы, определенные в реализации.Используйте определения заголовков и #ifdef, чтобы изолировать те экземпляры, где вам нужно охватить небольшое количество альтернатив.
4. Не предполагайте, что текущая платформа использует символы EBCDIC и упакованные десятичные целые числа. Существует довольно много ASCII - машин с дополнением до двух. : -)

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

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

Числа по-разному представляются на двоичном уровне в разных архитектурах. В системах big-endian старший байт располагается первым, а в системах little-endian первым располагается младший байт.

Если вы запишете необработанные данные в файл в одном эндиане, а затем прочитаете этот файл обратно на системе с другим эндианом, у вас, очевидно, возникнут проблемы.

Вы должны быть в состоянии получить endianness во время компиляции на большинстве систем из sys/param.h. Если вам нужно определить ее во время выполнения, один из методов - использовать объединение int и char, затем установить char в 1 и посмотреть, какое значение имеет int.

1. Используйте как минимум два компилятора.
2. Иметь систему непрерывной сборки, которая предпочтительно строится на различных целевых платформах.
3. Если вам не нужно работать на очень низком уровне, попробуйте использовать какую-нибудь библиотеку, которая предоставляет абстракцию. Маловероятно, что вы не найдете сторонних библиотек, обеспечивающих хорошую абстракцию для того, что вам нужно. Например, для сети и связи есть ACE. Boost (например, файловая система) также перенесен на несколько платформ. Это библиотеки C ++, но могут быть и другие библиотеки C (например, curl).
4. Если вам нужно работать на низком уровне, имейте в виду, что платформы иногда ведут себя по-разному, даже в таких вещах, как posix, где они должны вести себя одинаково. Вы можете посмотреть исходный код указанных выше библиотек.

Это очень длинный список. Лучше всего читать примеры. Например, исходный текст perl. Если вы посмотрите на исходный текст perl, то увидите гигантский процесс создания заголовочного файла, который решает около 50 проблем платформы.

Прочтите его и прослезитесь, или возьмите взаймы.

Список может быть длинным, но он не настолько длинный, как поддержка Windows и MSDOS. Что характерно для многих утилит.

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

Дифференциация между несколькими разновидностями unix довольно проста. Либо придерживайтесь функций, для которых все используют одинаковые RTL-имена, либо смотрите на конвенцию большинства для поддерживаемых платформ и #ifdef в исключениях.

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