#205 mingw, glut to freeglut breaks code using far and near as variable names

None
closed-invalid
nobody
None
5
2014-12-02
2013-12-04
David Mathog
No

Just my luck, the very first program I tried to use with freeglut on mingw uncovered an issue.

The pulsar.c program uses double variables "near" and "far". When compiled with glut.h (the real one) this is fine. When compiled with glut.h (from freeglut) the preprocessor converts this:

double near = 0.0;

to this

double = 0.0;

Tracked it down to windef.h where the lines:

#define far
#define near

are found. These are there to allow ancient 16 bit code to compile. windef.h is included by windows.h, which freeglut pulls in, but glut does not. pulsar is a command line program, so it doesn't really need anything from windows.h.

Not sure who/what supplies windef.h, either gcc or mingw. It is possible to leave it out with
-D_WINDEF_H on the command line, but since other programs might actually need something in windef.h, I am working around this by modifying my copy like this:

#if WINDOWS_16BIT
#define far
#endif

Until it is fixed generally perhaps this merits one line of warning somewhere in the readme.

Discussion

  • Hmm, classic GLUT avoids this problem by not including windows.h indeed, but instead it does a bunch of nasty defines itself. I'd like to avoid that, its a maintenance nightmare.

    I'll add a note to the docs indeed, thanks!

    Best,
    Dee

     
  • This is not really a bug of freeglut, it's a windows issue. Programs just shouldn't use near and far as identifiers if they are to work properly on windows.

    Feel free to open a feature request to "avoid including windows.h", but I'm not sure it's worth it really.

     
    • status: open --> closed-invalid
    • Group: -->