11

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.

enter image description here

The code compiles without issue but I suspect I have to explicitly add a path to the include directories. I already have the usual suspects in there. I am cross compiling for a ColdFire processor using the Gnu tool chain so in addition to the standard include from mfg of the chip I have the includes under m68k-elf

\include  
\include\c++\4.2.1
\include\c++\4.2.1\include
\include\c++\4.2.1\m68k-elf

Update

I noticed that the only place stddef.h exists for this toolchain is in a lib directory

gcc-m68k\lib\gcc\m68k-elf\4.2.1\include

I added that path, the parent path and \include-fixed from the parent but the problem still exists.

Note on testing

When testing what works and what doesn't I noticed a couple of things

  1. Code analysis does not get re-triggered when modifying Code Analysis preference settings, I still need to make an editor change (simply adding a space works)
  2. Turning off the Code analysis setting for Symbol is not resolved will not make the error go away.
  3. Turning off all Syntax and Semantic Errors, triggering the analysis, going back in and turning them all back on and then turning off Symbol is not resolved keeps the error from reappearing.
Tod
  • 8,192
  • 5
  • 52
  • 93

5 Answers5

3

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.)

HighCommander4
  • 50,428
  • 24
  • 122
  • 194
  • Thanks but no such luck. I have the items you originally specified. I did try rebuilding the index but the problem persists. I've added to my directory paths just about every path I can find with include files but nothing has helped. I wonder if the way stddef.h defines it for this toolchain is fooling Codan. – Tod Apr 10 '12 at 20:27
  • "I've added to my directory paths just about every path I can find with include files but nothing has helped." -> It is conceivable that you have added too many include paths, which can be just as harmful as too few. Try running the command `echo | g++ -v -x c++ -E -`. About halfway down in the input, you will find a list of include directories. Make sure eclipse has precisely those ones (plus any additional include paths you pass to the compiler on the command line), nothing more and nothing less. – HighCommander4 Apr 10 '12 at 20:46
  • OK while not exactly the answer it got me there! I found my stddef.h in a strange location so I just explicitly added this hard-coded path `C:\nburn\gcc-m68k\lib\gcc\m68k-elf\4.2.1\include\stddef.h` and the problem went away. Having this path in the _C/C++ General->Paths and Symbols_ Project settings Includes tab was not enough. – Tod Apr 10 '12 at 20:52
  • Hmm... perhaps it was finding the wrong stddef.h at another path that appeared earlier on the include paths list. In any case, glad you solved it! By the way, if false positive Codan errors annoy you, you may want to consider upgrading to Juno when it comes out in a few months. There have been significant improvements to the indexer between Indigo and Juno, leading to a much reduced false positive rate. – HighCommander4 Apr 10 '12 at 20:56
  • Would you happen to know where this option stores its data? I just upgraded to Juno and noticed the option for "Files to index up-front" is gone. I'm not having a problem yet but when I do I'm wondering where I go to add files. – Tod Jul 12 '12 at 20:42
  • 1
    @Tod: In Juno, the bug that necessitated the existence of the "Files to index up-front" option in the first place (https://bugs.eclipse.org/bugs/show_bug.cgi?id=197989) was fixed - so you needn't worry about it any more! – HighCommander4 Jul 13 '12 at 00:02
  • 2
    Oh how I wish that were true! Today it showed up again. The identical problem, with size_t is back. I had to open a file that had a dependency on size_t but as soon as I did, dozens if not hundreds of false positive Codan errors showed up. – Tod Jul 14 '12 at 21:55
  • @Tod: Sorry to hear that :( My only suggestion is to open the file that defines size_t in eclipse (you may be able to do this by doing "Open Declaration" on a size_t in eclipse in spite of the fact that it's underlined in red) and see what's going on with the definition. It'll be a line like `typedef __SIZE_TYPE__ size_t;` or similar. Eclipse probbaly believes that either that line, or the line defining `__SIZE_TYPE__`, is in an inactive preprocessor branch, thus causing it to give the error. [to be continued] – HighCommander4 Jul 17 '12 at 03:33
  • [continued] You should be able to trace the problem back to some preprocessor symbol which should be defined but isn't, and then define that symbol manually in Project Properties -> C/C++ General -> Paths and Symbols. – HighCommander4 Jul 17 '12 at 03:34
  • Well, stddef.h for the gnu m68K cross compiler is somewhat of a nightmare. I counted 17 consecutive "#ifndef" statements prior to the typedef for size_t. Right at the top is `#if defined (_STDDEF_H) || defined (__need_size_t)` so I thought I would try and learn something and define __need_size_t. However, when I go to Project->Properties->Paths and Symbols I don't see anyplace to define symbols. All the tabs appear to be for adding paths.The first four are Libraries, Library Paths, Source Location, Output Location, the final tab is References. – Tod Jul 23 '12 at 21:31
  • That's strange, I have two addition tabs named 'Includes' and 'Symbols' at the beginning. Do you have a page under "Paths and Symbols" called "Preprocessor Include Paths, Macros etc."? It's something new in Juno, I think it's meant to replace the old way of defining paths and symbols. Try adding a Preprocessor Macro under CDT User Setting Entries (be sure to select C++ as the language). – HighCommander4 Jul 23 '12 at 22:01
2

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.

Matteo Italia
  • 123,740
  • 17
  • 206
  • 299
  • 1
    Thanks but it didn't help. I included cstddef added the std:: namespace, recompiled and no compiler errors but still have the red gutter bug from Codan. – Tod Apr 10 '12 at 19:49
1

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.

rakslice
  • 8,742
  • 4
  • 53
  • 57
1

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.

fquinner
  • 548
  • 5
  • 16
0

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.

Marian
  • 325
  • 2
  • 12