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.
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'.
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.
Erik
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.
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
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.
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.
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.
"I can see no wrong use of the pointers."
You're code is wrong.
The best method of removing the error is to correct the incorrect code!
No, it's not actually wrong - it's just suspect - which is why it only gets a warning, not an error.
"The best method of removing the error is to correct the incorrect code!"
There isn't an error to remove - but, as has already been explained, the suspicion could be removed by using an explicit cast!