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.
Ok, I'll go along with the suspect.
That said, I always feel safer by treating warnings as an indication that the code/project needs modifying; if only to examine the suspect line and override the compiler's message.
In other words, I treat warnings as errors.
Anyway, the OP seems to have given up debating the point ... Maybe he's (finally) understood?
And the even better method is of course to learn how pointer indirection works. Then the Address field could be changed from uint to a pointer of the proper type - and no typecast would be needed.
Maybe he's (finally) understood?
I haven't seen any "Hey, thanks guys for explaining it to me." messages yet.
He may have just left to try his luck in a different forum.
"it leaves the compiler 'unsure if this is what you want'".
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?
Just noticed an update to the C51 compiler, bringing it up to 8.20.
Hope it reports the same warnings, else the OP will start all over again!?
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"
Erik
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.".
I said Thus the compiler, while being "content with its decision" (it has done what the documentation states it will)
But of course you've snipped the crucial part of your post. Here's the rest of the sentence:
does declare "I am unsure" i.e. issues a warning.
Your 'adjustment' of quotes definitely is "as the corrupt administration attempts to rewrite history".
it IS unsure about the users intention.
Round and round and round we go!
Have you tried your unprototyped function mismatched arguments example yet?
More than 100 posts just because a broken assumption about how to use pointers...
About unsure/confused/insecure compilers. The developers of the compiler knows that some translation rules are less likely and that there may be a good idea to warn the user.
However, the compiler is most definitely without any feelings. And I'm pretty sure that the developers of the compiler are reasonably sure about what they do, and what they want their compiler to do.
It is all probabilities and experience. Compilers are normally designed (and the language it handles) by knowledgeable people. Knowledge normally implies experience. Experience tells that some constructs are seldom intended - such as the traditional if (a = b) ... - and it is then a good idea to add a warning. But the compiler is not unsure. And the compiler developers are not unsure. They are on the other hand suspecting that the end user is unsure - or just clueless...
If you read my post you will see that I suggested YOU did it. I have no interest in how wrong code works, if it is wrong (whether that is a C issue or not) it is wrong.
if all warnings are treated as errors, what is the interest in what happens if a warning exist.
If you read my post you will see that I suggested YOU did it.
Well, I did. The result is not what *you* expect.
If I simply tell you what happens you will no doubt argue that I'm wrong, so it would be better for all concerned if you would simply try it. Perhaps if you see the result in front of you we can avoid another one of your futile attempts to wriggle out of a situation where reality is at odds with your beliefs.
if all warnings are treated as errors, what is the interest in what happens if a warning exist
Er, wait a minute. *You* suggested trying to 'visualise' what would happen in this situation, not me.