#include "stdio.h"
#include "cpu.h"
#include "memory.h"
void cpu_start()
{
for (;;)
{
int test = 5;
exec_8(test);
StepIP(1);
}
}
void exec_8(int a)
{
}
I get these warnings
root@bt:~/Desktop/x86Emu# bash build.sh
cpu.c:17: warning: conflicting types for ‘exec_8’
cpu.c:9: note: previous implicit declaration of ‘exec_8’ was here
x86Emu compiled!
I would hazard a guess that it is complaining because you call exec_8 before you define it. So it guesses the return type to be an int, and later discovers it to be void. Either use a prototype, or place exec_8 before the function which calls it.
The continuous image of a connected set is connected.
mathematician wrote:I would hazard a guess that it is complaining because you call exec_8 before you define it. So it guesses the return type to be an int, and later discovers it to be void. Either use a prototype, or place exec_8 before the function which calls it.
Other than the fact that C only does one pass and has implicit declarations, there is no such thing as stdio.h (i.e., the fact that you included it with quotes worked by mistake but can break elsewhere), only <stdio.h> (as it needn't be implemented as an actual file), as is the case for all standard library headers.
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
Love4Boobies wrote:Other than the fact that C only does one pass and has implicit declarations, there is no such thing as stdio.h (i.e., the fact that you included it with quotes worked by mistake but can break elsewhere), only <stdio.h> (as it needn't be implemented as an actual file), as is the case for all standard library headers.
So what your saying is for standard libraries in the operating system use
You can probably use #include "library" if you want but you have to understand your implementation to make sure. File inclusion is not determined by the language, but by the implementation. Even the difference between the two methods of file inclusion in ANSI C depends upon something that is described as "deliberately implementation-dependent" in section A12.4 of the second edition of Kernighan & Ritchie. If you don't have that book then you maybe want to get your hands on it.