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.
Related
I'm using PC-Lint to lint a C project. I want to ignore errors and warnings in third party libraries, but I'm not able to get this. Reading the manual, I check all #include files specified with angle brackets are considered as libraries.
[...] and you want this header to be regarded as a library header use angle brackets
as in: #include <\include\graph.h>
Or for example, using the -libh command to indicate that header file is a library.
Using the option -vf, I've verified that my library files are being included as libraries. So everithing is OK.
The problems is that I'm receiving lot of errors from these files. I thought that since these files are considered as libraries, errors would be ignored.
How can ignore errors in library files? I've tried with -wlib(0), but this option ignore errors in header files too. In addition, generates an umcofortable warning:
Warning 686: Option '-wlib(0)' is suspicious because
of 'the likelihood of causing meaningless output'; receiving a syntax error
in a library file most likely means something is wrong with your Lint
confinguration
Any suggestion? Thanks in advance
I had to read several times the PC-Lint manual and check the output log several times. The "problem" is by default the expression
+libclass(angle, foreign)
is enabled, so all .h files are considered libraries. It is necessary to overwrite this expression by using:
+libclass(angle)
In order to treat these files as headers an not libraries.
Thanks again.
Sorry for posting late but I found this thread when looking for ways to remove the -wlib(0) warning in the output.
So for others looking for that answer a simple -e686 before the -wlib(0) removes that warning from the output.
I understand this does not answer the original question, but sometimes this is what you want to do.
Is it possible to turn off all macro and pasting errors (or errors of any types)?
ie:
error: macro "macro_name" passed 1 arguments, but takes just 0
error: pasting "&" and "0" does not give a valid preprocessing token
The reason is that I'm debugging code that has a bunch of these errors (which I haven't fixed yet) that are making it harder to see the other types of errors that I'm trying to fix first.
No, that's why they're errors instead of warnings; the compiler doesn't know what to do with/how to work around them. You should usually fix errors in the order they come up anyway, especially the preprocessor errors you want to turn off, because an error in one part of the code can propagate and cause "errors" in other, correct, parts of the code. If you're getting too many errors, use make 2>&1 | less to get them without scrolling back.
Pipe the output of the compiler to a text file, and then read the text file to find your errors. You could remove the "un-interesting" errors via RegEx or something similar.
gcc 4.6.0
GNU Emacs 23.2.1
I have some c code and at some point I must have made a typing mistake. And now I am left with unbalanced curly braches or a parentheses.
I have about 2000 lines of code and I am just wondering is there any technique for finding them?
Emacs has some good features, so I am just wondering is there any way it can scan the code and tell me where they are. Currently I have a compile error related to this.
Many thanks for any suggestions,
In emacs you can use M-x check-parens . See http://www.gnu.org/software/libtool/manual/emacs/Parentheses.html
I would suggest adding "#ifdef 0 .... #endif" around blocks of code until the source compiles. Keep adjusting the size of the ifdef'd out code until you narrow down a chunk that compiles when ifdef'd out and doesn't otherwise. This chunk will contain the unbalanced brace.
Personally I'd start by ifdefing out almost the whole file and moving my "#ifdef 0" ahead each function until I started seeing compilation errors.
If you have crazy long functions then take the same sort of approach but within the function that's giving you trouble (once you've determined which function it is).
One good point to start is selecting all (M-x select-all) and then indenting the code (M-x indent-region). As emacs does a very good job indenting, you'll notice where the indentation failed.
Also, using show-paren-mode (M-x show-paren-mode) emacs will show you the matching paren of each ending paren (and vice-versa), so you can go through your code.
If you want something more fancy than plain highlighting, you could use rainbow delimiters: https://www.emacswiki.org/emacs/RainbowDelimiters
Here is a short blog post on it: http://emacs-fu.blogspot.com/2011/05/toward-balanced-and-colorful-delimiters.html
I want to run splints whole program analysis on my system. However the system is quite large and different parts are compiled with different compiler defines and include paths. I can see how to convey this information to splint for a single file but I can't figure out how to do it for whole program. Does anyone know a way of doing this?
Assuming you have a Makefile you could create a new target; then you would go through the actual compilation steps to duplicate them using Splint instead of the compiler.
My advice, however, is against the full-program approach. If you can isolate your system into separate parts, I'd rather start by checking them, one by one. Since your program is "quite large", expect a gazillion warnings... for each one of your modules. You will start to get rid of them once you have sprinkled your source code with the appropriate semantic annotations. Good luck! :)
When releasing source code for someone else to see, when coding style is not well defined
(no pun intended)
do you remove the #ifdef DEBUG parts?
(that is the parts that are compiled only when DEBUG is defined)
If I remove it, it makes the code looks better (or me look better - do I really want someone to know I've debugged, and how I've done it? ), but then I'll lose my debug parts, or have to keep two (or more) versions of the code.
What is to be done?
I think if your debug code is clean and has "professional" language in any logging statements, it's okay to leave it in. If the debug code is sloppy or has debug messages like "I'm here...," "Now I'm here..." you should take it out.
If your debug statements reflect the fact that there are issues that you can't figure out, it might be best to take them out, if you're trying to "sell" your software to someone. (Hopefully you can fix them later...)
You should leave the code as is, unless you make use of non-recomadable language in your commentary. If someone is to use your code, chances are they'll need those, or it will help them understand your code. (this is also true for commentaries)
Edit: I worked on drop of other studio code often in the past. I have seen debug code, dead path and many other stuff, still the only thing I hated, was people that strip their code of debug and commentary, this makes their code real hard to maintain
I also vote to leave it in. If/when you start work on your first patch, you'll likely need those DEBUG-blocked pieces. Also, QA won't love it that you removed the code, even if it is blocked in a directive.
If you do decide to remove them, just filter them out with a script when exporting the code, no need to maintain two versions.
Maintain your base version with everything in your source code management system.
Then if you want to distribute source code filtered in one or more ways, make a script that will make a release version of your source code.
Do not maintain these secondary filtered repositories, make them always generated.
But is it worth the time? Probably not, and you should probably just distribute everything including the #ifdef DEBUG parts.
Maintaining multiple versions of ANYTHING is undesireable.
Only do so if you must.