Is there a tool which can do static analysis and find possible forward null and possible null dereference cases.
I know coverity is pretty much used and also cpp check.
But I dnt find it usefull when comes to user defined data-type comes to picture.
Please provide a solution which can handle user defined data types also and works on C++ code.
You might try
Cppcheck - Cppcheck is a static analysis tool for C/C++ code. Unlike C/C++ compilers and many other analysis tools it does not detect syntax errors in the code. Cppcheck primarily detects the types of bugs that the compilers normally do not detect. The goal is to detect only real errors in the code (i.e. have zero false positives).
Coverity-Scan - STATIC ANALYSIS Find and fix defects in your Java, C/C++, C# or JavaScript open source project for free. Test every line of code and potential execution path.
There are a lot of other tools available, both open source and commercial.
Good luck.
Related
As far as I know, the compiler compiles the code by converting it to a language that a computer can understand which is the machine language and this is done before running the code.
So, does the compiler compile my code each time I write a character in the file?
And if so, does it check the whole code? Or just the line that updated.
An important part to this question is the type of programming language(PL) we are talking about. Generally speaking, I would categorize PL into 3 groups:
Traditional PLs. Ex: C, C++, Rust
The compiler compiles the code into machine language when you hit the "build" button or the "run" button.
It doesn't compile every time you change the code, but a code linter does continuously observe your code and check it for errors.
Another note, when you change part of the code and compile it, the compiler doesn't recompile everything. It usually only recompile the current assembly file (or module or whatever you call them).
It is also important to note that a lot of modern IDEs, compile when you save the files.
There is also the hot reload feature. It is a smart compiler feature that can swap certain parts of the code while it is running.
Interpreted PLs Ex: python, JS and PHP
Those languages never get compiled; Rather, they get interpreted or translated into native code on the fly and in-memory when you run them.
Those languages usually employee a cache to accelerate the subsequent code execution.
Intermediary Code PL. Ex: Kotlin, java, C#
Have 2 stages of compilation:
Build time compilation.
Just in time (run-time) compilation.
Build time compilation converts the code into intermediary language (IL) machine code, which is special to the run-time.
This code only understood by the run time like Java runtime or dot net runtime
The second compilation happens when the programs get installed or ran for the first time. This is called just in time compilation (JIT)
The run-time convert the code into native code specific to the run-time OS.
I was wondering if there is a quick and effective way to remove all the unused variables (local, instance, even properties) in xcode... I am doing a code cleanup on my app and if I knew a quick way for code refactoring it would help me a lot...
Thanks...
It's being a long time since you made your question and maybe you found an answer already, but from an answer to a related question:
For static analysis, I strongly
recommend the Clang Static Analyzer
(which is happily built into Xcode 3.2
on Snow Leopard). Among all its other
virtues, this tool can trace code
paths an identify chunks of code that
cannot possibly be executed, and
should either be removed or the
surrounding code should be fixed so
that it can be called.
For dynamic analysis, I use gcov (with
unit testing) to identify which code
is actually executed. Coverage reports
(read with something like CoverStory)
reveal un-executed code, which —
coupled with manual examination and
testing — can help identify code that
may be dead. You do have to tweak some
setting and run gcov manually on your
binaries. I used this blog post to get
started.
Both methodologies are exactly for what you want, detecting unused code (both variables and methods) and removing them.
Visual Studio seems to want to put class contructor code and event handling code in the .h file. I have only been involved in small 1 man projects and was wondering what the general industry standard was.
For Visual C++ Application projects what code would one put in the .h file? I am used to the mode classical C++ way of declaring your class in the .h file and coding in the .cpp file. Does this still apply to Visual Studio applications?
I have a strong C background which would explain my preference for this. The VSC++ compiler doesn't seem to mind.
In short: What is one supposed to put in which type of file?
TIA
Ends
There is no widely accepted industry standard. By putting (short) function definitions in the header, you give the compiler a better chance to inline the code. The benefit is that it can make the code run faster (keep those functions short, though). However, this comes at the cost of exposing more code to the clients who include that header, making you (or your colleagues) recompile more files when you change the implementation.
You also have to take into account the cost of going against your tools. Since VC++'s wizards insist on putting the functions in the headers, you have to move them everytime if you disagree.
It's really project-specific, I would say.
If you're using MFC and you're talking about the generated code, it's best to leave it alone.
If you're trying to do 'normal' C++ development, put as little as you can get away with in the header, as it means client code doesn't depend on too many implementation details. What you can get away with depends a little on use of templates, and how much indirection your performance budget can support.
For Visual C++ Application projects
what code would one put in the .h
file? I am used to the mode classical
C++ way of declaring your class in the
.h file and coding in the .cpp file.
Does this still apply to Visual Studio
applications?
Short: Yes
Long: Depends on the person or language. In c++ the header is for declaring and cpp for the coding. For C# you have one file (or if you use interfaces, 2)
This might seem minor, but just remember: headers are #included in several places. (And headers including headers complicates things further.) Any time you change a header, a lot of files are gonna be compiled again. Keeping as little of frequently changing code in the header reduces recompilation of dependant files.
Another thing: an uncluttered header file gives you a quick overview of what a class/form has to offer.
Whats the easiest way to find out what programming language an application was written in?
I would like to know if its vb or c++ or delphi or .net etc from the program exe file.
Try PEiD
of course if they used a packer, some unpacking will need to be done first :)
Start it up and check what run-time DLLs it uses with Process Explorer.
If that doesn't make it immediately obvious, search the web for references to those DLLs.
Most disassemblers (including Olly I think) can easily show you the text contained in an EXE or DLL, and that can also sometimes give a clue. Delphi types are often prefixed with T as in TMyClass.
If it's a small executable with no DLL references and no text you might be SOL. At that point you'd need to look for idioms of particular compilers, and it would be mostly guesswork.
There is an art to detecting what language a program was written in. It is possible but there are no hard and fast rules. It takes a lot of experience (and it also leads to the question "Why would you want to..." but here are a few ideas on how to go about it.
What you're looking for is a "signature". The signature could be a certain string that is included by the compiler, a reference to an API that is quite common in the programming tool being used, or even a style of programing that is common to the tools being used, visible in the strings contained in the application.
In addition, there are styles to how an application is deployed: various configuration files found in the deployment directory, dlls and assemblies and even images, directories or icons.
Java applications wrapped in a self-launching executable will contain references to java libs, and will likely have certain libraries or files included in the same directory that indicate that it's java.
As indicated in other answers a managed assembly will show certain signs as well: you can open it in Reflector etc. While it is correct that c# and VB are "interchangable" once compiled, it is not true that they are identical. If you use Reflector to disassemble VB code you will quite often see that the assembly references the Microsoft.VisualBasic.dll assembly. You'll be able to tell the difference between Mono applications because they will most likely contain references to the mono assemblies.
Many compilers assemble and link code in certain ways, and leave footprints behind. For example, examining a window executable using "strings: tab in Process Explorer, you'll see a lot of strings. Using these you may be able to determine programming styles, methods called, error or trace methods withint the exe.
An example is that compilers use different mechanisms for localization: Microsoft stores localized strings in XML files or resource files. Other compilers will use a different tactic.
Another example is c++ name mangling. The CodeWarrior compiler uses a different algorithm to mangle the names of the member variables and functions of a call than Visual Studio.
I suppose you could write a book on the subject of accurately determining the lineage of any executable. This subject would probably be called "programming archeology".
You could try using Depends to see what runtime dependancies it has, which might give some clues.
The easiest way is to ask the developer of the program. It does not require any knowledge and utility programs.
Determine Delphi Application
Use eda_preview270.exe (from here) or some other spy tool and check the window class names. If they read like TButton or TfrmBlubb, it's a VCL app. If there is an "Afx" in them, it's probably MFC.
Compiled languages (by this I mean no scripting languages, or Java, .NET, etc.) are compiled into CPU assembly instructions, which is essentially a one-way conversion. It is not usually possible to determine which language a program was written in. However, using a dependency walker, you could potentially determine which runtime library the program was loading (if any) and therefore determine which language it used (e.g. MS Visual C++ 9 uses msvcr90.dll).
you can check is that a .net assembly or not by trying to open with ildasm.exe tool
PE Detective works best for me.
In general, you can't.
If you can load it into Reflector, you know it is a managed assembly.
That's a good question. There isn't any general way to tell, but I bet most compilers and libraries leave a mark in the resulting EXE file. If you wanted to spend a lot of time on it, you could gather a bunch of EXEs written in known languages and scan for common strings. I would image you'd find some.
Dependancy Walker, which someone else mentioned would be a good way to look for telltale dependencies, like versions of MSVCRT, etc
i'd try running the .exe thru a 'strings' program to get assorted hints.
If I remember correctly PE Explorer Disassembler gives some information about compiler that creates given not .net and java binary, for .net use Reflector or ILDAsm tool
The easiest way that I found (at least in computer games) was to look in the "redist" folder nested within the game's main folder. It might be obvious to some of you that are more experienced in programming yourself, but the specific purpose of the MSI in this folder is to allow the setup.exe file to automatically install the prerequisites for the game itself.
For example:
In Empire Total War, there is an MSI called "vcredist_x86-sp1.exe". This indicates that the game/program was written in Microsoft's "Visual C 2005" in the .NET Framework (usually).
In fact, if you open the MSI/EXE, the installer should immediately indicate the language it's written in and which version.
The reason I'm familiar is because I code in C# and VB in the .NET Framework and we auto-install the prerequisites for our business app.
Hope this helps!
We have a proprietry system that we develop scripting code in.
We currently do not have a developer environment (apart from Notepad++) and cannot debug or compile this code. We have to submit it to the vendor to insert the code into the test or live system.
The language is essentially C like and has the same syntax.
Basically we want a tool to be able to simply check the syntax of chunks of code we send to the vendor.
Does a tool exist that will do this for me?
You write code in a proprietary scripting language, so you require syntax checking because you cannot compile or debug the code onsite? I'd suggest getting a copy of the language reference (including the BNF if possible) from your vendor, get a compiler-compiler like Coco/R (http://www.ssw.uni-linz.ac.at/coco/), and build yourself a quick and dirty compiler that just validates the abstract syntax tree.
That is to say, yes, there are tools you can use, though perhaps they involve more work than what you may have hoped.
If it's really the same syntax as C you can use a C compiler. Usually there's a syntax check only option (/Zs for MSVC).
I'm not sure how many problems you'll run into since C compilers are pretty picky, and being "like C" is not the same as being C.
It does seem odd that you're being asked to develop code without having any capability to run or even compile it. Kind of like writing a book without being able to proof read it before publishing. I have a hard time getting even "Hello World" programs to compile & run without some sort of goof-up on the very first go.