Why can't Codan find size_t

Question

I\'ve just started using Eclipse Indigo (coming from Galileo) and I\'m getting little red bugs in the gutter for every use of size_t.

Answer 1

To make sure to get size_t you should #include the header <cstddef>; then, it would be std::size_t, unless you also put a using namespace std or a using std::size_t.

Answer 2

If your toolchain can compile the code with only its default include paths and symbols, just setting Eclipse to use them should be enough. Go to C/C++ Build -> Discovery Options in the project properties, and for each language, change the Compiler invocation command from the native compiler (e.g. g++) to your cross compiler (e.g. C:\nburn\gcc-m68k\bin\g++ perhaps?). Then on the next build, the auto-discovery will run and update the so-called "built-in" paths and symbols that show up in the project's C/C++ General -> Paths and Symbols to whatever your compiler reported, and you can re-index again to make sure any warnings for the old "built-ins" are gone.

Answer 3

After hitting this problem and a search revealing two stack overflow questions hitting the same problem, I figured I would submit how I fixed it after it annoyed me enough to actually investigate.

I'm running Fedora and annoyingly, it has a stddef.h file in /usr/include/linux.... which is actually empty. So even though I had the compiler's stddef.h in the include path, the indexer was actually parsing this other empty file. So what needed done was:

Prefix your paths and symbols list with the compiler specific include path (in my case it was /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/) to avoid the other empty stddef.h from being parsed.

Answer 4

Check your indexer settings under Preferences -> C/C++ -> Indexer.

There is a field there called "Filed to index up-front". Its contents should be:

cstdarg, stdarg.h, stddef.h, sys/resource.h, ctime, sys/types.h, signal.h, cstdio

If there is something else in there, try replacing it with the above, then rebuild the index, and see if that fixes the problem.

(In particular, if what you have in that field is stdarg.h, stddef.h, sys/types.h, then I have a pretty good guess as to what went wrong. Back in Eclipse Ganymede, the value of this field was stdarg.h, stddef.h, sys/types.h. In newer versions (Galileo and Indigo), it was changed to the above. However, since this field is part of "preferences", if you exported your Ganymede preferences and imported them into Galileo/Indigo, this field was overwritten with the old Ganymede value. I was burned by this a while ago.)

Answer 5

I actually had the same problem. The issue seemed to be the same like the one described in the post of fquinner, the stddef.h located in /usr/include/linux/stddef.h was empty as well. Strangely enough, the correct stddef.h was found by eclipse and even could be openened without any issues.

If you just need to fix the indexing by eclipse like me (for example when building with another build tool anyway), this indexing issue can be worked around by defining __SIZE_TYPE__ to the expected type, e.g. long unsigned int under C/C++ General -> Paths and Symbols.