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.
uint some_var; struct stObJ{ uint address; uchar object_nr; }; struct stObj *stPtr_Obj; stPtr_Obj->address = &some_var; ptr_xdata = stPtr_Obj->address;
Let's take the structure away, as that just complicates it unnecessarily. So it boils down to:
uint some_var; // A uint uint my_uint; // Another uint uint *my_ptr; // A pointer to a uint my_uint = &some_var; my_ptr = my_uint;
So I guess your real question here is:
Why does
my_ptr = my_uint; // Assign a uint value to a pointer
generate a warning when
my_uint = &some_var; // Assign a pointer value to uint
doesn't?!
That's a good question!
I guess it's becuase the former is more likely to be immediately dangerous than that latter - since a very high proportion of 'C' bugs are due to bad pointers...!
Remember that 'C' is not a strongly-typed language, so you will only get warnings on things that look really suspicious.
Clearly, Keil have revised their opinion of what warrants a warning - which is why you get the warning now that you didn't before - but still don't consider the pointer-to-uint worth a warning.