Hello!
I have uVision that compiles fine with the C51 v7.03 compiler and the related package, but not complete with the 8.06. I used two different Keil installations. All files are in the same folder.
In the 8.06 I get linker errors like "object does not fit in to pdata page" and "0080H". This looks like the compiler was thinking the PDATA was only 128 bytes, but it is set to 256 bytes in the startup.a51. Any clue what's different in the newer Keil package?
Also there is a warning in 8.06 (which does not show in 7.03) "converting non-pointer to pointer" on this
ptr_xdata = sPtr_obj->Adresse;
while the vars are set like this:
uchar uc_set_obj( uchar pdata *ptr_Set) { uchar i; uchar xdata *ptr_xdata; struct stOBJADR code *sPtr_obj; sPtr_obj=&Obj[*ptr_Set]; . . . ptr_xdata = sPtr_obj->Adresse; }
The struct stOBJADR has a member "uint Adresse;"
I can see no wrong use of the pointers. I just want to be sure that the warning does not affect the code to not work correctly.
Not sure why you talk about K&R. Most people only care about ISO/ANSI, with the exception of any non-standard extensions needed for the specific platform.
Not just the number of parameters that are important.
A function may expect to receive a long, float or double parameter but get an int. The compiler doesn't know if it is expected to convert the data type when sending the parameters.
The compiler doesn't know if the function returns any value or not, and in such case if the return value is of a different type than int.
Quite a number of compilers have also support for different calling conventions, for example: - Normal C, where the caller cleans the stack (supports a variable number of parameters) - Pascal, where the function cleans it's parameters before returning (generates smaller code). - Fast call, where the parameters are sent in registers instead of on the stack (generates faster code). - ...
In the end, there are very big incentives to supply a function prototype to the compiler, since the alternative can be a very bad crash when running the program. I would guess that most people usually treat this warning as an error, and don't spend any time trying to run the application. The probability of incorrect code generation is too high.
I would guess that most people usually treat this warning as an error, and don't spend any time trying to run the application. The probability of incorrect code generation is too high I totally agree with treating it as an error, the only caveat I have is that, occasionally, I'll realize "no problem" and run a session and THEN in the next editing that comes up, fix it. I would NEVER release anything with ANY warning.
Erik