Что стоит за _PTR_?

Question

Я работаю с исходной базой с неясным для меня правилом определения типов указателей: использую макрос _ PTR _ вместо *. Итак, все прототипы функций и typedefs выглядят так:

extern FILE_PTR    _io_fopen(const char _PTR_, const char _PTR_);

Интересно, в чем может быть причина этого, так как для меня это кажется чрезмерным.

EDIT

Кстати, для двойной косвенности я нашел:

_io_strtod(char _PTR_, char _PTR_ _PTR_);

Answer 1

Возможно, это определение для совместимости с DOS.

#ifdef DOS
#define _PTR_ far *
#else
#define _PTR_ *
#endif

Ключевые слова far / near позволяют указателям обращаться к памяти внутри / снаружи текущего сегмента, что позволяет программам обращаться к большему количеству64 КБ памяти, сохраняя при этом преимущества 16-битных указателей для более быстрого кода и меньшего использования памяти.

Более типично исключить * из определения.Например, в LibPNG вы можете увидеть определения, такие как:

typedef png_color FAR * png_colorp;
typedef png_color FAR * FAR * png_colorpp;

На большинстве платформ FAR будет #defined ничем.

Хотя DOS давно прошла, некоторые современныевстроенные архитектуры имеют схожие проблемы.Для процессоров Гарвардской архитектуры указатели на программы и память данных должны быть доступны с использованием разных инструкций, поэтому они имеют разные типы.Другие процессоры имеют разные «модели данных», и нередко можно видеть специальные типы указателей для указателей ниже 2 ^ 24, 2 ^ 16 или 2 ^ 8.

Answer 2

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

int _PTR_ arr = malloc(42 * sizeof _PTR_ arr);