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.
I would guess that most people usually treat this warning as an error, and don't spend any time trying to run the application. The probability of incorrect code generation is too high I totally agree with treating it as an error, the only caveat I have is that, occasionally, I'll realize "no problem" and run a session and THEN in the next editing that comes up, fix it. I would NEVER release anything with ANY warning.
Erik
but in german we say:
No. We don't. You do. That, of course, is precisely the root of the problem. You confused yourself enormously by using such incoherent terminology
Ein Zeiger, der auf eine uint-Variable zeigt, ist vom Typ uint.
Nein, ganz sicher nicht. Ein solcher Zeiger ist vom Typ "Zeiger auf uint", oder auch "uint-Zeiger", wenn es gerade sehr eilig ist.
Wie sollte man diese Adresse denn sonst nennen???
Den Wert des Zeigers.
Because it does not really work to access a pointer address value inside a struct that is pointed to by a pointer.
Nonsense.
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.
if you have a function fun(a,b,c,d) and you call it w/o a prototype how is the compiler to "know" that you have provided all parameters?
Well, that's encouraging. It looks as though you do have some understanding of what a prototype is for.
Thus, as far as the compiler "knows" there is "no guarantee that the call to the non-prototyped function will work"
Ok, but I notice you have misquoted yourself. This is what you said before:
no guarantee that all non-prototyped functions will work
Which means something quite different.
I suggest you read up in the Keil manual (this is NOT K&R) on 4 int functions and visualize what will happen if a 3 variable function w/o a prototype is called with 4 or more variables.
I know what will happen. I think that if *you* knew what would happen, you wouldn't have made this suggestion. Go on, try it.
Oh I'm sorry I forget that, although you post here, you have no interest whatsoever in the Keil documentation,
I find it really strange that you say that - I always recommend reading the documentation.
in your opinion, if it is not in K&R it does not exist.
The 'C' language has been standardised for 18 odd years, so I use the standard as my reference, not K+R. For implementation dependant details and extensions to the standard language I refer to the relevant documentation.
In your eagerness to come down on me you state that I introduced 'content' in the discussion, I did not.
Reality isn't your strong suit, is it?
a lot stronger than your reading
You do actually realise, don't you, that you did introduce 'content' into the discussion?
"it leaves the compiler 'unsure if this is what you want'".
I'm not sure why you persist with this statement when it has been ridiculed by at least two of the more intelligent contributors to this forum.
it seems you scour my posts with one intention only: to find something that can be misunderstood in a way that makes it wrong.
I try to understand what you write. If I can understand it, and find it to be wrong, I point it out. Generally I ignore the stuff that is completely indecipherable.
or
and the result is perfectly well-defined - but there is reason to doubt that it may not actually have been the programmer's intention.
ridicule?
Yes:
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.
Oddly enough, the quote you give was not a response to one of Eriks posts.
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
I said Thus the compiler, while being "content with its decision" (it has done what the documentation states it will) That comment of yours definitely is "as the devil reads the bible"
Indeed, which is why I'm amazed that he went on to adopt and defend it as follows:
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.".
View all questions in Keil forum