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.
As you say, ptr_xdata is a pointer, and sPtr_obj->Adresse isn't - so the warning is perfectly correct!
As usual, an explicit cast should both stop the warning and make your intention clear...
"I just want to be sure that the warning does not affect the code to not work correctly"
There is always a risk in playing fast-and-loose with pointers like this!
I think you should be OK with the XDATA-Specific pointer...
Hello Andy! Thanks for your help.
You are wrong. "sPtr_obj->Adresse" is a struct pointer and gives me a number, an address that "ptr_xdata" is set to.
The compiler will do exactly what you tell it to do - but, as mentioned earlier, if you cannot express what you want correctly, then the compiler cannot guess for you... "the compiler was unsure how to handle it." Often, a compiler will try to figure out what you ment and instead of an error issue a warning, which, in a way means "the compiler was unsure how to handle it.". Then, it is up to you to accept "unsure" or find the reason for the warning and remove it. Should you decide to accept 'unsure' please tell me and I will avoid buying any of your products.
Again, the compiler does what you tell it - but, if you tell it rubbish, you will get rubbish as a result.
Hence the well-known programming term, GIGO = Garbage In; Garbage Out.
I thought that in the OK it was "RIRO rubbish in, rubbish out" :)
Erik
"Means, the compiler was unsure how to handle it."
Assuming that you're running the C51 compiler on Windows on a PC using , the compiler will be consistent with its decisions.
As far as I am aware, the random computer is not in common usage.
You obviously use English as a method of communication - Haven't you noticed that it (like all languages) is based on mutual understanding.
If someone, unilaterally, opts to change the meaning of a word, then that person is obviously going to generate misunderstanding.
Why to you want that someone to be you?
Yes, I suppose it should be - but we are beset by far too many americanisms...
:-(
It shouldn't need saying yet another time, but apparently it does: No, that pointer is not of type uint. It's of type pointer-to-uint. A uint is not a pointer any more than a car is a driver's license. Staying in that image, you got a warning because you tried to put the car in your inside pocket. I'm just translating it from our language, Herr Broeker, to english. I don't know why the guys here are such nitpickers, but in german we say: Zeiger und Zeigertyp. Ein Zeiger, der auf eine uint-Variable zeigt, ist vom Typ uint. Und eine Zeigeradresse ist die Adresse, wo der Zeiger draufzeigt, und nicht seine eigene! Wie sollte man diese Adresse denn sonst nennen???
OK, in order to get this straight, folks: How do you call the adress the pointer points to? How do you call the value the pointer points to?
Assuming that you're running the C51 compiler on Windows on a PC using , the compiler will be consistent with its decisions. I agree the compiler is 'content' but I still maintain it is 'unsure'. i think we are haggling words rather that function.
Does a warning not mean "I have done the best I can and am 'content' with that, but it is possible I applied the wrong decision"
As an example: most often a simple non-prototyped functiaon will work just fine, but there is no guarantee that all non-prototyped functions will work. Thus the compiler, while being "content with its decision" (it has done what the documentation states it will) does declare "I am unsure" i.e. issues a warning.
One of my recurring 'faults' is forgetting to prototype a function and often I will run a debugging session with the warning existing and remove the warning at the next editing session.
I don't know why the guys here are such nitpickers,
Because most of the responders earn their income by writing programs in C.
How do you call the adress the pointer points to?
Value/content of the pointer.
How do you call the value the pointer points to?
Content of the memory address referenced by the pointer.
Did you read all the other postings on this thread yet ? If not, could you do so and comment on whether they make things clearer ? Could you also answer the questions I asked about the -> operator ? I assume that much of the confusion you experience stems from a misconception on what this operator does, and to confirm that I could use the answer to those questions. Sorry if they sound a bit textbook-ish, but if things are like I think they are, then an explanation of this operator would clear them up quite a bit.
"I don't know why the guys here are such nitpickers"
If you consider this "nitpicking" to be a problem, then you going to struggle with any sort of computer programming.
Computer programming is all about accuracy & precision: computers are stupid machines, and will follow your instructions to the letter and without question. Therefore, if your instructions are anything but a completely accurate and precise representation of your requirement, you will not get what you expected!
I thought Germans should understand about accuracy and precision...
Unfortunately, this forum doesn't support pictures, so we'll have to make do with "ASCII-Art" - but here goes.
Consider the following definitions
typedef unsigned int uint; // In C51, this occupies 2 bytes (16 bits) uint my_uint; // A variable of type uint uint *my_ptr; // A pointer to type uint uint **my_ptr_ptr; // A pointer to a pointer to type uint
Assuming that pointers are also 16 bits, these could result in a memory layout looking something like this:
Address: 100 101 102 103 104 105 106 ...+------+------+------+------+------+------+... Memory: | | | | ...+------+------+------+------+------+------+... Name: my_uint my_ptr my_ptr_ptr
You can see that: The address of my_uint is 100; The address of my_ptr is 102; The address of my_ptr_ptr is 104.
Now let's assign some values:
my_uint = 986; // Assign the value 986 to the variable my_ptr = &my_uint; // Assign the address of my_uint to my_ptr my_ptr_ptr = &my_ptr // Assign the address of the pointer to my_ptr_ptr
This would result in the following values being stored in memory:
Address: 100 101 102 103 104 105 106 ...+------+------+------+------+------+------+... Memory: | 986 | 100 | 102 | ...+------+------+------+------+------+------+... Name: my_uint my_ptr my_ptr_ptr
Now you can see that: The address of my_uint is still 100, and the value of (ie, the value stored in) my_uint is 986; The address of my_ptr is still 102, and the value of (ie, the value stored in) my_ptr is 100; The address of my_ptr_ptr is still 104, and the value of (ie, the value stored in) my_ptr_ptr 102.
Thus it should now be clear that the address of a pointer has nothing to do with the value of a pointer.
"Assuming that pointers are also 16 bits..."
Note that, in general this assumption is not true for Keil C51.
In Keil C51, an unqualified pointer definition (as shown) would give a Generic Pointer - which occupies three bytes. See: http://www.keil.com/support/man/docs/c51/c51_le_genptrs.htm
Therefore, with Keil C51, the diagram should be more like:
X:100 101 102 103 104 105 106 107 108 ...+------+------+------+------+------+------+------+------+... | 986 | X:100 | X:102 | ...+------+------+------+------+------+------+------+------+... my_uint my_ptr my_ptr_ptr
I agree the compiler is 'content' but I still maintain it is 'unsure'. i think we are haggling words rather that function.
You'll have to settle for agreeing with yourself, as nobody else has mentioned the compiler's contentment or lack thereof. As for the compiler being 'unsure', let me assure you that it does not suffer from such problems.
No, not at all. A warning in this context means that the compiler has successfully translated some syntactically correct code but has recognised a particular construct as one that is commonly unintended by the programmer.
In other words, it is telling you that you, rather than it, have 'applied the wrong decision'.
As an example: most often a simple non-prototyped functiaon will work just fine, but there is no guarantee that all non-prototyped functions will work.
Why not? Do you understand the purpose of prototypes?
Thus the compiler, while being "content with its decision" (it has done what the documentation states it will) does declare "I am unsure" i.e. issues a warning.
You fail to prototype a function, the compiler issues a warning. What could it possibly be unsure about?
You'll have to settle for agreeing with yourself, as nobody else has mentioned the compiler's contentment or lack thereof In your eagerness to come down on me you state that I introduced 'content' in the discussion, I did not.
As for the rest of your ridicoulous babble, Ill just lket stand for what it is: ridicoulous babble.
Mr OP,
When I get confused with things like pointers, typecasts and functions, I always add brackets.
But ... take note of the following text from the C infrequently asked questions:
"In the old days, when Microsoft first invented C, the syntax for calling functions involved more parentheses; this was after their market research indicated that most C programmers would be coming from a Lisp environment. Later, when Kernighan took over the language design (right after AT&T bought Microsoft's language technology), he decided to eliminate the parentheses, but the old form is still allowed."
Additional brackets (parentheses) would be of no help at all in this situation, I'm afraid.
Yes. I believe the OP thinks that the "->" operator returns a pointer to the member, when it actually references the member itself ...
"Additional brackets (parentheses) would be of no help at all in this situation, I'm afraid."
Trouble is, looks like nothing helps him anyway!
Not even your nice explicit diagrammed examples!
Perhaps if a native German speaker could translate & explain his German quotation, that might throw some light...
I did, and it doesn't.
So his terminology has exactly the same flaw when expressed in German?
ie, it's a fundamental flaw, not just a problem with the translation into English?
Absolutely. Nothing was lost in translation.
View all questions in Keil forum