I have the following error on my simulated program.
Error C267 Funcdef Requires ANSI-Style Prototype Summary *** Error C267 Funcdef Requires ANSI-Style Prototype
Description A function was invoked with parameters but the declaration specifies an empty parameter list. The prototype should be completed with the parameter types in order to give the compiler the opportunity to pass parameters in registers and have the calling me
Copyright (c) Keil - An ARM Company. All rights reserved.
That was the error description, can anybody tell me how to correct it?
This is the code: #include "Main.h" #include "Simple_EOS.H"
#include "PC_IO_T1.h"
/* ...........................................................................................................................*/ /* ........................................................................................................................... */
void main(void) { // Set baud rate to 9600: generic 8051 version PC_LINK_IO_Init_T1(9600);
// Set up sEOS (5ms tick) sEOS_Init_Timer2(5);
while(1) // Super Loop { sEOS_Go_To_Sleep(); //Enter idle mode to save power } }
This is an example of the Addison_Wesley_Embedded_C.pdf
That some, out of ignorance, see the error and do not worry about the warnings (showing the cause of the error), is not the fault of the compiler/linker.
A failure to open a header file shouldn't be classified as a warning. It is definitely an error! I, have a quite complex build scheme (I buld 47 different things, with various commonality, from a somewhat complex file structure (if a=1 include file group a1 combined with (if b=2 gropup lnclude file group b2 combined with (...))). In such a construct, there often will, initially, due to 'cross pollination' be an include of something that is not used and may not be found. If I had to take care of such being an error during initial development of a new subset it would be a pain, the warnings are, of course, removed before release.
Since the compiler has no means of determining if a given missing header contains needed information (how could it, it can't find it) the only thing a compiler can do is tell it is missing. Thus I agree with it being a warning.
This, of course, bring this discussion a full cycle to my original statement "do not ignore warnings".
My opinion of errors/vs warnings: both should indicate a problem, if the compiler/linker can live with it it should be a warning, if the compiler/linker can not, it must be an error and I do believe that is the 'rule' for Keil tools.
Erik
"Since the compiler has no means of determining if a given missing header contains needed information (how could it, it can't find it) the only thing a compiler can do is tell it is missing. Thus I agree with it being a warning."
I thoroughly agree.
"My opinion of errors/vs warnings: both should indicate a problem, if the compiler/linker can live with it it should be a warning, if the compiler/linker can not, it must be an error and I do believe that is the 'rule' for Keil tools"
Yea verily 'tis so: http://www.keil.com/support/man/docs/c51/c51_er_errorwarn.htm