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.
Unfortunately, this forum doesn't support pictures, so we'll have to make do with "ASCII-Art" - but here goes.
Consider the following definitions
typedef unsigned int uint; // In C51, this occupies 2 bytes (16 bits) uint my_uint; // A variable of type uint uint *my_ptr; // A pointer to type uint uint **my_ptr_ptr; // A pointer to a pointer to type uint
Assuming that pointers are also 16 bits, these could result in a memory layout looking something like this:
Address: 100 101 102 103 104 105 106 ...+------+------+------+------+------+------+... Memory: | | | | ...+------+------+------+------+------+------+... Name: my_uint my_ptr my_ptr_ptr
You can see that: The address of my_uint is 100; The address of my_ptr is 102; The address of my_ptr_ptr is 104.
Now let's assign some values:
my_uint = 986; // Assign the value 986 to the variable my_ptr = &my_uint; // Assign the address of my_uint to my_ptr my_ptr_ptr = &my_ptr // Assign the address of the pointer to my_ptr_ptr
This would result in the following values being stored in memory:
Address: 100 101 102 103 104 105 106 ...+------+------+------+------+------+------+... Memory: | 986 | 100 | 102 | ...+------+------+------+------+------+------+... Name: my_uint my_ptr my_ptr_ptr
Now you can see that: The address of my_uint is still 100, and the value of (ie, the value stored in) my_uint is 986; The address of my_ptr is still 102, and the value of (ie, the value stored in) my_ptr is 100; The address of my_ptr_ptr is still 104, and the value of (ie, the value stored in) my_ptr_ptr 102.
Thus it should now be clear that the address of a pointer has nothing to do with the value of a pointer.
"Assuming that pointers are also 16 bits..."
Note that, in general this assumption is not true for Keil C51.
In Keil C51, an unqualified pointer definition (as shown) would give a Generic Pointer - which occupies three bytes. See: http://www.keil.com/support/man/docs/c51/c51_le_genptrs.htm
Therefore, with Keil C51, the diagram should be more like:
X:100 101 102 103 104 105 106 107 108 ...+------+------+------+------+------+------+------+------+... | 986 | X:100 | X:102 | ...+------+------+------+------+------+------+------+------+... my_uint my_ptr my_ptr_ptr
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.
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"
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.
Erik
Mr OP,
When I get confused with things like pointers, typecasts and functions, I always add brackets.
But ... take note of the following text from the C infrequently asked questions:
"In the old days, when Microsoft first invented C, the syntax for calling functions involved more parentheses; this was after their market research indicated that most C programmers would be coming from a Lisp environment. Later, when Kernighan took over the language design (right after AT&T bought Microsoft's language technology), he decided to eliminate the parentheses, but the old form is still allowed."
Additional brackets (parentheses) would be of no help at all in this situation, I'm afraid.
Yes. I believe the OP thinks that the "->" operator returns a pointer to the member, when it actually references the member itself ...
"Additional brackets (parentheses) would be of no help at all in this situation, I'm afraid."
Trouble is, looks like nothing helps him anyway!
Not even your nice explicit diagrammed examples!
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...
Perhaps if a native German speaker could translate & explain his German quotation, that might throw some light...
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.
Not sure why you talk about K&R. Most people only care about ISO/ANSI, with the exception of any non-standard extensions needed for the specific platform.
Not just the number of parameters that are important.
A function may expect to receive a long, float or double parameter but get an int. The compiler doesn't know if it is expected to convert the data type when sending the parameters.
The compiler doesn't know if the function returns any value or not, and in such case if the return value is of a different type than int.
Quite a number of compilers have also support for different calling conventions, for example: - Normal C, where the caller cleans the stack (supports a variable number of parameters) - Pascal, where the function cleans it's parameters before returning (generates smaller code). - Fast call, where the parameters are sent in registers instead of on the stack (generates faster code). - ...
In the end, there are very big incentives to supply a function prototype to the compiler, since the alternative can be a very bad crash when running the program. 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 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.
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.
"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.
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.".
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?
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.
If I simply tell you what happens you will no doubt argue that I'm wrong I do not think I have ever stated you wrong except in your deliberate misinterpretations of my statements.
When you I am sure, by mistake, have included anything helpful ".. x does y this way" I have never stated you wrong.
I comr to think of the proverb "thief think everyone steals" when you anticipate me arguing that you are wrong
View all questions in Keil forum