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.
int a = 5; unsigned b = 5; a = b;
Could generate a warning, because some legal unsigned values won't fit in a signed int
Similarly,
int a = 5; unsigned b = 5; b = a;
Could generate a warning, because some legal signed values won't fit into an unsigned int.
In both cases, you can tell the compiler that it's not an accidental oversight by giving an explicit cast.
Exactly the same applies when assigning a non-pointer to a pointer, as has already been explained.
"In my understanding and I guess in everyone else too, this means that I was trying to convert something that's not a pointer (a normal variable, for exmple) to a pointer."
Yes correct: The pointer is ptr_xdata; The non-pointer is sPtr_obj->Adresse.
"Since ptr_xdata is declared as a pointer, it will still be a pointer after its value has changed."
Correct - but the warning is not about that: Read it again, the warning is about converting a non-pointer to pointer - that is, the thing being converted is the non-pointer
ptr_xdata = (sPtr_obj->Adresse); ^ ^ | | | | This is a pointer This is not a pointer (it's a uint)
So the above assignment is from a non-pointer (on the right-hand side) to a pointer (on the left-hand side)
And so the warning is correct:
"converting [from] non-pointer to pointer"
You don't seem to get it. I don't understand it, because it's confusing.
In this case, it is actually the reverse. It is confusing because you don't understand it.
A number of million students have thought that pointers are confusing. However, there are quite a lot of programmers in this world that do know about pointers now. And they can testify that as soon as they really did understand pointers, they no longer see them as confusing.
It's just a question of getting the correct internal picture of the pointer concept. Before you have a working mental picture, they will be confusing. With the picture in place, you will think: gosh, that was easy.
The reason so many programs fails because of pointer errors, is not because pointers are hard to grasp but because they are powerful and a more powerful tool is inherently more dangerous. People makes mistakes. When they make mistakes with pointers, bad things happens. So a developer should always be extra careful when working with pointers.
Right now, we are trying to get you to change your internal view of pointers. A number of us believe that the terminology really is crucial to this task. If you see a pointer as a variable, with the normal properties of a variable (location, value, size, ...) then we believe you have a better chance to be able to switch your mental image of pointers, and be able to figure out their full potential. And their full potential really do require you to think about the address of the pointer, i.e. where it is stored. You really do have to understand why several steps of indirection is needed, or why programs must be able to modify the value of the pointer, and not just the value it points to.
I repeat for the xth time that I absolutely KNOW
And everybody else has to keep repeating, that you don't know anywhere as much as you think.
You're contradicting yourself all the time. One moment you claim you understand pointers perfectly, the next you admit you're confused by them.
You've stated painfully obvious nonsense like this, several times by now
this value is an uint value and I put this value to another pointer, also of type uint,
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.
Everybody, including you, is allowed to be wrong once in a while. But that doesn't mean we'll seeingly tolerate your insisting on staying a confused fool forever.
"One one man stands against the world, the world is often right."
To the insane, the rest of the world is crazy and they are the ones who are sane.
"the struct [element?] was formerly initialised with an address of a variable"
I presume you're talking about sPtr_obj->Adresse - yes?
If this is supposed to hold the address of a variable, why was it not properly defined as a pointer in the first place?!
The only reason why the language allows conversion from integers to pointers is for systems programming (embedded or when you write hardware drivers), i.e. when you need to access a hardware device at a specific location or when you need to locate variables dynamically at absolute locations.
Taking the address of a variable and convert to an integer and later converting the integer back to a pointer is something a program should hardly ever need. Most required address manipulation can be performed on the pointer. If you implement a memory manager, you might like to play with / and % (or more probably with >> and &) to figure out memory page and offset within memory page.
You can lead a horse to water, but you can't make him drink.
"You can lead a horse to water, but you can't make him drink."
Similarly:
"You can lead a boy to college, but you can't make him think." - Elbert Hubbard.
"You can lead a boy to college, but you can't make him think." - Elbert Hubbard. "you can lead a boy to college, but you can not make him do his homework instead of posting "please send schematic and code" in a forum"
Erik
I presume you're talking about sPtr_obj->Adresse - yes? If this is supposed to hold the address of a variable, why was it not properly defined as a pointer in the first place?!
Because it does not really work to access a pointer address value inside a struct that is pointed to by a pointer. It should be something like
ptr_xdata = *(sPtr_obj->Adresse)
if Adresse wouldn't be an uint, but a pointer instead. We had severe problems in the past calming down the compiler when using such a way. The chance is 50:50 that it will work. Means, the compiler was unsure how to handle it.
Means, the compiler was unsure how to handle it.
That is a statement to print and put on the wall. The next time I get a compiler error, I will complain about insecure compilers. That is almost as funny as saying that the car stood still when the tree suddenly decided to run into it.
You can have any (!) level of pointer indirection (with or without any structs in the indirection chain) without any problems separating operations on the pointer value (the pointer) or on the referenced object. It all follows from the operator precedence rules.
"Because it does not really work to access a pointer address value (sic) inside a struct that is pointed to by a pointer"
Doesn't it?
If the struct element is correctly defined as a pointer, then there is no difference whether it is read via a direct access as
ptr_xdata = some_struct.some_pointer
or via a pointer as
ptr_xdata = struct_ptr->some_pointer
"We had severe problems in the past calming down the compiler when using such a way"
I very much suspect that all comes back to you not really understanding what's going on.
"chance is 50:50 that it will work"
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."
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.
Because it does not really work to access a pointer address value inside a struct that is pointed to by a pointer.
It should work just fine as long as proper attention is paid to things like operator precedence. This functionality is well-defined and definitely not compiler-specific. If it does not work, then there is either a mistake in the C code or a bug in the compiler. The former is usually much more likely than the latter.
It should be something like
No. It shouldn't be something like X - this leads to bugs. The syntax for doing that is very clear and if you would not insist on ignoring how to work with pointers in C, you would probably know how to do it.
Have you read up on pointer-specific operators, especially the "Member access from pointer" operator, "->" ?
What is this supposed to do ?
1. Copy the value of the structure member Adresse to ptr_xdata ? 2. Copy the address of the structure member Adresse to ptr_xdata ? 3. Copy the contents of the memory address pointed to by the structure member Aresse to ptr_xdata ?
We had severe problems in the past calming down the compiler when using such a way.
The compiler should have absolutely no trouble parsing a trivial operation like that, provided it is fed with the correct code.
The chance is 50:50 that it will work.
Compilers don't roll dice. Provided that you didn't switch compilers somewhere in the middle, there should be no statistics involved. The code is either correct, or it is not.
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.
I thought that in the OK it was "RIRO rubbish in, rubbish out" :)
Yes, I suppose it should be - but we are beset by far too many americanisms...
:-(
View all questions in Keil forum