string.h errors

[davekelly]

I am porting one of my ByteCraft projects to CCS, V 3.249

Whenever I include the string.h header, I end up with >100 errors in this file alone, generally for 'Expecting a declaration' or 'Expecting a ('

The correct file is being included, as indicated in the MPLAB output window

Anyone have any ideas? I have spent years getting used to the quirks and bugs in the Bytecraft compiler, I hope there aren't as many issues with CCS!

[treitmey]

Like any trouble shooting, break the problem down.
comment everything out but a few lines and get that working the way
you think it should work. Then add some code. and repeat..

Thing is that when you fix a problem, you can fix all the others that are similar. And remember that 1 coding error can call out many errors.

I bet this won't be as bad as you think.

[davekelly]

The original file is just under 6000 lines long, so this is a big port!

For the previous version, I had written all of the library code myself (functions such as strcat, as well as I2C, LCD), as I ran out of ROM space and everything had to be customized.

With the CCS I wanted to use their libraries, and I have got down to less than 100 errors, but as soon as included the string.h file it alone generates 100 errors, on virtually every line.

As an example, the following function creates errors

[Ttelmah]

The 'normal' reason for this, is that there is a fault in one of the lines 'in front' of the include. The include is donw just as if the whole file was typed into the main program. If (for instance), a function declaration is performed, and not correctly formatted, in front of the include, all the functions in the include can give errors.
Start by laying out the front header of the program in the 'standard'CCS format:

include the chip definition file
setup fuses
set clock rate
define RS232/I2C etc., as required
include the other CCS libraries
Now have your type definitions/prototypes
Now have the code as such.

I suspect you will suddenly find the errors disappear from string.h, and appear further down the code.

Best Wishes

[davekelly]

Thankyou, you are right (about order).

I haven't found the problem yet, but the string.h is ok when included earlier on.