why some c programs are not run even if there is no error in compile time??????????
why some c programs are not run even if there is no error in compile time??????????
Such as ?why some c programs are not run even if there is no error in compile time??????????
You mean like this one:
Because the compiler does not check stuff like this. Perhaps it should, and this is a performance trade-off in the compiler.Code:#include <stdio.h> #include <string.h> int main() { char *overflowme; strcpy(overflowme,"this will overwrite some memory"); printf("%s", overflowme); return 0; }
On the other hand, programming need not be quite so easy as throwing darts blindfolded (which really is easy if you don't care what you hit). You have to know what you are doing. To know you have to learn, partially thru a process of trial and error. It's not nearly as painful as learning to ride a bike, and you already did that (hopefully).
Lesson: Don't expect the compiler to fix everything for you, and be happy when it does.
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
A compiler doesn't check if you're doing meaningful things. It only checks if you're doing correct things.
I don't think many compilers will complain at this:
Even though it is clearly undefined behaviour.Code:#include <stdio.h> int main(void) { printf("The mystery is solved: *NULL is %d\n", *(int *)NULL); return 0; }
Compilers can't check logic errors or care much whether there are even any output statements. That should be obvious.
The compiler just checks to make sure you use correct syntax, it doesn't check to make sure your code is coherent.
The warbling of the instantiated was blue.
Perfectly good syntax, with no meaning whatsoever.
And if you do this:
GCC -O3 will just ignore the statements in red as if they didn't exist, because they are meaningless in the context of the program.Code:int mostlypointless (int x) { int a = 12, i; for (i=0; i<10; i++) a = a*i+a; return x+1; }
The only way to notice this (I guess) is if you use massive meaningless loops for profiling. Compiled gcc -O3, they won't happen.
Last edited by MK27; 07-25-2009 at 04:34 AM.
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
Newer compilers for other languages are 'attempting' to do this and it comes off to me as 100% annoying. Maybe it's because I don't like my hand being held while I code.
It's extremely helpful to offer such code analysis, because it can find problems in your code.
Naturally, it is also slower, so there should always be an option to turn it off. Otherwise the compiler is flawed.
Or perhaps you don't like the compiler removing certain code in optimizations?
>> They can, and some do.
To a very limited extent, but for the most part they can't.
When it comes to incorrect manipulation of certain things, 'const' does a good job for protecting against this - if for some reason the programmer doesn't want to use it, that's his problem.
Hmm... I disagree. That's definitely not the task of a compiler. Abachler said it best.
That type of code analysis can and should be done by specialized tools only. MSVC offers those tools in its Team System releases. Tools like Code Metrics, C/C++ Code Analysis Tools, Application Verifier, Line Level Sampling and even Code Profiler (and there's even more).
Note that by "compiler", I mean the actual task of code compilation. In this context I don't agree such tasks should be implemented. In fact I suspect most of them couldn't, since better diagnostics can only be achieved after compilation and during program execution with access to debugging symbols, which is what most of the tools above do. On the other hand, if we consider the tasks of a compiler (lexical analysis, pre-processing, parsing and code generation with/without optimization) we can see there is really no place for such analysis as the excellent example provided by Mk27 demonstrates.
Again, go back to abachler statement. There's an underlying truth to it that basically says it's not the task of the compiler to make sure your code works as you want it to.
Last edited by Mario F.; 07-25-2009 at 01:16 PM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.