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

Question

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

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

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

РЕДАКТИРОВАТЬ

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

_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);