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.
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" :)
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...
:-(
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 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.
Not in this case, it isn't.
Warnings really are for those cases where the compiler knows that it has interpreted the source code to the letter of the law, but is aware the users commonly misinterpret the point.
The original post is a classic example: it is perfectly legal to assign an unsigned int value to a pointer, and the result is perfectly well-defined - but there is reason to doubt that it may not actually have been the programmer's intention.
The other classic example is, of course,
if( a = b )
which is perfectly valid syntax, and will give a perfectly well-defined result - but that result may well not be what the programmer had intended...
Thus the compiler, while being "content with its decision" (it has done what the documentation states it will) does declare "I am unsure if this is what you want" i.e. issues a warning.
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?
Ah yes, the 'can't admit I'm wrong but can't defend it' moment.
Ok, you've expanded. I'll paste the expanded sentence back into the paragraph it came from:
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 if this is what you want" i.e. issues a warning.
Could you now explain this paragraph properly, as your expansion has not helped it make sense? In particular, please explain:
1) The lack of a guarantee that all non-prototyped functions will work. 2) How the lack of a prototype leaves the compiler 'unsure if this is what you want'.
Mr. smoked sardine: there is an expression "like the devil reads the bible" and it seems you scour my posts with one intention only: to find something that can be misunderstood in a way that makes it wrong.
If, instead of trying to misunderstand me, you tried to understand (if that is within your mental capacity) we would not have these exchanges.
if you have a problem with this, I give up.
the answers are so obvious that if you can not see them, then all is lost for you.
OK, a bit of bending it in neon trying to make a simpleton see what it is about.
there is no answer separate for 1) and 2) 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?. Thus, as far as the compiler "knows" there is "no guarantee that the call to the non-prototyped function will work" and "it leaves the compiler 'unsure if this is what you want'".
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. Oh I'm sorry I forget that, although you post here, you have no interest whatsoever in the Keil documentation, in your opinion, if it is not in K&R it does not exist.