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.
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.
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.
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".
Flaming just means, at least for me, that someone was blamed or accused of something without the need to do so.
Yes, we are acusing you of being unhealthily stubborn. When the world has one definition of a metre, and a single individual decides on a distance only half as long, the problem is not semantic. We are not talking about which nuance of red that is the most beautiful. Such questions does not have a correct answer - everyone is free to have their own opinion. When it comes to the definition of a pointer, there are no room for opinions. You just have to follow the terminology of the inventors of the pointer concent - and the inventors of our programming languages - and the authors of all books - and the ...
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. Yes - the drunkard do tend to think the others are in the wrong lane... Are you bashing yourself, or just selecting bad examples?
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.
There would not have been 100+ posts if you have spend some time and read the 5-10 first answers instead of deciding on running around blindfolded.
You would have learned why the cast was needed. You would have learned how to avoid the cast. You would have learned the terminology needed to read books. You would have learned why multiple indirection is both needed and elegant.
Sorry, we can't chew your food for you. Some things must be up to you. If you like running around with a blindfold, you will get a lot of bumps in your head.
Correct me if you need to, but I understand "convert" as "turn into" or "change".
And if you had spent just a tiny little bit of time reading this thread, you would know that you can convert binary data. You can convert data types. You decided that convert must be a binary conversion, and failed to realize that the compiler has more than a single attribute it cares about for a variable. It careas about the name, the type, the size, the location, ... In this case, the types did not match, so the compiler had to do a type conversion. But not of the pointer. It needed to to a type conversion of the integer. The source had to be converted to fit the destination, i.e. the standard way (and only way possible) in programming languages with pre-typed variables.
Oh, "implicit conversion"! Wow, what an intelligent phrase.
Explicit and implicit (and what they stands for) are standard words in most (all?) modern languages. I agree - there are natives living in the jungles who may not have a need for this concept. But they are the exception.
Explicit type cast: You have to inform the compiler. Implicit type cast: The compiler have to figure out the conversion itself.
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.
Not at all. You just have to realize that there can be more than one attribute involved, so it need not be the value that needs conversion. In this case it is the data type. In some cases, a type conversion will imply a conversion of the value too.
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.
Exactly. The pointer's value is an address. But that is not what you have argued about time and time again in this thread. Do you have so twisted terminology that you don't remember what your point is, even in your own terminology? You have again and again and again claimed that the value of the pointer is the value of the integer, instead of the address of the integer, and that addresses of pointers are irrelevant.
but the pointer is not changed in his type... No, but the integer (Adresse) is changed in his (masculinum?) type since the compiler (explicitly or implicitly) has to convert from the uint data type to a pointer data type. Did you forget that? Do you have so twisted terminology that you don't remember what your point is, even in your own terminology?
You just have to follow the terminology
because I don't read any post, of course (uses too much time).
the above made me realize that writing posts to help you and others "of course (uses too much time)". I will definitely consider that in the future.
so, if anyone wants to help Maik Staberock they should be aware that doing so "uses too much time" and refrain.
The Address Of a variable always means the memory address at which that variable itself is located - no ifs, no buts, no exceptions = no confusion;
The Value Of a variable always means the value stored in the variable itself - again, no ifs, no buts, no exceptions = no confusion;
How can adding complexity by having the terms mean different things in different contexts be anything but more confusing?!
"Kind of flaming" just means that you nearly flamed me.
Yes, and "nearly flamed" makes about as much sense as "nearly pregnant".
You may consider youself flamed if you see certain four-letter words and clearly derogatory insults (idiot, moron, and the like).
The driver who thinks that he's in the correct lane and everyone else isn't needs to have his license yanked as soon as possible, and probably needs to seek medical help.
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 first posting that mentions an explicit cast as the solution to your problem is the second response (the first response to the original posting was actually written by you. Reading the second posting takes too much time ? That does not make sense.
Actually not. I never said you are wrong.
Oh yes you do. We are wrong for not following along with your made-up terminology. That statement is pretty much implied in any of your postings on the matter.
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.
O ... kay.
The line in question tells the compiler the following:
1. Take the value of stPtr_Obj->Adresse. 2. (implicit) Convert this value to the datatype of ptr_xdata if necessary. 3. Assign this value to the variable ptr_xdata.
Step 2 involves turning a non-pointer (the value of stPtr_Obj->Adresse) into a pointer (the data type of ptr_xdata). This is very clear to the compiler, since the C standard demands it. If you think the compiler should not adhere to the C standard, but follow your line of thinking, then you need to write your own compiler (possibly with your own programming language, since that compiler won't qualify as a C compiler).
It's not about intelligence. It's about the terminology used in the C standard and the literature. It's about the terms that seasoned C programmers will use and understand. It's about being concise and getting your point across.
You don't need to be intelligent to use the correct terminology. However, you need to want to use the correct terminology, and this seems to be somewhat lacking. You are posting in English, so you're following some of the conventions. What's so difficult about going all the way and actually using the right terms ?
The compiler does not care about "represents". It does not know what a variable is supposed to represent. It cannot read you mind. For the compiler, you are assigning an integer to a pointer, and this requires a type conversion.
In this thread you are advising:
ever tried an internet search with the wrong terminology
Yet in another thread you are insisting that your terminology is perfectly acceptable:
http://www.keil.com/forum/docs/thread11843.asp
Even though Google tells us:
Your search - "merging execution strings" - did not match any documents.
I find it extraordinary that you are arguing the same argument from opposite standpoints in two threads simultaneously.
I guess you know what merging means and "execution string" returned 3,810 hits.
You seem to be quite good at picking apart, that is nice
A pointer is slightly different. In your terminology the pointer value is the same as a variable's value, because this value is stored in the location (address) of the variable/pointer. But... the pointer also points to a value, not only an address. It points to the value at the address. And how do you call this value? I have no other name than to call it the pointer's value (or pointed value). That's what I always said. For my code it was always important where a pointer points to and what the value of this address was, normal pointer operation that is.
I still don't get why setting a pointer of type uint to an address given by a value of type uint is conversion or why it is called conversion. For me it is an assignment. Something totally different to a conversion:
uint *ptr_xdata; uint address; ptr_xdata = &address;
is logically the same as
uint some_var; struct stObJ{ uint address; uchar object_nr; }; struct stObj *stPtr_Obj; stPtr_Obj->address = &some_var; ptr_xdata = stPtr_Obj->address;
like I was writing it all the time and that's why I'm not very delighted (confusion has gone since I managed to figure out what the compilers considers as conversion) about the compiler warning. Because on the upper example it does not warn about conversion. It's not the terminology.
the above made me realize that writing posts to help you and others "of course (uses too much time)". I will definitely consider that in the future. Only if the replies are constantly saying "you naughty boy, don't you use the wrong terminology" instead of "hmm, the compiler has its own style of warning you. You need to read between the lines".
Because the topic wasn't that my colleague who wrote the code has forgotten the implicit cast or that the pointer operation was actually a bit wrong, it was about the fact, that the Keil compiler warns you in the one version and not in the other. And this warning isn't always created when compiling, it only happens from time to time. That's why I said in one of my posts that the compiler doesn't seem to know what to do in some situations and it then confuses the user with warnings you might not understand while being absolutely sure the code is correct (because it runs as desired).
Only if the replies are constantly saying "you naughty boy, don't you use the wrong terminology" instead of "hmm, the compiler has its own style of warning you. You need to read between the lines". Sorry, but you can't back that up. The majority of the text in the replies you have received tries to explain the reason for the naming. But whenever someone says why something is important, you answer with: But I don't care about that. For me xx is the only important thing. You write answers, but you never seem to spend time trying to read the posts before answering to them. Without any bandwidth allocated for input, you can't expect good quality of your output.
But... the pointer also points to a value, not only an address. It does not point to both a value and an adderss. It has an address as it's value. It may point to an address - in case it is a pointer to a pointer. In your case, it is a pointer to a uint, so it does not point to an address - it points to a uint. You have specifically said that you don't care about dual indirection, so your pointers never points to an address...
confusion has gone since I managed to figure out what the compilers considers as conversion Your examples shows that you have not managed to figure out what the compilers consider a conversion. If you did understand your two examples, you should be delighted that the compiler notices the problem with one of them.
It should be obvious why one case needs a manual (explicit) typecast to make sure you don't get a warning, while the other example does not need neither implicit nor exmplicit type cast.
&address means "address of uint" and means that there is no need for a typecast - the right-hand side already have the correct data type for assigning to your pointer, since the value of a pointer to uint is an address to uint.
Assigning &address to a uint means that you throw away the information that the value represents a pointer. The result: Most compilers will warn about the type conversion needed, to convert from uint to "address of uint".
In this case, the newer version of the compiler has been improved. Some compilers has the special case that they are silent only for assign of the integer value 0 (i.e. a NULL pointer, but complains about any other integer-to-pointer assigns).
"A pointer is slightly different."
It still has an address at which it is stored, and a value which is stored in it - from that point-of-view, it is no different from any other variable. Hence there is no reason to give these properties different names - that only causes confusion.
"It points to the value at the address. And how do you call this value?."
It is called, very simply, the pointed-to value!
"I have no other name than to call it the pointer's value (or pointed value)."
Haven't we already established that doesn't make sense - either in English or in German?
"The pointer's value" has identical meaning to "the value of the pointer" - the two expressions are equivalent.
Just as "the car's colour" has identical meaning to "the colour of the car"
And the value of the pointer (the pointer's value) is not at all the same as the value pointed to by the pointer!
Try this:
void main( void ) { int my_int = 1234; int *my_ptr = &my_int; printf( "The int's value is: %d\n", my_int ); printf( "The value of the int is: %d\n\n", my_int ); printf( "The address of the int is: %p\n", &my_int ); printf( "The int's address is: %p\n\n", &my_int ); printf( "The pointer's value is: %p\n", my_ptr ); printf( "The value of the pointer is: %p\n\n", my_ptr ); printf( "The pointer's address is: %p\n", &my_ptr ); printf( "The address of the pointer is: %p\n\n", &my_ptr ); printf( "The pointed-to value is: %d\n", *my_ptr ); printf( "The value pointed to is: %d\n\n", *my_ptr ); }
My results with Borland on a PC are:
The int's value is: 1234 The value of the int is: 1234 The address of the int is: 0012FF88 The int's address is: 0012FF88 The pointer's value is: 0012FF88 The value of the pointer is: 0012FF88 The pointer's address is: 0012FF84 The address of the pointer is: 0012FF84 The pointed-to value is: 1234 The value pointed to is: 1234
"I still don't get why setting a pointer of type uint..."
STOP right there!
That is your basic problem: there is no such thing as "a pointer of type uint"
What you have is a pointer to type uint
"why it is called conversion."
Because they are different types!
"uint" is a type and "pointer to uint" is a different type!
"For me it is an assignment. Something totally different to a conversion"
No - it is an assignment that involves a conversion!
Just as assigning from a float to a uint would involve a conversion (from float to uint).
And how do you call this value?
Value of the dereferenced pointer.
I still don't get why setting a pointer of type uint to an address given by a value of type uint is conversion or why it is called conversion.
Because "pointer to uint" and "uint" are two completely different types for the compiler, that need to be treated completely differently in a number of cases.
Okay, I'll repeat my little quiz for the third time:
unsigned int some_int = 0; unsigned int *some_int_ptr = 0; some_int++; some_int_ptr++;
What is the value of some_int after this snippet ? (that's easy, right) ?
What's the value of some_int_ptr after this snippet ? (or - is it even possible to answer this question?)
uint some_var; struct stObJ{ uint address; uchar object_nr; }; struct stObj *stPtr_Obj; stPtr_Obj->address = &some_var; // st_ptr_Obj->address is a uint, // &some_var is a pointer to uint. TYPE CONVERSION. // (Yes, believe me, it's really really really true) ptr_xdata = stPtr_Obj->address; // ptr_xdata is a pointer to something, // stPtr_Obj->address is a uint. // ANOTHER TYPE CONVERSION.
like I was writing it all the time and that's why I'm not very delighted (confusion has gone since I managed to figure out what the compilers considers as conversion) about the compiler warning.
Believe it or not: The compiler is correct. Your problems with understand this fact and the reasons for it stem from a) misconceptions about the data type "pointer to something" and b) very big misconceptions about what the "member reference from pointer" operator "->" does. "->" does _not_ return an address, it returns a value. Please please please believe it, it's true.