I am new to Static analysis tool and I am trying to build a simple checker. When I am throwing a OUTPUT_ERROR, I am also getting some more details with tags like "cond_true" etc. Is there a way I can stub these and print only the error I want to see.
Thanks.
First You have to use cov-build to create intermediate files.With this command u have to specify the make (makefile). After that It will create emit file where you mentioned in cov-build command.
Then You have to use cov-analyze to create analyze report.If there is any Bugs found means it will return on terminal.
To show that errors in html file you have to use cov-format-errors.This command will create error directory.In that directory you can find the html statistical report for your analyzed code..
Example commands:
(if the program is in same folder(bin), it will create emit file in current directory(bin/emit)).
cov-build --dir . gcc hi.c
(if you want to build for a single .c file)
OR
cov-build --dir . make
(to use make command You have to create makefile.(vi makefile in bin,write your own script about compiling programs which is going to be build by cov-build))
cov-analyze --dir .
cov-format-errors --dir .
This question is asking about writing a checker using the Extend SDK. There are two kinds of Extend checkers, flow-sensitive and flow-insensitive. The Extend documentation explains how to choose the kind of checker. Flow-sensitive checkers emit the cond_true events because they show the specific control flow path along which the issue was found; they cannot be suppressed. Flow-insensitive checkers do not emit them, so perhaps that is what you want to use.
Related
how can I run only one ui-test by XCTest from fastlane?
I know about parameters for fastlane: only_testing but not understood how to use this.
Can you give an example
I run my all ui-tests as:
fastlane ios RunningUITests
but want fastlane ios RunningUITests only_testing:GTUITests/GT00FirstClass/testFunc
this not work for me
Can you give an exactly example for this?
You have to use the scan (also known as run_tests) "action". Read this documentation for information.
There, you can see the instructions for calling it directly on the command line. In your example it would be:
fastlane scan --workspace "<YourRunningUITests>.xcworkspace" --scheme "<YourRunningUITestsScheme>" --only-testing "GTUITests/GT00FirstClass/testFunc"
Replace the values inside of the angled brackets (< >) with the values appropriate to your code.
However, rather than running that multi-parameter call from the command line, I recommend using a Fastfile to consolidate your logic and allow you to perform more sophisticated logic (such as these Fastfiles).
If you were to follow the logic suggested here, you could then simply call fastlane tests from the command line. Much simpler.
The comment from above is very useful, the only thing I want to add is that if you want to run more tests, write something like the following:
--only-testing "GTUITests/GT00FirstClass/testFunc,GTUITests/GT00FirstClass/testFunc2"
You should always write the full path to the test function
I'm struggling with the last pieces of logic to make our Ada builder work as expectedly with variantdir. The problem is caused by the fact that the inflexible tools gnatbind and gnatlink doesn't allow the binder files to be placed in a directory other than the current one. This leaves me with two options:
Let gnatbind write the the binder files to topdir and then let gnatlink pick it from there. This may however cause race conditions if we want to allow simulatenous builds for different architectures and compiler versions which we want.
Modify the calls to gnatbind and gnatlink to temporarily go down to the build directory, in our case build/$ARCH/src-path. I successfully fixed the gnatbind step as this is explicitly called using a env.Execute from within the Ada builder. To try to fix the linking step I've modified the Program env using
env["LINKCOM"] = SCons.Action.Action(ada_linkcom)
where ada_linkcom is defined as
def ada_linkcom(source, target,env ):
....
return ret
where ret is a string describing what should be done in the shell. I need this to be a function it contains a bit complicated logic to convert paths from being relative to top-level to just containing their basenames.
This however fails with an error in scons-2.3.1/SCons/Executor.py on line 347 in function do_execute. Isn't env["LINKCOM"] allowed to be a function with ada_linkcom's signature?
No, it's not. You seem to think that 'env["LINKCOM"]' is what actually calls/executes the final build command, and that's not quite correct. Instead, environment variables like LINKCOM get expanded by the Executor/Builder for each specified Action, and are then executed.
You can have Python functions as Actions, and also use a so-called "generator" to create your Action strings on-the-fly. But you have to assign this Action to a Builder, and can't set it as an environment variable directly.
Please also have a look at the UserGuide ( http://www.scons.org/doc/production/HTML/scons-user.html ), especially section 18.4 "Builders That Execute Python Functions". Our basic guide for writing Builders and Tools might also prove to be helpful: http://www.scons.org/wiki/ToolsForFools
Can any one tell me which function in gcc source code is responsible for finding a macro in C file and repalce it with actual value ?
I want to know the function as I have to take log by making changes to it, so that at the end my log file will contain where all macro is used and its line number .
It's done by the preprocessor, prior to generating the output file. If you want to see what it is doing, try gcc -E
From man gcc:
-E Stop after the preprocessing stage; do not run the compiler proper.
The output is in the form of preprocessed source code, which is sent to
the standard output.
I recommend using clang for this type of task. It is pretty well documented and you don't need to change its source, as it's extendable with a plugin system.
In your case you create a plugin based on the PPCallbacks class and override its MacroExpanded method, and any other method you find useful. This is an easy starting point.
I want to create an extension to recognize specific comments in my code. I will use this to signal code smells by using the //# comment prefix. One feature of this extension will be to generate warnings for each comment encountered while compiling the code. Is it possible to do this?
I don't think you can hook into the compiler to generate warning. However, the "Error List" view aggregates errors, warnings and messages from multiple sources. Would it be good enough for you to simply append to that list?
Here's a link I could find on the subject : http://www.mztools.com/articles/2008/MZ2008022.aspx
There is a sample called CodeSweep that detects certain strings in comments (it is written to look for mild swear words) that adds tasks to your Task List. http://code.msdn.microsoft.com/Code-Sweep-3bfb7bb5 Reading this code could help you write your own extension if you can't use it as-is.
You could also use the existing task functionality and add your own keywords (like the out-of-the-box //HACK and //TODO - you could add //SMELL) which is quicker but gives you less control. http://msdn.microsoft.com/en-us/library/zce12xx2(v=VS.100).aspx. This may be all you need.
Let me prefice this question with the comment that I know very little about Makefiles or make.
There is a very large project that is automatically built nightly. It is built in both Debug and Release mode, Debug being used for utilities like Valgrind to provide code analysis. Somehow, some of the built libraries are losing the debug flag during the make process, which makes some analysis output unhelpful. I was tasked with finding the bug and I need some suggestions on how to go about locating/repairing the issue.
Thanks in advance
make itself also supports a debug flag, -d; depending on how your Makefiles call each other, it may be possible to pass it through (and if not, you can rewrite them to do so with a script); then if you feed the resulting output to a file you can start looking for clues.
Given the sparse information, I can only sketch a very general strategy based on what I've seen in terms of Makefile usage for a handful of large projects.
If you don't already know where the flags originate, search through the Makefiles to find out.
Something like:
find . -name Makefile -exec grep -nH -- -g {} \;
(Adjusting the -name pattern if your project uses included Makefiles like foo.mk or bar.mak or something. And adjusting the "-g" if your debug flag is something else.)
You'll probably find it assigned to a variable like CFLAGS. Look around the spot where this variable is assigned, it is probably set conditionally (e.g. ifeq($(RELEASE),1)).
Now look at the Makefile(s) in the library that isn't getting those flags. Find the spot where the compile command lives. Is it using the right variable? Are these Makefiles overriding the variable?
It may also be helpful to capture the output of a build to a file and search around for any other places that might not have the debug flags set.
use remake, its really good