I got an odd message compiling a project for the PIC16F526. On COFF load after compiling, a message popped up stating that include statements were inside function definitions and that the debugger would not be able to find this included file. There are only 3 include statements and none were inside of any function. Anyone got an idea on what is happening?

The same project had no such warning message with MPLAB 8.20 and PICC Pro 9.60 PL4.

On further investigation, there is no such message with 9.60PL4 and earlier with MPLAB 8.30 with either the original or the rev A code. The message did pop up with 9.60PL5, 9.65, and with 9.65PL1.

The window is titled "Import COFF File" and the warning is "The project contains source files that use the #include directive from within a function to include source code. The debugger will not be able to find any variables in the included file."

It appears with either debug or release builds.

I thoroughly checked my source files for typo's and such and found none. Other projects with different controllers do not exhibit this behavior with the same compilers.

I have the same problem and it is a compiler bug or library issue. Not only do I never put #include directives in function bodies (though this should actually be technically (though not stylistically) acceptable) but I was not getting this error and then suddenly it started happening for no apparent reason. The only thing I can think of is that some minor edit I made triggered some different handling of the vendor-supplied library code which may have an #include directive inside a function. When this started happening I also found that I cannot set breakpoints in many places (the second 2/3 of the main project file)--very annoying to say the least.

There are so many bugs in this compiler that I no longer report them since they ignore, and I suspect, don't like me. For example, I also found today that the compiler chokes on a const int defined in a header and used as an array size specifier in another module. Unless I add +0 after the constant it reports that a constant expression is required--duh!

Quote:... the compiler chokes on a const int defined in a header and used as an array size specifier in another module.

From a forum standpoint, you providing compilable, testable evidence is best. For example, from what you have written here, I'd wonder if you were expecting features of a different language to be present in the C compiler you're complaining about.

Quote:... the compiler chokes on a const int defined in a header and used as an array size specifier in another module.

From a forum standpoint, you providing compilable, testable evidence is best. For example, from what you have written here, I'd wonder if you were expecting features of a different language to be present in the C compiler you're complaining about.

I don't know what you mean about expecting features of a different language. The C language certainly supports const int.

This in a header file: const int system_id_size = 8;

Used like this in a C file that includes the header (at the top of the file--not in a function body): unsigned char buf[system_id_size];

Generates an error saying that a constant expression is needed (bug 1). Adding +0 after system_id_size gets rid of the error, but, as I just discovered, results in the message about using an #include directive in a function body (bug 2 since there is certainly no include directive there). The result of that is that no breakpoints are possible in any code following the function.

As far as it being testable, I have found on a number of occasions that the compiler will have problems like this in one place, but similar code in another place will work. I realize that those kinds of bugs are difficult to fix because test cases are difficult to produce. However, I don't have the time to produce them, and I'm not willing to ship off my whole project.

Beyond that, I have found IMO that HI-TECH does not adequately test code. I conclude this since I found errors in their headers that would not compile (missing macro argument) and others (nearly all register addresses off by two) that show that basic checking was not done.

Also, since the last three or four bug reports I submitted did not even provoke the automated response, I think they must have put me on a spam list. :-) When I pointed out to them that my code and their own library code generates loads of bogus warnings when you turn up the warning level (as is normally good practice) they said that I should try a different compiler. Not a great sales tactic. Therefore, I am not submitting any more bug reports.