I’m using an old m68k-elf-gcc that doesn’t support C99 on a project, with Eclipse Indigo Service Release 1 as my IDE. One of my cross-project header files has the following code which tests for C99, and if C99 is found, uses stdint.h, or if not, manually defines some of the fixed size _t types:
#if __STDC_VERSION__ >= 199901L /* C99, with support for stdint.h>. */
#include <stdint.h>
#else
/* Make sure to set these up correctly for your system if you don't have stdint.h. */
typedef unsigned short uint16_t;
typedef short int16_t;
typedef unsigned char uint8_t;
#endif
This compiles fine, and uses the lower section where stuff is manually set up. Eclipse’s indexer, however, insists that __STDC_VERSION__ exists, and in fact has the exact value 199901L (that value shows up when hovering the cursor over the macro name). This causes the Eclipse text editor and “Problems” tab to show errors on any line that uses the _t types, even though those lines compile fine.
I know it’s easy enough to work around this particular problem – erase everything but the manual typedefs from my header file – but I would really prefer that the Eclipse indexer have some relation to the compiler version I’m using. I have set the following project properties to make Eclipse aware that I’m using a different GCC:
- “C/C++ Build”->”Discovery Options:” Set the compiler invocation command to “m68k-elf-gcc”
- “C/C++ Build”->”Tool Chain Editor:” Set the “Current toolchain” to “Cross GCC”
These seem to have at least some of the desired effect, because the indexer references the correct system includes (goes to the m68k-elf-gcc include directories when perusing headers, not the “vanilla” GCC’s include directories), and the “Includes” and “Symbols” tabs on the “C/C++ General”->”Paths and Symbols” properties screen all match the m68k-elf-gcc stuff (and no, __STDC_VERSION__ is not listed in the Symbols list).
The actual value of
__STDC_VERSION__used by your compiler is invisible to Eclipse as it is a pre-defined macro rather than being defined in any header file. Eclipse must therefore be getting this value from somewhere else. I believe that it is defined internally within the CDT parser.