I have one file in which I use "int16_t x", when I declared it in other file, by mistake I have declared "extern int8_t x". i.e int8_t is used instead of int16_t.
But compiler do not generate warning for this. Why. Is there any method for it or it has to be taken care by the programmer only.
How could it?
Remember that the compiler only "sees" one compilation unit (usually, one .c file and all its #includes) at a time - it has absolutely no knowledge whatsoever of anything else.
The only way that the compiler knows about external symbols is through the information that you provide in extern declarations - so it's up to you to ensure that they are correct!
A common way to do this is to have:
file1.h
extern int16_t x;
file1.c
#include "file1.h" int16_t x;
Then, when it compiles file1.c, the compiler does see both the extern declaration and the definition of x - and can give a warning if they don't match!
This is standard, basic 'C' - nothing specifically to do with Keil or ARM.
c-faq.com/.../decldef.html
quote: Remember that the compiler only "sees" one compilation unit
Obviously this should say something along the lines of: Remember that most "C" compilers only "see" one compilation unit at a time.
In truth, there is much scope for a compiler to be far smarter. Compilers such as GCC accept multiple source file names on a single command like. The fact that it only opens one at a time is not a specified requirement.
However, the rules concerning public and external usage are.
There was a reason why C++ added type-safe linking by using name mangling, where the symbol names of external symbols are mangled with extra character data representing the data type of the symbol.
So an int8_t variable and an int16_t variable using the same name in the source code would have different names in the object files resulting in a linking failure.
But as noted earlier - the code should be written so the compiler sees both declaration and definition and can spot any important difference. So all files making use of a variable should include the header file where the variable was mentioned.
"Compilers such as GCC accept multiple source file names on a single command like."
Just that gcc isn't a C compiler. It is just the command line processor that will take a command line with a list of source files object files libraries flags etc and then send out the relevant information to one or more background programs that does the actual work of compiling, assembling and linking.
gcc isn't alone in supporting many source file names on the command line - just about all C compiler tools supports that. But the actual compiler part of the tools sees one source file at a time. Then optimization tools may perform cross-module optimization by walking anre rewriting the expression trees created by the compiler before they generate the machine code output.
Quote: Just that gcc isn't a C compiler.
True. But that is the end of the package that people most frequently consider to be the one used to compile a unit or an application. Microsoft have the same with cl for compilers and ml for assemblers. I wonder how many people would use (or even know of) the executable that is triggered by these key applications.
So, that being the case, it is quite possible (and indeed not unusual) for the compiler to 'go the next step' and do global optimizations, verification checks etc.
Indeed there is.
But there is no requirement for them to be so, and many (most?) aren't - clearly, "the" compiler in question here is one such.
Quote: But there is no requirement for them to be so, and many (most?) aren't
I remember reading an article from Microsoft on their (then proposed) compiler technologies which spoke about doing this very thing. I gave up at the .net system, maybe they implemented such things in that.