Annoying syntax glitch?

[Labdabeta]

I just observed an unusual phenomena in my code. I am wondering if anyone can explain it.

void dofunc(int a, int b){a+=b;}
void foo(int near,int far){dofunc(near,far);}//Syntax error, expected primary expression before , and )
void poo(int vnear,int vfar){dofunc(vnear,vfar);}//Compiles fine?

[mrnutty]

void dofunc(int a, int b){a+=b;}
void foo(int near,int far){dofunc(near,far);}//Syntax error, expected primary expression before , and )
void poo(int vnear,int vfar){dofunc(vnear,vfar);}//Compiles fine?

int main(){}

that works fine for me? Whats the real code ?

[mike_2000_17]

far and near are reserved keywords in C (not standard, but common, it is a relic from the times of 16bit architectures), it is generally not present in C++, but it's possible that your particular compiler uses it in C++ for compatibility with C. That's the only explanation I can think of.

[Labdabeta]

That is certainly a possibility. They do seem to be acting as keywords.

[Salem]

> far and near are reserved keywords in C (not standard, but common, it is a relic from the times of 16bit architectures)
They're reserved identifiers only in compilers for the x86. C itself pre-dates DOS (and the x86), and didn't have these keywords. Likewise, compilers for other languages which ran on x86 also needed to know about the hacky segmented memory models.

What many modern compilers have in some system header file (particularly any with a DOS heritage) are

#define near /*not useful in 32-bit*/
#define far /*not useful in 32-bit*/

So that when used in the correct context, say far char *ptr; // 16-bit would become char *ptr; // 32-bit through the magic of the pre-processor.

But using them inappropriately, say void foo(int near,int far){dofunc(near,far);}//Syntax error, expected primary expression before , and ) expands to void foo(int ,int ){dofunc(,);}//Syntax error, expected primary expression before , and )