This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 182157 - #error pre-processor entry get an error in Netbeans 6.8
Summary: #error pre-processor entry get an error in Netbeans 6.8
Alias: None
Product: cnd
Classification: Unclassified
Component: Code Model (show other bugs)
Version: 6.x
Hardware: PC Solaris
: P3 normal (vote)
Assignee: Vladimir Voskresensky
Depends on:
Reported: 2010-03-16 19:46 UTC by lvskiprof
Modified: 2011-11-16 16:42 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

This file gives the error (in the block that I included in the comments) (49.19 KB, application/octet-stream)
2010-05-28 07:16 UTC, blaroche

Note You need to log in before you can comment on or make changes to this bug.
Description lvskiprof 2010-03-16 19:46:16 UTC
Here is a sample of some code that fails:

#if defined(UNIX)
         *mk = (struct keyword_node *) calloc(1, KEYWORDSIZE);
         (*mk)->keycode = 9;
         new_keyword = 1;
         convert_filename = 1;
         is_executable_name = 0;

         ci = &(get_src_group(_inline_+3, "LIB"))->libname;
#elif defined(NT)
         fprintf(stderr, "LIB is not supported on NT\n");
#error Unknown OS

The intent is that it should report the error "Unknown OS" if the pre-processor symbols UNIX and NT (in this case) were not defined.

What happens is that Netbeans reports that line as an error.  When you hover the mouse pointer over the red exclamation mark it says "Preprocessor stopped on this #error directive".

I tried commenting it out, but that seems to leave other code further down the line messed up, too.  In this case real C code lines (like : exit(1) gets reported that the function exit is undefined, which is simply wrong).
Comment 1 Vladimir Voskresensky 2010-03-17 05:17:48 UTC
If you compile you code you should see " Unknown OS" error and compilation would stop (because of preprocessor error)

Can you clarify what do you expect instead, please?
Comment 2 lvskiprof 2010-03-17 13:43:29 UTC
I would see that only if UNIX and NT were not defined.  In this case UNIX is defined.  There are similar lines in Solaris .h files:

> grep '#error' /usr/include/*.h
/usr/include/aio.h:#error	"POSIX Asynchronous I/O is not supported in POSIX.1-1990"
/usr/include/float.h:#error "Unknown architecture!"
/usr/include/gelf.h:#error "64-bit integer types are required by gelf."
/usr/include/libelf.h:#error "large files are not supported by libelf"
/usr/include/luaconf.h:#error "you must define LUA_BITSINT with number of bits in an integer"
/usr/include/meta_basic.h:#error "Compiling kernel file rpcgened without _KERNEL define."
/usr/include/mlib_types.h:#error  "unknown platform"
/usr/include/mqueue.h:#error	"POSIX Message Passing is not supported in POSIX.1-1990"
/usr/include/nan.h:/* #error is strictly ansi-C, but works as well as anything for K&R systems. */
/usr/include/nan.h:#error ISA not supported
/usr/include/pcsclite.h:#error BYTE is already defined
/usr/include/values.h:/* #error is strictly ansi-C, but works as well as anything for K&R systems. */
/usr/include/values.h:#error "ISA not supported"
/usr/include/xenctrl.h:#error "Define barriers"

It should not stop parsing at that point, but should continue, just as it does for a #if/#elif/#else/#endif construct.  The only time you can know which path is being taken is at compile time.

BTW - I am not sure if the issue with exit() being undefined later in the code is related to this issue or not at this point, but it might be a side effect, so I wanted to mention it.
Comment 3 Vladimir Voskresensky 2010-03-17 14:34:09 UTC
Some other questions to understand your environment:
- do you develop on Solaris for Solaris
or say
- you are on Windows and develop for Solaris

In fact preprocessor (when compile file) would definitely stop on #error directive and would not process lines below #error directive
=> you can:
1) manually add to project properties additional define directive
2) has two configurations (Solaris, Windows NT) - in one configuration there would be UNIX defined in other NT

Code assistance is trying to emulate your "compile time" environment.
So, it uses settings from toolchain defined in project properties.

See Tools->Options->C/C++->Code Assistance for toolchain to review #include directive folders and macros
Comment 4 lvskiprof 2010-03-17 15:39:18 UTC
I am building for Solaris on Solaris.  I have the latest Sun Studio installed on the system.  The code was indeed designed to build on multiple OSes originally, but now is only being built on Solaris.

Looking in the Code Assistance tab I see these directories being listed under Include Directories:

I won't bother with the macro list, but it looks like the standard list for Solaris compilers.  I do see __unix defined there.  The UNIX definition is from one of our header files.

I see where I can add the definition for the project, but it should have had that already from the include file the code was using.  If I define it in the project properties, does that add the definition to the compiler invocation line (-DUNIX for example)?

That might be a workaround, but the question is why did it not properly interpret the definition as it should?

If you need me to, I can try to reproduce it in a small code fragment that you can test with.
Comment 5 Vladimir Voskresensky 2010-03-17 17:10:56 UTC
If you have managed project => in defines defined in project properties are used to generate Makefile and they are used in compiler invocation.
If you have unmanaged project (project from Existing source) and all your compiler options are in your own Makefile => we can pick them using our discovery logic => all additional include directives && defines should be added into project properties under "Code Assistance" category.
If you have 
#define UNIX 
in one of included files => you can check path from source file, where
#ifdef UNIX
is used to your header file with #define UNIX

