I have a bunch of C files and I need to check for a set of indentation rules. These rules are custom made. I basically need to flag warnings for all indentation violations. Is there any code/tool that does basic parsing of a C file. I am planning to add my own stuff to a code that already exists.
Since you plan on extending existing code, why not use astyle?
Once you have the correct flags it formats your code accordingly so that the results will always be the same. I (sadly) haven't found any dry-run flags, but a diff of your original file and the newly created astyle file should give you all violations.
Related
I was exploring gcc supported pragmas and I just didn't get what the manual say about #pragma GCC dependency:
#pragma GCC dependency allows you to check the relative dates of the current file and another file. If the other file is more recent than the current file, a warning is issued. This is useful if the current file is derived from the other file, and should be regenerated. The other file is searched for using the normal include search path. Optional trailing text can be used to give more information in the warning message.
Can anyone explain this part with some minimal code?
This is useful if the current file is derived from the other file
How can the current file be derived from the other file? I can understand how another file can be derived form the current file but not vice versa.
How can the current file be derived from the other file? I can
understand how another file can be derived form the current file but
not vice versa.
The primary case served is when a C source file is created by a program, using the designated other file as an input. The C source is derived from the other file by running the program. It is to be presumed that differences in the other file would cause the code generator program to produce the C file differently, at least a little, else the pragma in question would not be used.
Thus, if the designated other file's last-modification timestamp is more recent than the C file's, then it is highly suspect to be compiling the C file at all, for it probably does not correspond to the current version of the other file. Instead, one should regenerate the C source from the other file by running the code generator program again, obtaining a whole new version of the C file to replace the current one. The new one will, of course, have a last modification timestamp newer than the other file's, because the other file had to exist before the new version of the C file could be generated from it.
Example:
There is a classic program named lex whose purpose is to help write programs that process text, especially the text of programming languages or rich data languages (the details are not important). The input file for this program describes how to recognize and categorize the basic units of this language, which are called "tokens". If the language being parsed were C, then tokens would include language keywords, numeric constants, and operators. The input file for lex is typically tens of lines long.
lex reads such an input file and writes a C source file defining several functions and some internal tables that implement the "scanning" behavior required: reading the input text and breaking it up into tokens, which it reports back to its caller. The C source generated by this program is typically a few thousand lines long, which, compared to the much smaller input file, explains in a nutshell why lex is useful.
To build a program that scans the language in question, one provides functions (in a different source file) that call those generated by lex, and compiles them along with the lex-generated C source to obtain a complete program. Say the lex input file is named language.l, and the output of running lex on that file is named language.c. If I want to change the behavior of the scanner functions then the thing to do is to modify (small, simple) language.l and then re-run lex to regenerate language.c.
When I change language.l in any meaningful way, language.c becomes out of date until I generate a new version of it from language.l by re-running lex. If I compile the outdated version of language.c then the result does not reflect the current version of language.l. This usually constitutes an error on the part of the person building the program, and #pragma GCC dependency provides a mechanism for eliciting a warning from the compiler in that situation.
My use case is as follows. In the automated testing of one of my libraries I use the mktemp function in order to obtain a filename in order to create a temporary file. Xcode correctly complains about this as a security risk, but in this case I have no option (the API I must follow demands filenames) and I am willing to take the risk since the code is only the test code and not in an actual service. (Hence the security risk is not applicable.)
I suppose I could create my own version of a mktemp that is local to my testing, but I would prefer not to write things that have already been written.
So what I am wondering is if there is a way that I can tell the analyzer to stop complaining this instance of the problem? Note that this differs from the question asked in Is it possible to suppress Xcode 4 static analyzer warnings? in that this is not a false positive, and I do not want to suppress analyzing the file or all instances of this check. I just want to suppress this one instance. (i.e. something similar to cppcheck-suppress comment in Cppcheck)
#JonathanLeffler last comment was absolutely correct and I don't know how I missed it when I read the question I referenced. The following code segment does exactly what I want - it suppresses the analyzer warning in this instance of mktemp while leaving it active for all other instances that would use mktemp.
#if defined(__clang_analyzer__)
char* filename = "/tmp/somename";
#else
char* filename = mktemp("/tmp/prefixXXXX");
#endif
I am looking through some proprietary source code: sample programs in using a library.
The code is written in C and C++, using make for build system.
Each and every file ends in a commented out []: /*[]*/ for source files and #[]# for makefiles. What could be the reason for this?
The code is compiled for ARM with GCC, using extensions.
It is most likely a place holder for some sort of automatic expansion.
Typically something like macrodef (or one of the source code control filters) would expand such items to contain some relevant text. As typically only the comment-protected brackets would expand, the comments would remain in place, protecting the source code from actual expanded items at compilation time.
However, what you are currently looking at is probably the outer containing brackets with all of the internal expansions removed. This may have been done during a code migration from one source code control system to another. Although such an idea is highly speculative, it does not appear that they took the effort to migrate expansion items, instead of just removing them.
On one project I used to work, every C source file contained a comment at the very end:
/* End of file */
The reason for that was the gcc warning
Warning : No new line at end of file
So we had this comment (with a new line after it) to be sure people do not write after the comment :)
This question asks about a coding style checker, but the focus seems to be on indentation and brace placement. GNU indent deals with indentation (which isn't a problem in this code base, amazingly enough).
I'm working with a pile of code that is full of various naming schemes: camelCase, everythingruntogetherinlowercase, underscores_as_separators, SomeStructsEndWithT, etc.
I'd like to be able to pick a convention and at least have an automatic check that new changes are in line with the convention.
Is there a good tool for checking naming in C? Something like Python's pep8 checker tool, I don't want a beautifier.
Thanks.
It looks like Google's cpplint (a C++ style checker) can be hacked into submission for checking C like I want.
(I'm still interested in knowing if there are any better checkers out there.)
It is an unorthodox choice, but I'd go with cxref, if you are willing to put in half a days work. It is a cross referencer, comes with the source code, it has a clean parser and doesn't build a parse tree. Yet, with a few lines of code you can dump all the variables to examine them, or rewrite them to your favoured style (or if you are as lazy as I am instead of rewriting you could generate replace commands for emacs/sed). I only managed to build it for Mac.
This one has a number of answers already in this thread Coding style checker for C
from which Vera++ might be the most promising, since most of the other suggestions are formatters not validators. There's a webpage about running vera++ at
https://bitbucket.org/verateam/vera/wiki/Running.
There's a download from https://bitbucket.org/verateam/vera/downloads/vera++-1.1.1.tar.gz
Compiling presents a few issues:
sudo apt-get install libboost-dev tcl-dev
An include of tcl.h that should have been tcl/tcl.h
Need a full boost src tree, like that from http://sourceforge.net/projects/boost/files/boost/1.53.0/boost_1_53_0.tar.gz/download
The build command becomes something like: make BOOST_DIR=/home/fluffy/tmp/boost_1_53_0
vera++ needs a ~/.vera++/profiles/ but doesn't autocreate a default (it can be copied from the one in the distribution, however)
Finally, running it on a C++ file produced output like (with duplicate errors omitted for brevity):
../dllist.c:1: no copyright notice found
../dllist.c:4: horizontal tab used
../dllist.c:10: horizontal tab used
../dllist.c:10: closing curly bracket not in the same line or column
../dllist.c:29: horizontal tab used
../dllist.c:38: keyword 'if' not followed by a single space
../dllist.c:38: negation operator used in its short form
../dllist.c:40: horizontal tab used
../dllist.c:40: full block {} expected in the control structure
../dllist.c:42: horizontal tab used
../dllist.c:71: keyword 'if' not followed by a single space
../dllist.c:71: negation operator used in its short form
../dllist.c:72: horizontal tab used
../dllist.c:72: full block {} expected in the control structure
../dllist.c:73: horizontal tab used
I unfortunately was doing a little code archeology today (while refactoring out some old dangerous code) and found a little fossil like this:
# line 7 "foo.y"
I was completely flabbergasted to find such an archaic treasure in there. I read up on it on a website for C programming. However it didn't explain WHY anyone would want to use it. I was left to myself therefore to surmise that the programmer put it in purely for the sheer joy of lying to the compiler.
Note:
(Mind you the fossil was actually on line 3 of the cpp file) (Oh, and the file was indeed pointing to a .y file that was almost identical to this file.
Does anyone have any idea why such a directive would be needed? Or what it could be used for?
It's generally used by automated code generation tools (like yacc or bison) to set the line number to the value of the line in the actual source file rather than the C source file.
That way, when you get an error that says:
a += xyz;
^ No such identifier 'xyz' on line 15 of foo.y
you can look at line 15 of the actual source file to see the problem.
Otherwise, it says something ridiculous like No such identifier 'xyz' on line 1723 of foo.c and you have to manually correlate that line in your auto-generated C file with the equivalent in your real file. Trust me, unless you want to get deeply involved in the internals of lexical and semantic analysis (or you want a brain haemorrhage), you don't want to go through the code generated by yacc (bison may generate nicer code, I don't know but nor do I really care since I write the higher level code).
It has two forms as per the C99 standard:
#line 12345
#line 12345 "foo.y"
The first sets just the reported line number, the second changes the reported filename as well, so you can get an error in line 27 of foo.y instead of foo.c.
As to "the programmer put it in purely for the sheer joy of lying to the compiler", no. We may be bent and twisted but we're not usually malevolent :-) That line was put there by yacc or bison itself to do you a favour.
The only place I've seen this functionality as being useful is for generated code. If you're using a tool that generates the C file from source defined in another form, in a separate file (ie: the ".y" file), using #line can help the user know where the "real" problem is, and where they should go to correct it (the .y file where they put the original code).
The purpose of the #line directive is mainly for use by tools - code generators can use it so that debuggers (for example) can keep context of where things are in the user's code or so error messages can refer the user to the location in his source file.
I've never seen that directive used by a programmer manually putting it in - and I;m not sure how useful that would be.
It has a deeper purpose. The original C preprocessor was a separate program from the compiler. After it had merged several .h files into the .c file, people still wanted to know that the error message is coming from line 42 of stdio.h or line 17 of main.c. Without some means of communication, the compiler would otherwise have no way to know which source file originally held the offending line of code.
It also influences the tables needed by any source-level debugger to translate between generated code and source file and line number.
Of course, in this case, you are looking at a file that was written by a tool (probably named yacc or bison) that is used to create parsers from a description of their grammar. This file is not really a source file. It was created from the real source text.
If your archaeology is leading you to an issue with the parser, then you will want to identify what parser generator is actually being used, and do a little background reading on parsers in general so you understand why it doing things this way at all. The documentation for yacc, bison, or whatever the tool is will likely also be helpful.
I've used #line and #error to create a temporary *.c file that you compile and let your IDE give you a browsable list of errors found by some 3rd party tool.
For example, I piped the output file from PC-LINT into a perl script which converted the human readable errors to #line and #error lines. Then compiled this output, and my IDE lets me step through each error using F4. A lot faster that manually opening up each file and jumping to a particular line.