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.
The address of my_uint is 100, and the value of (ie, the value stored in) my_uint is 986; The same in my terminology, because it's a normal variable The address of my_ptr is 102, and the value of (ie, the value stored in) my_ptr is 100; In my terminology the address of my_ptr is 100 the value of my_ptr is 986 The address of my_ptr_ptr is 104, and the value of (ie, the value stored in) my_ptr_ptr 102. In my terminology, the address of my_ptr_ptr is 100 and the value of my_ptr_ptr is 986. If my_ptr changes its address, the address of my_ptr_ptr also changes and thus its value. Because for me it is only relevant to concern the address the pointer points to and the value at this address. That's why a pointer to a pointer does not make sense for me at all. It makes it only harder to distinguish what's what.
And if I repeat the x-th time, I know YOUR terminology and I know MINE. Mine is easier to understand for me. You only know YOUR terminology, that's why you try so hard to convince me, that you are correct (what I don't contradict) and that I'm terribly wrong (what I also don't contradict, but I don't know why I should tell you - just because to make you satisfied for being right? No!). The code works anyway, with or without the cast. I was only a little irritated by something not self-explaining.
But one thing I have to admit you to be correct with: Struct member Adresse should be a pointer. Well, it's not my code and the strange thing is still that compiler version 7 does not warn about it, while version 8 does. But in another part of the code I used a similiar assignment and there the version 7 did warn me. That's what I meant with confusing.
And, last but not least, I found the thread somewhat funny. How people can get obsessive about this little topic...
In "my" terminology, the terms "address of" and "value of" always have the same meaning irrespective of whether we're talking about a pointer or any other type of variable.
"your" terminology makes the same terms have different meanings depending on whether they're applied to pointers or other variables. Where is the benefit in that?! Surely that just makes it more confusing - as the same terms have different meanings in different contexts! It's just illogical!
"That's why a pointer to a pointer does not make sense for me at all."
It would make a lot more sense if wasn't for the needless confusion of your terminology!
Just because you don't understand a thing is no reason to mess-up the terminology for people who do understand it - and, in fact, need to use it!
The diagram illustrates perfectly clearly how a pointer-to-a-pointer does have a meaning - and a logical, consistent terminology makes it easy to understand.
This is why your terminology is fundamentally flawed: because it is actually common to use pointers-to-pointers and your terminology, on your own admission, cannot handle that.
It's not that people can't conceive that a different terminology is possible; it's that your terminology is so obviously flawed and unable to cope with the real requirements of 'C' programming - such as pointers-to-pointers!