|
| From: | Hans Aberg |
| Subject: | Re: Interesting problem with bison on Windows |
| Date: | Fri, 19 Oct 2007 19:58:53 +0200 |
On 19 Oct 2007, at 17:41, address@hidden wrote:
I am running into an interesting problem on Windows with Bison 2.1. My grammar defines the word IN as a token. When I build on Windows, there is a file which includes the generated gram.h after including Microsoft's header WinDef.h. I'm using Visual Studio .NET 2003. Unfortunately, that header defines "IN": #define IN So, when compiling, the inclusion of gram.h gets an error due to the enum yytokentype which ends up getting the line for IN messed up during preprocessing: ... = 250, INTEGER = 251, ... I can undefine "IN" before the inclusion of gram.h which works, but is a bit hacky. I tried defining YYTOKENTYPE in the compile line (the enum is conditionalized with YYTOKENTYPE), but I got a link error when doing so. Any idea why defining YYTOKENTYPE in the compile line causes this problem? It sure looks like it's there for this reason.You might try #undef IN after the inclusion of your header that defines it. If you need the name, you might try #define INFOOBAR IN before the #undef. Otherwise, it is a problem of that header; get those who wrote it to fix it.
Yes, using "#undef IN" after the inclusion of WinDef.h works, but it seems like a bit of a hack. By getting "those who wrote it to fix it", if you mean WinDef.h, it's a header from Visual Studio. Somehow, I doubt that I could get Microsoft to "fix" that header.
Well, since it is rather amateurish to preprocessor macro short names that way, you could switch to another platform :-), ...
I'd still like to understand why defining YYTOKENTYPE on the command line broke the link. It sure looks like the code was written to give this option to not include the enum.
...or change the .y file so that the letter combination "IN" does not appear.
But, anyway, this is not a Bison issue. Hans Aberg
| [Prev in Thread] | Current Thread | [Next in Thread] |