The nxstyle check tool recognizes the division operator as
a comment. Check the following content to determine whether
it is a comment.
Change-Id: Id07c6668489895b45a1042794bc3acca66cd3c47
Signed-off-by: yangjiukui <yangjiukui@xiaomi.com>
This resolves issue 718: nxstyle line width check was ignoring the line width check for single line comments.
This turned out to be an artifact in parsing. Usually when parsing character by character, the file character to be parsed was '/n'. Howefver, in the case of parsing single line comments, the final character was the NUL terminator. This means that the lenth check was not being performed in the case of single line comments.
NOTE: Currently, I have suppressed error reports for single line right-hand comments. My fear is that this will unmask more standard violations than we can cope with. It is easy to re-enable and perhaps we should do that in the future:
/* Check for long lines
*
* REVISIT: Long line checks suppressed on right hand comments
* for now. This just prevents a large number of difficult-to-
* fix complaints that we would have otherwise.
*/
if (m > g_maxline && !rhcomment) <-- remote the second condition
The sub-string MHz is used frequently is pre-processor variable definitions. The section "Lowercase Exceptions" permits reasonable use of lowercase characters in pre-processor variable names and, given the frequency of the use of MHz (no pun intended), it certainly should qualify.
Allow "Public Function Prototypes" sections in .c files. Per the coding standard, all public function prototypes belong in .c files. However, there are some situations when the public function prototype is needed in a .c file and it shoudld, most correctly, be placed in a "Public Function Prototypes" section.
Checking for white-listed prefixes is also simpler now because the check is table driver. New data structure: g_white_prefix[] and new function white_prefix().
Clean up the no and unknown file extension info since only .h and .c
files supported. Just ignore them quietly.
Signed-off-by: liuhaitao <liuhaitao@xiaomi.com>
If we are going to use this tool for things like
git pre-commit hook or CI workflow, it's critical to
avoid false alarms.
This reverts commit de764af9aa.
Eliminate warnings. Ignore mixed case identifies beginning with PRIx.
These most likely come from inttypes.h and we nxstyle must tolerate
those definitions even though they do not follow the coding style.
Consider junk.c for example:
/****************************************************************************
* xx
****************************************************************************/
/****************************************************************************
* Private Types
****************************************************************************/
struct foo_s
{
int bar;
};
/****************************************************************************
* Public Functions
****************************************************************************/
int dofoo(int barin)
{
barout = barin;
return barout;
}
nxstyle not detects these problems:
$ tools/nxstyle.exe junk.c
junk.c:11:0: error: Blank line before opening left brace
junk.c:21:0: error: Blank line before opening left brace
Commit cf5d17f795 added logic to detect #define pre-processor definitions outside of the "Pre-processor Definitions" file section. That commit was verified against numerous .c source files. But not against any .h header files.
When run against a header file, that change causes a false alarm warning like:
file:line:pos: warning: #define outside of 'Pre-processor Definitions' section
That is caused the idempotence, guard definition that must appear in the header file BEFORE the first file section.
This commit adds logic to nxstyle to ignore pre-processor definitions in header files that occur before the first file section is encountered.
* tools/nxstyle: Added logic to parse section headers (like Included files, Pre-processor Definitions, etc.) and to assure that the section headers are correct for the file type. Also (1) verify that #include appears only in the 'Included Files' section and that (2) #define only occurs in the Pre-processor definition section.
Right now, there are several places where that rule is not followed. I think most of these are acceptable so these failures only generate warnings, not errors. The warning means that we need to go look at the offending #define or #include and decide if it is a acceptable usage or not.
