Community
Participate
Working Groups
Codan does not resolve a field correctly in the following test case. This makes it unusable on OS X. Repeat by: 1. Create a new managed C project. 2. Add the following files: test.h: #ifndef TEST_H_ #define TEST_H_ #include <sys/select.h> struct foo { struct timeval select_timeout; }; typedef struct foo foo; #endif /* TEST_H_ */ test.c: #ifndef TEST_C_ #define TEST_C_ #include "test.h" int main() { foo* a; a->select_timeout.tv_sec = 10; return 0; } #endif /* TEST_C_ */ 3. Ensure codan is enabled in project properties 4. Run C/C++ code analysis Codan show the following error on line 17 of test.c: Description Resource Path Location Type tv_sec : field could not be resolved test.c /test line 10 Semantic Error Checking paths and symbols shows the following have been added automatically: /usr/local/include /usr/lib/gcc/i686-apple-darwin10/4.2.1/include /usr/include Open declaration on <sys/select.h> opens select.h. Open declaration on <sys/_structs.h> open _structs.h, however the macro "__need_struct_timespec" which was set in select.h (prior to including _structs.h) is no longer set in _structs.h. The code builds with no errors or warnings.
it is not codan per se. Could be scanner discovery - hard to tell based on the information in the pr, and I am not an indexer expert.
Works for me. I have the same includes. I have Xcode 3.2.5 with gcc version 4.2.1 (Apple Inc. build 5664). Try rebuilding the index maybe? I noticed that you can right-click on a file, Index, Create Parser Log file. Maybe that will help find the problem?
I found that the "Index source files not included in the build" option was unselected. When I select this option, the error is resolved. Does this mean that included header files are not considered part of the build, and are not indexed?
(In reply to comment #3) > I found that the "Index source files not included in the build" option was > unselected. When I select this option, the error is resolved. Does this mean > that included header files are not considered part of the build, and are not > indexed? Nope, headers are always indexed when they are included by some other file that is being indexed. Chances are, that your test-file was not indexed (because it was not considered part of the build).
Well, to the extent that I manually selected "Rebuild" from the index menu a number of times, it was indexed. But in any case, I'm not able to reproduce the problem any more. I can now create a new project and unselect this option, but it still seems to find the declaration. Perhaps playing around with the preferences reset something...
The same parser error exists on Eclipse Indigo under Linux. Under Eclipse Galileo I didn't get these problems. I took my workspace from Galileo to Indigo. Under Indigo, for some header file symbols seem to get "lost" during "C/C++ code analysis". Therefore I get the same errors: Description Resource Path Location Type Field 'tv_nsec' could not be resolved sample.c /sample line 79 Semantic Error ... In order to trace this, I typed the following at the top of some .c file of my project: #include <time.h> #ifndef _TIME_H #warning symbol gets lost #endif #include <errno.h> #ifndef _ERRNO_H #warning symbol does not get lost #endif The first warning is hit while the second is not which is reflected as soon as the texts are typed. This matches the analysis log file, which is also missing the lost symbols. My project compiles without warnings or errors. Must be a "spurious" bug of the analysis which always occurs with my current settings. I tried to change settings as described in the original PR but cannot get rid of the problem.
(In reply to comment #6) > The same parser error exists on Eclipse Indigo under Linux. Under Eclipse > Galileo I didn't get these problems. I took my workspace from Galileo to > Indigo. Is the problem reproducible in a fresh workspace?
I guess on some platforms we have troubles with parsing time.h, similar as in bug 347719 I guess you should be able to resolve the issue by adding time.h into the list of files parsed front up (Indexer preference setting). I guess (I have different system headers) it is best to insert it after <ctime>. If this does not work, move it as far to the front as necessary (but not any further): Try: cstdarg, stdarg.h, stddef.h, sys/resource.h, ctime, time.h, sys/types.h, signal.h, cstdio
Yes, your hint improves the parsing of time.h. The bad news is that I still get one related error: Description Resource Path Location Type Symbol 'CLOCK_MONOTONIC' could not be resolved sample.c /sample line 20 Semantic Error CLOCK_MONOTONIC is defined in linux/time.h. Any suggestions?
Don't know if it is worth mention, but adding time.h before sys/resource.h in "Files to idex up-front" list makes strange behaviour in my C++ project. Without this TIMER_* constants and clock_* functions are marked that they are not defined. After adding this, sometimes it works fine - no errors are present, and sometimes only TIMER_* are marked as they are not defined. I have noticed that if only TIMER_* are shown as not defined, restarting eclipse often makes it disappear (with added time.h). gcc version 4.4.5 (Ubuntu 10.10) eclipse 3.7 Indigo Service Release 1 Linux Developers version
I experience just the same bug with time.h when using Eclipse 3.7.1 Stable on my system. Should I report a new issue or would it be possible to use this one or reopen bug #347719? Problem is as follows: including time.h in pure-C linux code results in advanced things like nanosleep(), CLOCK_MONOTONIC and struct timespec to be unresolved by indexer. Adding time.h into list of the headers that should be indexed up-front just after the ctime improves situation a bit but still CLOCK_MONOTONIC remains unresolved. P.S. To enable usage of nanosleep and other fancy features I define _POSIX_C_SOURCE symbol equal to 199309L. Same effect might be achieved by defining _GNU_SOURCE but defining _POSIX_C_SOURCE provides more fine-graided control on what glibc subsets are being exposed so I prefer to use it instead of _GNU_SOURCE.
Update: In my case it was possible to workaround the problem by setting up-front parse list to this: cstdarg, stdarg.h, stddef.h, ctime, time.h, sys/resource.h, sys/types.h, signal.h, cstdio
With the fix for bug 197989 we no longer need to index files up-front. This should get rid of problems caused by variations in different system headers.
