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.
Seems like we talking past each other.
In other words: I know what a pointer is, but for me the only thing of interest is what it does. That's what I was talking about. An example:
char *ptr; char a; ptr = 7;
is the same principle as
ptr = &a;
where the address of 'a' is not determined. I'm setting the pointer to point to an address, whether this is a number (an absolute address) or a variable. This is all what is done in the code above. Where is the conversion? I can't see it. Because warning C289 says "converting non-pointer to pointer" in v8.06. Actually I'm setting a pointer to an address of a variable.
1. A struct is declared. 2. The struct has a member 'Adresse', uint type. 3. This member is set to the address of a variable, let's say &test. 4. A struct pointer is set to this struct. 5. A char pointer is declared. 6. The struct pointer is set to point to the member 'Adresse'. 7. The value of 'Adresse' is read out and used to set the char pointer to point to 'test'.
Totally OK for me. Where's the problem?
Where is the conversion? I can't see it.
You cannot see it, but the compiler can. Even though C is a fairly weakly-typed language, an integer and a pointer are not the same for the compiler, and need to be treated differently in a number of situations.
Consider the following code snippet:
unsigned int some_int = 0; unsigned int *some_ptr = 0; some_int++; some_ptr++;
Can you tell what the value of some_int will be after the snippet ? (that's trivial, right ?)
Can you tell what the value of some_ptr will be at the end of the code snippet ? (If yes, please state what it will be and why. If no, please state what information you are missing.)
And that is just one example.
Since C is fairly weakly-typed, the compiler might allow a number of so-called implicit type casts. More high-level languages are usually more strongly-typed, and would require an explicit cast in many situations.
Now back to your warning - can you post the line with the explicity type cast you use that still results in a warning ?
The & in 'C' is the "address-of" operator; the result of the expression
&a
gives the "address-of" a - so its type is self-evidently "pointer to a"
So, when you write
p = &a
the compiler can clearly see that you are assigning a pointer-type expression (&a) to a pointer-type variable (p)
However, when you write
p = 7
it is not self-evident that 7 is intended to be a valid address; more particularly, when you write
p = a
there must be some doubt that you might have meant
hence the compiler gives the warning.
To avoid the warning, you can make you intention clear by using an explicit cast:
p = (char*)a
If you're still getting the warning, you must have done it wrong. If you want an explanation of what you've done wrong, you will have to show what you have done!
The problem is that it is not self-evidently correct.
The compiler has noticed the possibility that what you wrote was not what you intended - and so it gives you a Warning.
The Warning is particularly justified as this is such a common mistake - like writing "=" instead of "==" in an 'if' clause...
One more time: you can stop the warning by using an appropriate explicit type-cast.
To avoid the warning, you can make you intention clear by using an explicit cast: p = (char*)a
Now that makes sense to me.