New 'Bug Icon' and 'size_t' not recognized in rel_26

[Ridgeglider]

I'm importing a project that worked in previous releases to a workspace running under Rel_2_6_0_020. The project builds successfully. However, when I open files that use size_t in either a function declaration, or as an input parameter to a function, I get a new bug icon messages that 'size_t' could not be resolved. The file with the problem code #includes <stdio.h> so size_t should be recognized. Other functions like snprintf() and memcopy() that take an argument of type size_t also produce the bug icons and produce a '?' character in the hover box in the position of that parameter.

Several questions:
1) What's the new bug icon all about?
2) why isn't size_t recognized?
3) If it isn't recognized, why is the build successful?

Any thoughts?

bug igon and size_t.png (98.38 KiB) Viewed 5750 times

[tod]

What version of Eclipse are you using? This looks like the Codan (code analysis) feature (available in Helios and Indigo only I think). If you're using NBEclipse then I'd like to know that, sounds like the base release of Eclipse may have moved from Ganymede.

My guess on the error would be that you need to explicitly include some directory that Codan is not finding. If you aren't familiar with this topic I wrote up a blog entry on the process a few years back. I'm not sure where size_t lives.

[Ridgeglider]

Tod:
This is vanilla NB Rel_2_6_0_020 w/o any plugins which I think is based on Indigo.
Code Analysis shows up when right clicking on the project. No idea yet how to use it.

As for the error, size_t lives in several places: stdio.h, stdlib.h, etc, all of which should be readily available...? Still wondering how to fix, and why it could build successfully if this error is occurring?

Cheers!

Code Analysis.png (18.64 KiB) Viewed 5738 times

[Ridgeglider]

Here's a really simple, almost AppWiz-generated bit of code that exhibits the problem with size_t when it's used in the arguments in a declaration, or in the parameters passed to any function expecting an input of type size_t. The code compiles under 2.5.3, and the new Rel_2_6_0_020 . However, no errors are reported for 2.5.3, while two are reported for Rel_2_6_0_020. That's odd, because in Rel_2_6_0_020 the console reports a successful build despite the presence of 2 errors. (2.5.3 reports none.)

Finally, the error locations are immediately indicated by new 'bug icons' that appear as soon as 'size_t' is typed and even before a save is done. Maybe, as Tod suggested this is part of the Code Analysis that's available as I previously reported?

Last but not least, it's worth mentioning that size_t is declared in stdio.h, which in turn is #included in this code.

Here's the code:

Code: Select all

#include "predef.h"
#include <stdio.h>
#include <ctype.h>
#include <startnet.h>
#include <autoupdate.h>


extern "C" {
void UserMain(void * pd);
}

const char * AppName="size_t_Test";

//A fairly useless function that's passed an argument of type 'size_t'
void ShowInt( int n, size_t intsize) {
	iprintf("This int = %d takes %d bytes", n, intsize);
}

void UserMain(void * pd) {
    InitializeStack();
    OSChangePrio(MAIN_PRIO);
    EnableAutoUpdate();

    iprintf("Application started: %s\n", AppName);

    // a call to the function:
    int Test_int = 1;
    ShowInt(Test_int, sizeof(Test_int));

    while (1) {
    	OSTimeDly(20);
    }
}

and a screen shot of the bug icons and the errors...:

More_Size_t.png (52.47 KiB) Viewed 5731 times

[tod]

My memory is scary bad sometimes. A short while back (like April) I was testing out a beta of the NNDK because I was interested in Codan. It is a plug-in but it's probably part of the standard C++ version of Indigo. I ran across this EXACT problem. I knew your question sounded familiar. I just took the time today to go back and confirm. Check out this guy's question on StackOverflow , read the comments in the answer. You can pay me back by upvoting my question! Also while you're there upvote the answer.

Tod

[Forrest]

Tod:
As for the error, size_t lives in several places: stdio.h, stdlib.h, etc, all of which should be readily available...? Still wondering how to fix, and why it could build successfully if this error is occurring?

Code Analysis.png

Codan is a separate error reporting process from the build. The build errors are from gcc and will prevent the application from loading. Codan is static analysis of your code based on rules. The new release is based off Eclipse indigo, and Indigo CDT includes codan by default. In the beta, we are still testing whether to leave Codan enabled by default, so any input is nice to get.

[Ridgeglider]

Tod: Your stackoverflow post did the trick thanks! I owe you a beer (probably several by now)!

Forrest: I like the Code Analysis feature!!

The only thing I changed from the stackoverflow post is:
C:\nburn/gcc-m68k/lib/gcc/m68k-elf/4.2.1/include

instead of
C:\nburn\gcc-m68k\lib\gcc\m68k-elf\4.2.1\include\stddef.h.


Not sure what the deal is with / vs \ but I just copied the default format used for the other paths...

Finally, is there any way to make this addition to the path be the default for all projects?

size_t-Fix.png (38.38 KiB) Viewed 5718 times

[tod]

I don't know about all projects but you can do it for all projects for a single type of board. For example under MOD5270 you will find a file called PROPERTIES. Add this include line to the

Code: Select all

 NBINCLUDE=

line and all new MOD5270 projects will include it.

Forrest, I vote for keeping it enabled. Personally I'm a bit disappointed in Codan but it's better than nothing. If you're used to tools like lint or ReSharper, Codan doesn't come close but I have to hope that it's just going to get better.

EDIT
BTW - where you added the path didn't work for me when I had the problem I had to go up to the Indexer setting and set it there. If you click on the Configure Workspace Settings... it let's you set it for all your projects in the workspace.

Screen shot of Indexer settings

Indexer.png (77.79 KiB) Viewed 5709 times

[tod]

One more thing on Code Analysis. Under Window-Preferences->C/C++->Code Analysis you can customize some settings. Not only can you turn checks on/off, but even though it's not obvious you can double-click on a rule and modify it. For example the default method name rule is ^[a-z], you can change this to ^[A-Z] if you like to start method names with Capital letters. Plus it lets you brush up on your regular expressions.

Also once you change preferences for Code Analysis you have to make a change for it to rerun. Alternately when you open a file it appears to run code analysis. You'll notice it puts little icon overlays over files in the Project Explorer. Using the right-click menu on the project and using the Run Code Analysis shown in RidgeGlider's post will cause the analysis to be run on all files. I turned off the setting for requiring parentheses around return statements and all my little yellow marks went away. So it's a convenient way to clean things up fast.

There are also code analysis project settings. Under the project properties C/C++ General->Code Analysis. This allows you to select project or workspace settings for code analysis and in the case of the former you can customize the project settings.