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.
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
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" i.e. issues a warning.
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.
a lot stronger than your reading
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.
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.