What is the logic _PTR_?

I work with the source database with a rule that is not clear to me for determining pointer types: using the _PTR _ macro instead of * . So, all function prototypes and typedefs look like this:

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

I wonder what could be the reason for this, because to me it seems excessive.

EDIT

By the way, for double indirection, I found:

 _io_strtod(char _PTR_, char _PTR_ _PTR_); 
+4
source share
2 answers

It is possible that the definition is intended for compatibility with DOS.

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

The far / near keywords allow pointers to address memory inside / outside the current segment, which allows programs to address more than 64 kilobytes of memory, while preserving the benefits of 16-bit pointers for faster code usage / less memory.

It is more typical to exclude * from the definition. For example, in LibPNG you can see definitions such as:

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

On most far platforms, there will be #defined nothing.

Although DOS is long gone, some modern embedded architectures have similar problems. For Harvard architecture processors, program and data pointers must be accessible using different instructions, so they are of different types. Other processors have different "data models", and special types of pointers for pointers below 2 ^ 24, 2 ^ 16 or 2 ^ 8 are not uncommon.

+6
source

In order for a good agreement (for sufficiently small definitions to be easy) to distinguish between multiplication and indirectness

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

All Articles