默认是不选one ELF section per function的,这样只要添加了C文件,就会编译进入。如果选了这个选项,就不被编译进去。
当然也可以在单个C文件下对此C文件选择是否选择one ELF section per function。
Stirct ANSIC是很好的检测代码的一种方式。
目前我代码中有一些违反STRICT ANSIC,例如用了ASM汇编语句。
======================================================================================================================
又如:告警如下
nonstandard type for a bit field
在严格的C标准下,UNSINGNED SHORT INT 不能用field。
查了一下资料:
连接为:http://blog.csdn.net/sdhongjun/article/details/40040045
TI论坛关于此提示 http://e2e.ti.com/support/development_tools/compiler/f/343/t/91483.aspx
According to the C89 standard, which our compiler adheres to, "unsigned short" is not a standard type for bit fields. Some compilers may support it as a non standard extension, however that will make the code not guaranteed to be portable between compilers. Some discussion about it is here: http://processors.wiki.ti.com/index.php/C6000_EABI_Migration#Bit-Field_Layout
The -pr option(relaxed ANSI check) will help avoid the warning as it tells the compiler to not perform strict ANSI C checking.
Aarti never says it explicitly, but note that the TI compiler does support bit-fields with type unsigned short; it just warns that it is nonstandard (with respect to C89).
Bit-fields themselves are not all that portable because the rules for layout in memory allow some variation. Most compilers will support this kind of bit-field (and it is standard in C++). So portability is not likely to be further compromised by non-standard integral types in most situations.
Note that you can suppress just that specific warning with the -pds=232 option (long form: --diag_suppress=232) or by using the equivalent pragma in the source.
C89, C99, and C++ have different requirements for the declared type: