Weird #66 expected a ";" errors in CCS

#66 is probably the error number, not the line number where the error is found. In other words, #66 simply means an expected ";" not found.
(I do not use CCS, I am just guessing.)

The #66 indeed is a error number. The line number is 32.

Edit: I managed to solve the issue. The IDE reported the missing semicolon to be in four different files, but in reality the issue was only on one common header file. The project was previously compiled in IAR compiler and there was one IAR compiler specific tag in the header file which caused the original issue. So the compiler works ok, but there is something going on with the IDE itself.

When you include the header file in four different source files, then the compiler is called 4 times to compile a source file and finds the error in each one.

The compiler doesn't know that the error was in an include - the preprocessor has replaced the include instruction by the content of the included file before passing the source to the compiler. There are some mechanisms how the preprocessor can tell the compiler to still produce a meaningful error reference, but this mechanism sometimes fails (not only on CCS).

So it is normal that you got the error four times. For the compiler, these were four different, independent jobs, all containing an error.

Well, header files should be tested and error-free before being used. :)

It was really confusing that the IDE itself reported that the error was in the source files that included the header file with IAR tags instead of referring directly to the header file. When I copy-pasted the error from the error printout, there it referred correctly to the header file line 32 instead of line 32 of the source code files that called the faulty header.

I think the IDE's referencing got messed up because the header file that had the error was included in the project via the include directories defined in the compiler settings instead of directly adding the header file in the project. Well, it is not a first time Eclipse does something strange.

Juho Lepist��� said:

It was really confusing that the IDE itself reported that the error was in the source files that included the header file

In fact, that is perfectly common behaviour!

It'll be because the error didn't become apparent until that point in the including file.

As an exercise, you could try to find the option to show you the preprocessor output as the compiler sees it - then it should become clear why the error was reported at the point it was.

Note that this is a very powerful technique for debugging preprocessor problems like this!

http://www.8052.com/forum/read/29152

Juho Lepist��� said:

I think the IDE's referencing got messed up because the header file that had the error was included in the project via the include directories defined in the compiler settings instead of directly adding the header file in the project.

Very unlikely.

Andy Neil said:

you could try to find the option to show you the preprocessor output

I also don't use CCS - so I can't tell you what it is.

Look for something like "Show Preprocessor Output" or "Keep Preprocessor Output"...

 I am facing the same issue.I am compiling IAR code in CCS but i am facing the same issue.
 Can you tell me what is the IAR compiler specific tag and in which header file?
 What is the change you did to make it work(#66 expected a ";" problem).
 

vinoth s1 said:

 I am facing the same issue.I am compiling IAR code in CCS but i am facing the same issue.
 Can you tell me what is the IAR compiler specific tag and in which header file?
 What is the change you did to make it work(#66 expected a ";" problem).

I don't remember exactly. Probably __data20?

The compiler doesn’t really care for line feeds, they have no syntactical meaning to the compiler (but to the precompiler, they have). In theory, all code could be in one single line without making a difference. Or each word of an instruction can be in a different line.

A “missing ‘;’ “ error means that the code found in this line doesn’t make much sense to the compiler because between it and the stuff that was before, a proper separation (;) is missing.

True and those errors are caused by additional IAR-specific tags in the code, like the __data20 identifier, which triggers the error #66.

But returning to the original problem, though it is solved, I still think the CSS works unexpectedly and I'd call it a bug. Let's say that we have a following set of code:

1. On main.c line 150 we have following code:
uint8_t u8_variable = GARBAGE_DEFINE;

2. On other_source.c line 25 we have following code:
uint8_t u8_another_variable = GARBAGE_DEFINE;

2. The main.c and other_source.c have included Garbage.h which has a following deifinition on line 5:
#define GARBAGE_DEFINE this is total garbage and should trigger error

The logical way for the compiler to report the issue would be to report errors on the line 150 in main.c and on the line 25 in other_source.c, because that's where the error really is when the code is actually compiled. But instead of that CSS reports that both the main.c and other_source.c have an error on line 5, even those lines would be completely empty. That does not make any sense. The CSS is reporting the error on correct source files, but with the line number of the invalid definition in the included header file.

If you are unlucky, you will have code on the line that CSS reports the source of the error (e.g. on line 5 of main.c in our example) and that is really confusing and I'd definitely classify it as a bug. I've never seen any other compiler doing that.

You will need to provide a test case which illustrates your allegation.

As it is, I rather suspect you are misinterpreting the situation...

http://www.catb.org/esr/faqs/smart-questions.html#idp54032560 

Yes. Good point! I'll try to reproduce the problem when I have some extra time. I'm 100% sure that the error references were wrong. I suspect that the issue is related to importing and converting an old CCS project into a newer version that messed up the IDE's internal references/indexing somehow. It wouldn't be nothing new since Eclipse is known to have myriads of  similar issues, so this is more Eclipse bug than CCS bug.

The compiler gets the code it is compiling as one file. It does not know of include files. The precompiler is assembling the source code, makes the replacements for defines, includes header files, strips comments etc.
To support debuggin gin case of include files, the precompiler inserts information to the compiler that the following data comes from a different file, or that multiple lines belong to one source line due to macro expansion, or that multiple lines have been removed because of #ifdef. However, this mechanism is not fool-proof and sometimes, the compiler doesn’t interpret this information properly.

Example:

/*
this
is
some
comment
*/
code

That would be a valid theory if the erroneous line number wouldn't have been the same on all the source files the error was reported. The files had different injection points for the error, but still the error's line number was same in all the files and the same where the erroneous definition was in the header.

I've used CCS for years and I've never seen this kind of behaviour before. Also one weird thing was that the CCS didn't show the yellow formatting problem indicator in the editor side like it does when you have structural error in the code, like in this case the additional unknown identifier.

I did some googling to see if there has been this kind of issues on Eclipse side and there seemed to be quite a few similar issues where the IDE indexing has failed and the errors/warnings are not shown correctly. I need to dig up the old CCS project that had this issue and see if this is an known Eclipse bug. Could be that refreshing the project index would fix the issue. I don't remember did I try it.

Juho Lepist��� said:

That would be a valid theory if the erroneous line number wouldn't have been the same on all the source files the error was reported.

It could happen if you always have the same set of #includes at the start of each file..

I'd put very high odds on Viewing the preprocessor output being the key to this...