Compiler/EK-TM4C1294XL: C+ compiler directives code analysis errors

BP101 said:

Adding #include <string.h> or "string.h" all version CCS compilers and code analysis marks various inline C+ directives Errors

I'm not sure which code analysis tool you use.  Please show a screen shot, or something similar.

BP101 said:

Also c_str() or equivalent C+ directive seem to be missing from compiler tool chains 8.2.5

Do you have a source file which demonstrates this problem?  If so, for that source file, please follow the directions in the article How to Submit a Compiler Test Case.

Thanks and regards,

-George

Hi George,

Thanks for early reply:

George Mock said:

I'm not sure which code analysis tool you use.

CCS version 7.3 built in code analysis rules, not sure of any others.

George Mock said:

Also c_str() or equivalent C+ directive seem to be missing from compiler tool chains 8.2.5

Do you have a source file which demonstrates this problem?  If so, for that source file, please follow the directions in the article

First one was syntax related structure and the second C+ directive simply does not exist in the compiler. So I think the second CCS compiler directive may fill the void? Well anyway it then compiled successfully after replacing;  strchr(temp) for bad temp.c_str().

ret = strlen(temp); //temp.strlen()
ret = ret > len ? len : ret;
strncpy(buffer, strdup(temp), ret); //temp.c_str()

The odd part is the (strings.h) file is not changing from pink background to white. So it appears to anyone the symbol (_INLINE) is not having any effect. Adding a #define _INLINE to the c.file of reference, the pink remained too. I have noticed only local libraries or files that exist in the project root does the pink ever change to white background no matter CCS tools/include exists as a named include project path. Likewise the compiler library path is add to library path tab.

${CG_TOOL_ROOT}/lib/libc.a

${CG_TOOL_ROOT}/include

To make sure I understand the issue, are you saying that the Eclipse built-in code analysis is reporting errors in places where you would not expect any? If so, then the analysis tool may have been inadvertently turned on because by default, code analysis is disabled for CCS projects. 

Please see this page for more information and hopefully that explains the behavior you are seeing.

http://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_project-management.html#code-analysis

HI Arti,

No the workspace settings are enabled but I have checked launching tab run as you type so syntax errors are quickly revealed.

The syntax errors resulted from two issues, one for the way the call was formed via I believe an Arduino compiler. Secondly the C+ call to c_str() does not exist in any TM4S129x compiler versions. Next closest match found in (string.h); perhaps strdup() and have no idea if it is doing what c_str() originally was. It compiled without throwing any exceptions the second time around.

I'm somewhat confused at this issue since the library downloaded from Github was derived via C+ language. My CCS project preprocessors include: TI Assembler, GNU-C, GNU-C++ with CDT managed build setting entries for the previously posted CCS library inclusion paths.      

HI Arti,

Code check windows preferences  (Potential Programming Problems) was always showing with checks in boxes for CCS 5, 6,7,8,9. So I don't know why you believe it is some how being disabled during CCS install or even shipped that way. The only difference I have ever noticed in Errors/Console view after checking the launching as you type box under a projects advanced properties, syntax errors show a bug icon or warning next to the code in question.

So if I uncheck all the boxes, click apply and ave no idea about syntax errors until a compile is completed or errors out when all unchecked.  It would seem prudent to have C++ code analysis engaged and TI tool chain conforms to industry language format and rules relative to C+.

So far it seems that some thing in-between industry standard and mixed language syntax has occurred in CCS root compiler library or GNU updates. The syntax/code via compiler checking seems to get more intense with CCS higher versioning levels on the very same syntax below.  The same compiler version same code is failing only under later versions of the IDE, how on earth does that occur. Odd part is code analysis in CCS7.3 worked very well for the syntax below.

After unchecking all the analysis boxes under preferences, the same errors are appearing in CCS 8.3 for the syntax below fails to compile. Same code same compiler compiles without error CCS 9.1 but both versions have the same Class errors. (#20 identifier "class" is undefined).

#110 expression preceding parentheses of apparent call must have (pointer-to-) function type

//
// Get the value from the varargs.
//
ui32Value = va_arg(vaArgP, uint32_t);

 Hi ArtiG,

AartiG said:

However for CCS projects, by default, we internally disable the checks to avoid confusion for our users who are mostly developing for TI embedded parts using TI compiler tools and are more interested in the errors reported by our tools than generic Eclipse C/C++ dev tool errors. T

Ok you are referring to the work place settings being disabled but that is not so obvious. I always assumed workplace settings inferred windows preferences C++ code analysis settings. 

Even after unchecking all the analysis points under preferences the code analysis is still functional in the CCS project. So that must be the default tool chain C analysis you are referring remains active. That is what seems to cause issues when ever C++ directives along side C root library tool chain calls. TI compiler can not detect C from C++ directives existing together in the same source file. The latter gets to the point made in other thread (class) not being recognized even when file name ends (*.cpp) when C library tool chain calls also exist too. Oddly it seem to be one or the other language and not C & C++ directive existing together in the same source file.