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.
"I can see no wrong use of the pointers."
You're code is wrong.
The best method of removing the error is to correct the incorrect code!
No, it's not actually wrong - it's just suspect - which is why it only gets a warning, not an error.
"The best method of removing the error is to correct the incorrect code!"
There isn't an error to remove - but, as has already been explained, the suspicion could be removed by using an explicit cast!
Ok, I'll go along with the suspect.
That said, I always feel safer by treating warnings as an indication that the code/project needs modifying; if only to examine the suspect line and override the compiler's message.
In other words, I treat warnings as errors.
Anyway, the OP seems to have given up debating the point ... Maybe he's (finally) understood?
And the even better method is of course to learn how pointer indirection works. Then the Address field could be changed from uint to a pointer of the proper type - and no typecast would be needed.
Maybe he's (finally) understood?
I haven't seen any "Hey, thanks guys for explaining it to me." messages yet.
He may have just left to try his luck in a different forum.
Just noticed an update to the C51 compiler, bringing it up to 8.20.
Hope it reports the same warnings, else the OP will start all over again!?
More than 100 posts just because a broken assumption about how to use pointers...
About unsure/confused/insecure compilers. The developers of the compiler knows that some translation rules are less likely and that there may be a good idea to warn the user.
However, the compiler is most definitely without any feelings. And I'm pretty sure that the developers of the compiler are reasonably sure about what they do, and what they want their compiler to do.
It is all probabilities and experience. Compilers are normally designed (and the language it handles) by knowledgeable people. Knowledge normally implies experience. Experience tells that some constructs are seldom intended - such as the traditional if (a = b) ... - and it is then a good idea to add a warning. But the compiler is not unsure. And the compiler developers are not unsure. They are on the other hand suspecting that the end user is unsure - or just clueless...
Well, kinda flaming me for using the wrong terms (if millions of people think the same way, it's not necessarily correct, as the history shows) is actually not the help I hoped for. I actually found the only one solution that helped getting rid of this warning:
ptr_xdata = (uchar *) stPtr_Obj->Adresse;
The cast is the solution. It was hidden amongst the many text that was written telling me what to DO NOT, instead of telling me what to DO.
Thanks anyway, guys. I know you only did your best and I also know that you are so much into programming (and perhaps doing nothing else in your job) that you are unable to even consider a different terminology for the same understanding (I always knew what pointers are, I just call it differently). I guess the biggest problem with this compiler warning was the little word "conversion". Because when it says "conversion: non-pointer to pointer" for the line of code above, then it's clear for me that ptr_xdata is meant. And this pointer is not converted, it's indirectly set to a variable. So the whole confusion just started by a silly english warning...
No, you have never been flamed for using the wrong terminology.
It is a border case that you have been flamed: But for completely refusing to accept that your terminology is incorrect.
if millions of people think the same way, it's not necessarily correct, as the history shows
Not applicable, since we are not talking about what millions of people think, but what a few number of people have defined.
No, the cast was not hidden away somewhere. It has been discussed a number of times in a number of posts, but you have totally failed to understand our posts, since you have been using a home-grown vocabulary.
We have also discussed - multiple times - why the cast would not be needed at all, i.e. why the Adresse field shouldn't have been an integer but a pointer in the first place.
1000ml of water is the same as 1 litre of water. Still, you do a conversion of units when switching between the two. In the same way, the compiler has to do a conversion of data types (and in some cases a conversion of the binary representation).
"The cast is the solution. It was hidden amongst the many text that was written telling me what to DO NOT, instead of telling me what to DO."
No, it was not in the least bit hidden - I stated it very clearly and explicitly in the very first reply in this thread - 5-Feb-2008 06:36:
"As usual, an explicit cast should both stop the warning and make your intention clear"
Nothing hidden there at all!
How can that possibly be clear?
The line
ptr_xdata = stPtr_Obj->Adresse;
clearly has one pointer - that's ptr_xdata - and one non-pointer - that's stPtr_Obj->Adresse
The line is clearly and assignment from the non-pointer (on the Right-hand side) to the pointer (on the Left-hand side)
In any assignment, it is always the RHS that gets converted to the type required by the LHS (ie, the thing receiving the assignment).
"So the whole confusion just started by a silly english warning..."
No, the whole confusion is caused by your insistence on using words with a completely different meaning from everyone else.
If you insist on calling "left" what everyone else calls "right" then you are obviously going to cause confusion! It is you that is the cause of the confusion!
If you want to use a terminology that differs from everyone else, then it's up to you to do the conversion when communicating with others.
It's already been shown that your terminology doesn't even make sense in your native German!
"you are unable to even consider a different terminology for the same understanding (I always knew what pointers are, I just call it differently)."
OK, then - please translate the following into your terminology:
Address: 100 101 102 103 104 105 106 ...+------+------+------+------+------+------+... Memory Content: | 986 | 100 | 102 | ...+------+------+------+------+------+------+... Name: my_uint my_ptr my_ptr_ptr
The address of my_uint is 100, and the value of (ie, the value stored in) my_uint is 986; The address of my_ptr is 102, and the value of (ie, the value stored in) my_ptr is 100; The address of my_ptr_ptr is 104, and the value of (ie, the value stored in) my_ptr_ptr 102.
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...
Well, kinda flaming me for using the wrong terms
What is "kinda flaming" ? Is that along the lines of "kinda pregnant" or "kinda dead" ?
A short text search over this thread shows a complete lack of terms usually associated with flaming (like "idiot", "moron", and the like), and the only "stupid" refers to computers being stupid machines.
(if millions of people think the same way, it's not necessarily correct, as the history shows)
If you're driving on the highway and hundreds of cars are coming your way, it's most likely because you're in the wrong lane.
Hidden ? How can it be hidden ? The text on my screen is quite high contrast (black on very light grey). In fact, you have stated that you tried doing a cast and that it did not help, and then you've been asked repeatedly to post the line containing the cast so we can check whether it is correct, with no response from your part.
There's nothing "hidden". You just did not bother to read the thread, because people were asking you to use accepted terminology instead of your own inventions, which probably ticked you off.
I know you only did your best and I also know that you are so much into programming (and perhaps doing nothing else in your job) that you are unable to even consider a different terminology for the same understanding (I always knew what pointers are, I just call it differently).
Hum hum. Is that you "kinda flaming" us ?
Because when it says "conversion: non-pointer to pointer" for the line of code above, then it's clear for me that ptr_xdata is meant.
Why ? The line says that a non-pointer is getting converted to a pointer. ptr_xdata quite clearly is a pointer, so it cannot be a non-pointer. Why does this line make it clear to you that ptr_xdata is being converted ?
And this pointer is not converted, it's indirectly set to a variable.
And you're doing it again ! You're again making up terms ("indirectly set") for something that already has a clear and concise term ("implicit conversion/typecast"), and then you wonder why people are having trouble making sense of what you write. The line in question does exactly what the compiler says it does. It converts a non-pointer (stPtr_Obj->Adresse) to a pointer.
So the whole confusion just started by a silly english warning...
It's not the compilers fault that you think that a clear and concise warning message is "silly".
Wow, you native english-speaking guys (are you?) seem to be very sophisticated about terms. "Kind of flaming" just means that you nearly flamed me. Flaming just means, at least for me, that someone was blamed or accused of something without the need to do so.
Always depends on the point of view. The one driving on the (apparently) wrong lane always thinks any other driver is on the wrong lane.
I'll explain to you what I meant. To find one certain line of the many code examples in >100s posts in this thread is not easy, because I don't read any post, of course (uses too much time). The most ones where not really helpful. So I just found it was hidden, because it does not pop out so clearly that you see it at the first glance.
Actually not. I never said you are wrong. But you keep telling me. Just because I have a different view, I'm wrong in your eyes. No comparisons!
Because when it says "conversion: non-pointer to pointer" for the line of code above, then it's clear for me that ptr_xdata is meant. Why ? The line says that a non-pointer is getting converted to a pointer. ptr_xdata quite clearly is a pointer, so it cannot be a non-pointer. Why does this line make it clear to you that ptr_xdata is being converted ?
Correct me if you need to, but I understand "convert" as "turn into" or "change". The target is ptr_xdata and the source is stPtr_Obj->Adresse. Since the source is never converted (or changed) in such a case, ptr_xdata is the subject to be converted and that's why the warning does not makes, because it's actually not converted.
And you're doing it again ! You're again making up terms ("indirectly set") for something that already has a clear and concise term ("implicit conversion/typecast")...
Oh, "implicit conversion"! Wow, what an intelligent phrase. Forgive me if I'm not intelligent enough to create such phrases because my native language is not english and that I'm not learning such phrases in order to use them so that you can understand me, while "setting a pointer" turns out to be completely incomprehensible. I should be learning another meaning of the word "conversion" than I always had in my life, just to understand "implicit conversion" as you seem to understand it. For me, a conversion is still a change of type/form/shape, but the pointer is not changed in his type, it is only set to point to a new address. In my humble silly words: the pointer is set. Set to a value which represents an address of a variable, which makes the pointer point to that variable.
It was hidden amongst the many text that was written telling me what to DO NOT, instead of telling me what to DO.
In my early days in this field I lerned much more from the don'ts than from the do's.
a "don't" represent ONE thing to avoid, where a "do" usually represent one possibility of many.
Several posters in various fora have expressed ire about being told "don't" but, In my honest opinion" these (while requiring the OP to do some work, which the do's do not) are ever so much more 'educational'
Erik
PS to Andy: I am in apostroph trouble above, since this seems to be your specialty would you be kind enough to clear that up for me for "educational purposes".