"I was asked to write a software to do exactly what you read. Take a code and check for its errors. Somewhat like a compiler that indicates the issue stopping a code from compiling or being correct."
And that a problem. Probably a very, very big one.
There are two big limits here: "error free compilation" - which depends on the compiler and environment that the code is intended for: there are a huge number of C compilers each of which will consider different things as "errors" for example, and code written in C for an embedded device will not compile for Windows for another. The only practical way to "prove" compilation correctness is to duplicate exactly what each compiler will do...
The second is a lot, lot bigger. You can't prove "correctness" of an application in isolation - only by referring to the actual specification it was written to.
For example:
using System;
using System.IO;
namespace TCFConsole
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello World!");
}
}
}Is a "correct program" in C# in the sense that it compiles ok and doesn't crash - but it doesn't work at all well if it is supposed to be a word processor!
I think you have possibly bitten off more than you can chew, and need to think very, very carefully about exactly what you are going to accept and what your "correctness" is going to be.
Then you can start thinking about how to implement it.
Even if you restrict it to indicating the actual problem in compilation, that's a nightmare!
Compilers do their best to say "this is where I found the problem" but that isn't the same as saying "You forgot to close your string here" when I leave out a double quote and it doesn't become a problem for a couple of hundred lines...:laugh:
Submit an article or tip