I am writing a simple C editor. I have to validate a code to highlight any misspellings, missing semicolons, uses of non-existing functions/variables/methods, assigments in if condition and so on and so forth.
Parsing and validating C is a very complex problem so I have decided to use CDT. However, I have no idea how to do so.
I have only found informations about method org.eclipse.cdt.core.dom.ast.gnu.c.GCCLanguage.getASTTranslationUnit(...) but this is not helping very much, because it allows to find only basic syntax errors. (Am I right?)
I need a function which gets a C code or an object of the class IASTTranslationUnit. It has to return list of all problems (errors and warnings). How can I do that, using the CDT API?
Many categories of errors can be checked by resolving names found in the AST (calling IASTName.resolveBinding()), and seeing whether the resulting binding is an IProblemBinding.
See how CDT's ProblemBindingChecker does this to show many errors in the editor.
Note that this wonn't catch all errors; you can look at CDT's other checkers for ideas about how to catch other categories of errors (some of the checkers also produce warnings).
However, even all of CDT's checkers put together won't diagnose of all the errors and warnings that a compiler would. If that is a requirement, I would suggest using an actual compiler's internals, such as libclang.
Related
I am new to C. I encountered an error message which involves unexpected "}". However, I checked the number of "}" with an editor and indeed they pair up.
Then I wonder if there is a compiler command, so the compilation can stop whatever I want? It will be convenient to have such tool as debug help.
Thank you.
(Edited in 29-10-2015)
I typically write my code with gedit. Nonetheless, since my work is mostly done on cluster, it will be troublesome to transport the files up and down. I must turn to nano, vi or vim which causes difficulty in debugging.
Stopping compilation partway through is rarely a useful feature. You'll want to see all of the errors that may exist in your code so you can fix more that just one at a time.
That said, an error such as a misplaced brace or parenthesis can cascade down and cause several more errors to appear. So if you see a long list of errors that don't seem to make sense when you look at the code, start at the top and fix that, then recompile to see if it took care of any others.
The answer is no compilers are all or nothing.
However, a good editor is recommended. For example, you can match brackets with the % command in vi, or if you have a color editor, you can visually see what's going on. A better IDE would even allow you to hide/show blocks of code, format it with proper indentation, and flag any compilation issues from static rules without actually compiling your code.
I need to be able to suppress lint warnings on specific lines of C code, and I would like to do this with in-line directives. This is for a very large body of legacy code that I am porting to 64 bit, and I'd much rather put the directives in the code than in the Makefile that runs lint, as the latter is quite obscure.
The problem is that Solaris lint documentation specifies how to do this for only a few warning types (as far as I can tell).
In the past, the following form was used and the Solaris documentation suggests that this is still allowed, but it doesn't seem to work. Complicating the issue is that the Solaris lint does not give error numbers, but rather uses identifiers like E_CAST_INT_TO_SMALL_INT.
Here is the old way (and there are lots of these in the code already):
/*line -e511*/
Described in Lint Directives Section at this link
There are two inline ways to suppress lint warnings for a single line of code - the old way and the recommended new way.
The old way is to use a LINTED comment: /*LINTED*/
The new way is to use a lint macro: NOTE(LINTED (msg))
The new way also requires including note.h.
I'm trying to create an Xtext parser for a scripting language that I use. The language is quite close to ANSI-C.
I started by converting this https://github.com/antlr/examples-v3/blob/master/C/C/C.g grammar to Xtext and removing the parts I don't need (structs, typedefs, etc.)
However, I run into problems and I don't know how to debug them properly and find my errors.
I receive
error(10): internal error: org.antlr.tool.Grammar.createLookaheadDFA(Grammar.java:1279): could not even do k=1 for decision 39; reason: timed out (>10000ms)
and also OutOfMemoryError exceptions.
EDIT: I have already tried increasing the memory & timeout. However, even with LARGE values, this does not work.
Can anyone suggest ways to "debug" the grammar? Where is decision 39? I would love to locate the problem, but I couldn't find anything.
PS: I've posted the grammar listing here, to not clutter the post up http://pastebin.com/8AYNUbSD
You can generate an Antlr grammar (.g) by activating debug mode in your workflow.mwe2, add the following fragment:
fragment = org.eclipse.xtext.generator.parser.antlr.DebugAntlrGeneratorFragment {}
Then, you can debug this debug grammar by using AntlrWorks IDE
Quick tutorial here
My assignment is to use unix system calls or library utilities in C to get an answer, and I've been searching for a while, All the answers available seem to lead to something with localtime() or time strftime() and I keep getting these warnings that say the functions are unsafe. I've been trying examples and copy pasting code but nothing seems to compile usually with the unsafe error. Help. Extra details, I can't use any libraries out of the very standard ones, things like chrono have gotten my friend rejected work before.
If you're required to turn in the work using the 'traditional' library functions like strftime(), then you'll need to turn off the warnings about these functions being unsafe.
There's usually some way to do this, but it will depend what specific compiler you're using, and you didn't say.
There's nothing particularly 'wrong' with solutions using these functions, it's just that times have moved on since they were originally developed, and many people try to avoid the potential security risks associated with their use.
Have you tried using whats available in the time header? As far as I know, the time.h header should be available to any C compiler.
Some more information to read up on:
http://en.wikipedia.org/wiki/C_date_and_time_functions
Let me try to give some background first. I'm working on some project with some micro controller (AVR) which I'm accessing through some interface (UART). I'm doing direct writes to its global variables and I'm also able to directly execute functions (write args, trigger execution, read back return values).
AVR code is in C compiled with GCC toolchain. PC, that is communicating with it, is running python code. As of now I have imported adress & size information into python easily by parsing 'objdump -x' output. Now what would greatly boost my development would be information about types of the symbols (types & sizes of structs elements, enums values, functions arguments & return values, ...).
Somehow this seemed like a common thing that people do daily, and I was naively expecting ready-made python tools at start. Well, not so easy. By now I've spend many hours looking into various ways how to accomplish that.
One approach would be to just parse the C code (using e.g. pycparser). But seems like I would have to at least 'pre-parse' the code to exclude various unsupported constructs and various ordering problems and so on. Also, in theory, the problem would be if compiler would do some optimizations, like struct or enum reordering and so on.
I've been also looking into various gcc, gdb and objdump options to get such information. Have spent some time looking for tools for extracting information from various debugging formats (dwarf, stabs).
The closest I get so far is to dump stabs debugging information with objdump -g option. This outputs C-like information, which I would then parse using pycparser or on my own.
But before I spent my time doing that, I decided to raise a question here, strongly hoping that someone will hit me with possibly totally different approach I just haven't think of.
There's a quite nice tool called c2ph that dumps a parsable descripton of the types and sizes (using debug info as the source)
To answer myself... this is what I found:
http://code.google.com/p/pydevtools/
Actually I knew about it before, but it didn't really work for me at first.
So basically I made it Python 3 compatible and did few other fixes/changes also - here you can get it all:
http://code.google.com/p/pydevtools/source/checkout
Actually there is some more code which actually uses this module, but it is not finished yet. I will probably add it when finished.