#define X (MinGW)

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
hgm
Posts: 24605
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

#define X (MinGW)

Post by hgm » Thu Apr 06, 2017 7:42 am

I have a C program that contains #define X (and Y and N). It compiles fine under gcc on Linux (where I developed it). Because I want to make a Windows binary I tried to compile it under MinGW. To my dismay I get tons of error messages, for every line where the X occurs, that there is no opening parentheses after it. Apparently MinGW has a hard-coded definition of the macro X that it doesn't allow me to redefine or undefine. Now this is pretty annoying, because the code is splattered with occurrences of X and Y, and global substitution isn't an option, because the X and Y also frequently occur inside may other variable and macro names.

Does there exist an option to switch off this rogue behavior w.r.t. the X macro?

mar
Posts: 2122
Joined: Fri Nov 26, 2010 1:00 pm
Location: Czech Republic
Full name: Martin Sedlak

Re: #define X (MinGW)

Post by mar » Thu Apr 06, 2017 8:41 am

Hmm, that seems like a pretty weird behavior that would possibly break many programs.
I wonder if this code would compile fine in your MinGW?

Code: Select all

int X(int) {return 0;}
Maybe you could try to just preprocess to file to see to what it translates to?

elpapa
Posts: 203
Joined: Sun Jan 18, 2009 10:27 pm
Location: Sweden
Full name: Patrik Karlsson

Re: #define X (MinGW)

Post by elpapa » Thu Apr 06, 2017 10:39 am

hgm wrote:global substitution isn't an option, because the X and Y also frequently occur inside may other variable and macro names.
With regex you can do '\bX\b' and it will ignore X's having other letters before or after it. Most editors have an option 'match whole word only', which does the same thing.

User avatar
Evert
Posts: 2929
Joined: Fri Jan 21, 2011 11:42 pm
Location: NL
Contact:

Re: #define X (MinGW)

Post by Evert » Thu Apr 06, 2017 10:47 am

hgm wrote: Does there exist an option to switch off this rogue behavior w.r.t. the X macro?
Sounds like a compiler bug, but anyway try something like

Code: Select all

#define X _X_rename
#include "standardheaders"
#undef X
#define X ... // Your definition
at the top of your code.

syzygy
Posts: 4582
Joined: Tue Feb 28, 2012 10:56 pm

Re: #define X (MinGW)

Post by syzygy » Thu Apr 06, 2017 7:20 pm

Evert wrote:
hgm wrote: Does there exist an option to switch off this rogue behavior w.r.t. the X macro?
Sounds like a compiler bug, but anyway try something like

Code: Select all

#define X _X_rename
#include "standardheaders"
#undef X
#define X ... // Your definition
at the top of your code.
But that will not replace "#define X bla" that supposedly is present somewhere in the included headers with "#define _X_rename bla".

BeyondCritics
Posts: 359
Joined: Sat May 05, 2012 12:48 pm
Location: Bergheim

Re: #define X (MinGW)

Post by BeyondCritics » Thu Apr 06, 2017 8:52 pm

When i meet an annoying problem, i don't start to hack frantically my source base to get it out of the way. Instead i just let it go and the next day, when i am fresh, i analyze the problem very carefully.
You say, the compiler does not allow you to "undef" the symbol X.
The C standard http://en.cppreference.com/w/c/preprocessor/replace says, that an undef of an not existing symbol is just ignored.
Therefore i assume that you don't have a macro X, but a method with this name from somewhere included.
The very first step would be, to explore from where do you have this name and why. Any decent IDE will assist you with that.

User avatar
Evert
Posts: 2929
Joined: Fri Jan 21, 2011 11:42 pm
Location: NL
Contact:

Re: #define X (MinGW)

Post by Evert » Thu Apr 06, 2017 9:26 pm

syzygy wrote:
Evert wrote:
hgm wrote: Does there exist an option to switch off this rogue behavior w.r.t. the X macro?
Sounds like a compiler bug, but anyway try something like

Code: Select all

#define X _X_rename
#include "standardheaders"
#undef X
#define X ... // Your definition
at the top of your code.
But that will not replace "#define X bla" that supposedly is present somewhere in the included headers with "#define _X_rename bla".
Yes, that's true. I think I made a leap in logic because the compiler "not allowing to #undef the symbol" suggested to me that it wasn't actually a macro. Otherwise #undef X after including the headers should work.

Dann Corbit
Posts: 11169
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: #define X (MinGW)

Post by Dann Corbit » Thu Apr 06, 2017 10:40 pm

Make the smallest possible sample that reproduces the problem.
Post that here (code complete to reproduce).
I guess that there is a simple explanation.
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

Sven
Posts: 3853
Joined: Thu May 15, 2008 7:57 pm
Location: Berlin, Germany
Full name: Sven Schüle
Contact:

Re: #define X (MinGW)

Post by Sven » Thu Apr 06, 2017 11:00 pm

Dann Corbit wrote:Make the smallest possible sample that reproduces the problem.
Post that here (code complete to reproduce).
I guess that there is a simple explanation.
For me the most simple explanation would be that he defines the macro X somewhere in an own header file but afterwards (i.e., after including this own header file) includes a standard header that redefines (somewhere in its include chain) X (as a macro taking parameters, but that detail does not matter here). That way it would be impossible to solve the problem by doing an #undef anywhere.

The only solution that I see without renaming the own X macro would be to ensure that the standard header causing the problem (or a set of standard headers where one of them causes the problem) always gets included *before* defining the own X macro, and then doing an #undef *between* the #include and the own definition. Then the foreign X macro can't win due to the include guard of the standard header file.

Dann Corbit
Posts: 11169
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: #define X (MinGW)

Post by Dann Corbit » Fri Apr 07, 2017 1:42 am

Sven Schüle wrote:
Dann Corbit wrote:Make the smallest possible sample that reproduces the problem.
Post that here (code complete to reproduce).
I guess that there is a simple explanation.
For me the most simple explanation would be that he defines the macro X somewhere in an own header file but afterwards (i.e., after including this own header file) includes a standard header that redefines (somewhere in its include chain) X (as a macro taking parameters, but that detail does not matter here). That way it would be impossible to solve the problem by doing an #undef anywhere.

The only solution that I see without renaming the own X macro would be to ensure that the standard header causing the problem (or a set of standard headers where one of them causes the problem) always gets included *before* defining the own X macro, and then doing an #undef *between* the #include and the own definition. Then the foreign X macro can't win due to the include guard of the standard header file.
The compiler will show you all its macros.
For instance, with VC++ it is:

Code: Select all

cl /EP <filename>
and for gcc it is:

Code: Select all

gcc -E <filename>
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

Post Reply