C/C++ parser ignores includes with minus

[l_inc]

Hi everybody. I have CodeBlocks 13.12.svn.10538 on Fedora 22. <fcntl.h> includes <bits/fcntl.h>, which includes <bits/fcntl-linux.h>. Including <fcntl.h> in a cpp file does not allow to see the definitions from fcntl-linux.h unless I rename the latter into fcntl_linux.h and modify <bits/fcntl.h> accordingly.

Is that a one more bug, or am I missing something? Seems like a very common use case, and it's strange I couldn't find any related complaints on the forum.

[Manolo]

Yes, very common usage. I doubt it's a bug. Showing some sample code may put some light.
Anyhow, why do you think your problem is related to C:B?

[oBFusCATed]

l_inc can you provide a minimal self-contained project that can be used to reproduce the bug?

[l_inc]

oBFusCATed
Sure. Here's main.cbp:

Code

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_project_file>
	<FileVersion major="1" minor="6" />
	<Project>
		<Option title="main" />
		<Option pch_mode="2" />
		<Option compiler="gcc" />
		<Build>
			<Target title="Release">
				<Option output="main" prefix_auto="1" extension_auto="1" />
				<Option object_output="." />
				<Option type="1" />
				<Option compiler="gcc" />
				<Compiler>
					<Add option="-O2" />
					<Add directory="/usr/include" />
				</Compiler>
				<Linker>
					<Add option="-s" />
				</Linker>
			</Target>
		</Build>
		<Compiler>
			<Add option="-Wall" />
			<Add directory="/usr/include" />
		</Compiler>
		<Unit filename="main.cpp" />
		<Extensions>
			<code_completion>
				<search_path add="/usr/include" />
			</code_completion>
			<envvars />
			<debugger />
		</Extensions>
	</Project>
</CodeBlocks_project_file>

And here's main.cpp:

Code

#include <unistd.h>
#include <fcntl.h>

int main(int argc, char *argv[])
{
    int fdFile = open("/dev/urandom", O_RDONLY);
    close(fdFile);
    return 0;
}

Code completion as well as "Context Menu -> Find declaration of:" don't work on O_RDONLY. Both work OK however if I apply the modifications mentioned in the first post.

Manolo

Anyhow, why do you think your problem is related to C:B?

I'm gonna try to stay serious and ask, what else you think C::B parser problems could be related to.

[Manolo]

I copied & pasted your both files and tested them with C:B 13.12 (not nightly updates) in Ubuntu 14.04. Compilation and execution went smoothly. Also, O_RDONLY definition is found.

You may open a terminal and execute g++ -H main.cpp It will tell all included files. It this command fails, it's you gcc instalation, not C:B.

[oBFusCATed]

l_inc: By self-contained I've meant a project that doesn't depend on external files.

Manolo: Reread the first post, please.

[l_inc]

oBFusCATed
Sorry, I misunderstood you. All dependencies are included in the attachment. Same situation there: O_RDONLY not resolved unless the minus replaced.

Manolo
I don't have any problems compiling the project. Neither from the console nor from CodeBlocks. In Ubuntu the header fcntl-linux.h is indeed resolved by the C::B parser. Unfortunately I killed my Ubuntu installation before checking how it works with the attached project.

[oBFusCATed]

Still not minimal.
I can reproduce the problem.

ollydbg: Can you look at it?

[l_inc]

oBFusCATed

Still not minimal.

It's as minimal as I could get without taking a dive into the CodeBlocks source codes. I was unable to make the bug manifest in an artificial environment, so I decided to just cut it off the natural and hope it will behave deterministically.

[ollydbg]

Still not minimal.
I can reproduce the problem.

ollydbg: Can you look at it?

A little late response, sorry.
I just download the achieve file, and unzip it, and open the cbp inside the nightly build(rev10553), and right click on the context menu of main.cpp, and I can correctly jump to the definition of macro O_RDONLY inside the file "include\bits\fcntl-linux.h", the mouse hover messages also shows the definitions, see image shot below:


So, It works fine here on my test environment.

[l_inc]

ollydbg
It works for me in Windows either. I even mentioned that I had not been able to make the bug manifest in Ubuntu, so I was glad oBFusCATed confirmed it was reproducible. I think the only way to fix this is to debug it myself. But... is there any reason to continue supporting the plugin anyway, considering there is a more stable, more functional and much easier to maintain alternative?

[ollydbg]

ollydbg
It works for me in Windows either. I even mentioned that I had not been able to make the bug manifest in Ubuntu, so I was glad oBFusCATed confirmed it was reproducible. I think the only way to fix this is to debug it myself.

Debugging is not that hard, mainly, when you see a "#include xxxx" statement, you just call the "HandleInclude()" function inside the parser, and it should locate the "xxxx" file, and parse that included file.
The error mainly happens the file "xxxx" can't be found by CC, maybe, it does not know the search path?

But... is there any reason to continue supporting the plugin anyway, considering there is a more stable, more functional and much easier to maintain alternative?

If you looked a similar IDE(codelite), you will see it have two alternative cc engine, one is its native cc, and the other is the clang.

[l_inc]

ollydbg

Debugging is not that hard

Right. What's hard is to setup the environment with all those dependencies that need to be additionally compiled and installed. Btw. I've just overwrote my previous compilation just because I forgot to change the prefix, and spent some half an hour restoring it. Anyway, I can't reproduce the bug anymore. No idea, what made that happen. I did system update since then, installed many dependencies etc... could be anything.