Что такое логика _PTR_?

Question

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

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 KiB памяти в то же время сохраняя преимущества 16 разрядных указателей для более быстрого кода/меньше использования памяти ,

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

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

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

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

Answer 2

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

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