start with source file
in context menu->Navigate->Include Hierarchy 
in plain list look for your header (make sure you show all included files, not only one level)
then switch to tree view to see the include-way
Comment 6 lvskiprof 2010-03-20 18:55:03 UTC
I am still having problems with this.  Changing the Project Properties to have the include file directories is not working, for example.

I have tried it with both relative and absolute paths to the include directories we use.  It always claims that it can't find the include file.  It has no problems finding the system include files when you use <>, just our project ones where we use "".

I also am seeing bad behavior with the defined values I put in for the project.  I have the following list from the makefile:

-DRUN_X=1 -DX11=1 -DLITTLE_ENDIAN=1 -DSYSV=1 -DSYS5=1 -DSVR4=1 -DSUNOS=1 -DSUNOS5=1 -DSUNOS58=1 -Di386=1 -D__i386=1 -DINTEL=1 -DUNIX=1 -DSunOS_5x=1 -D__i386__=1 -DSunOS=1

I entered all those into the project properties (without the -D, of course).

Now I am creating a modified version of a file where I want my new code to be present for Solaris 8 and above, so I did a #ifdef-#else-#endif to preserve the old code that went like this:

#ifdef SUNOS58

The problem is that it shows the first section as grayed-out, as if it would not be compiled, and the second section as the active code.  I had to add a "#define SUNOS58 1" line at the top to get it to show up correctly.

It is almost as if it is taking the entries I put in the defined list and treating them the reverse of the way it should!
Comment 7 lvskiprof 2010-03-20 19:12:42 UTC
Okay, I figured out what I was doing wrong.  It is a user interface issue, as in the interface is not at all clear to the dumb user (me).

When you select the ellipsis button for either the Include or Preprocessor Definitions lists the dialog that comes up has a little checkbox down in the lower left that says: Inherit from project

Now to my way of thinking this implies that if I check that box all my files will "inherit" the settings I am defining here.  I resolved my issues by unchecking that box for both lists.  Once that was done the code is now being evaluated correctly and it is finding my project include files.

I now have now idea what the function of that checkbox is for, so I will try an look it up in the docs, but it probably needs to be made clearer with a better label.

I wish that I was seeing a list of my local include files the same way I do when for the system include files, but maybe that will happen if I restart the IDE after making this change.  Right now I am just happy that it is finally finding them!
Comment 8 Vladimir Voskresensky 2010-03-20 23:43:47 UTC
I'm glad you found the solution, but to be fair I do not understand how "unchecking" have resolved your issue especially for include directives :-)
by "unchecking" you have reduced the list of include paths => why it started to resolve #include directives?
Comment 9 lvskiprof 2010-03-22 13:24:41 UTC
I spoke too soon.  After my last comment I closed Netbeans and restarted it.  Once again it is behaving as before, unable to recognize the defined values or the include paths.  So this is still not working correctly, although it does occasionally work for reasons I don't understand just yet.
Comment 10 lvskiprof 2010-03-22 13:34:03 UTC
When I got back into the office today I verified that changing these settings, in this case setting the checkbox to be on, made my include files work.  But if my past experience is true, exit Netbeans and bring it back up and they will not be working again.

Once you have done that you have to close the file with the issue and re-open it for it to recognize the include file.  That behavior is also broken, as any change to the include or define lists should cause all open files to be re-scanned.

Strangely, for one file that included a project-specific include file it still did not find the include file.  I had all the paths as relative to the project start. For this file (one of 5 that I had open) I had to add the path as an absolute path before it properly saw the include file.  Again, broken behavior.

It seems that changing the checkbox is key to the issue, but what you change it to does seem to matter, just that you change it.

We are in the process of setting the code up on, so you should be able to download it and see the behavior for yourself a bit later.  On that site anyone can download a read-only copy, so access should not be a problem.  E-mail me directly at if you need to get a copy that allows you to see this behavior.  I am not certain that you would need it, but if you can't reproduce this behavior it is available, or will be soon.
Comment 11 Vladimir Voskresensky 2010-03-22 13:40:30 UTC
Please, send me your project privately or give the exact link on I will review your issue.

Btw, what do you see in tooltip when Ctrl+mouse over broken #include directive?
Comment 12 Vladimir Voskresensky 2010-04-25 13:23:40 UTC
Mike, have we solved the issue?
Comment 13 blaroche 2010-05-28 07:16:30 UTC
Created attachment 99583 [details]
This file gives the error (in the block that I included in the comments)

#       error "wxUSE_DYNLIB_CLASS must be defined."
#   else
#       define wxUSE_DYNLIB_CLASS 0
#   endif
#endif /* !defined(wxUSE_DYNLIB_CLASS) */
Comment 14 blaroche 2010-05-28 07:17:01 UTC
#       error "wxUSE_DYNLIB_CLASS must be defined."
#   else
#       define wxUSE_DYNLIB_CLASS 0
#   endif
#endif /* !defined(wxUSE_DYNLIB_CLASS) */
Comment 15 Vladimir Voskresensky 2010-10-27 09:02:45 UTC
(In reply to comment #13)
> Created an attachment (id=99583) [details]
> This file gives the error (in the block that I included in the comments)
> #ifndef wxUSE_DYNLIB_CLASS
> #       error "wxUSE_DYNLIB_CLASS must be defined."
> #   else
> #       define wxUSE_DYNLIB_CLASS 0
> #   endif
> #endif /* !defined(wxUSE_DYNLIB_CLASS) */
This is because your file contains 
on line 48 and macro wxUSE_DYNLIB_CLASS is not defined at the same time