This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Compiling differences between C51 v7.03 and v8.06

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.

Parents
  • Only if the replies are constantly saying "you naughty boy, don't you use the wrong terminology" instead of "hmm, the compiler has its own style of warning you. You need to read between the lines".
    Sorry, but you can't back that up. The majority of the text in the replies you have received tries to explain the reason for the naming. But whenever someone says why something is important, you answer with: But I don't care about that. For me xx is the only important thing. You write answers, but you never seem to spend time trying to read the posts before answering to them. Without any bandwidth allocated for input, you can't expect good quality of your output.

    But... the pointer also points to a value, not only an address.
    It does not point to both a value and an adderss. It has an address as it's value. It may point to an address - in case it is a pointer to a pointer. In your case, it is a pointer to a uint, so it does not point to an address - it points to a uint. You have specifically said that you don't care about dual indirection, so your pointers never points to an address...

    confusion has gone since I managed to figure out what the compilers considers as conversion
    Your examples shows that you have not managed to figure out what the compilers consider a conversion. If you did understand your two examples, you should be delighted that the compiler notices the problem with one of them.

    It should be obvious why one case needs a manual (explicit) typecast to make sure you don't get a warning, while the other example does not need neither implicit nor exmplicit type cast.

    &address means "address of uint" and means that there is no need for a typecast - the right-hand side already have the correct data type for assigning to your pointer, since the value of a pointer to uint is an address to uint.

    Assigning &address to a uint means that you throw away the information that the value represents a pointer. The result: Most compilers will warn about the type conversion needed, to convert from uint to "address of uint".

    In this case, the newer version of the compiler has been improved. Some compilers has the special case that they are silent only for assign of the integer value 0 (i.e. a NULL pointer, but complains about any other integer-to-pointer assigns).

Reply
  • Only if the replies are constantly saying "you naughty boy, don't you use the wrong terminology" instead of "hmm, the compiler has its own style of warning you. You need to read between the lines".
    Sorry, but you can't back that up. The majority of the text in the replies you have received tries to explain the reason for the naming. But whenever someone says why something is important, you answer with: But I don't care about that. For me xx is the only important thing. You write answers, but you never seem to spend time trying to read the posts before answering to them. Without any bandwidth allocated for input, you can't expect good quality of your output.

    But... the pointer also points to a value, not only an address.
    It does not point to both a value and an adderss. It has an address as it's value. It may point to an address - in case it is a pointer to a pointer. In your case, it is a pointer to a uint, so it does not point to an address - it points to a uint. You have specifically said that you don't care about dual indirection, so your pointers never points to an address...

    confusion has gone since I managed to figure out what the compilers considers as conversion
    Your examples shows that you have not managed to figure out what the compilers consider a conversion. If you did understand your two examples, you should be delighted that the compiler notices the problem with one of them.

    It should be obvious why one case needs a manual (explicit) typecast to make sure you don't get a warning, while the other example does not need neither implicit nor exmplicit type cast.

    &address means "address of uint" and means that there is no need for a typecast - the right-hand side already have the correct data type for assigning to your pointer, since the value of a pointer to uint is an address to uint.

    Assigning &address to a uint means that you throw away the information that the value represents a pointer. The result: Most compilers will warn about the type conversion needed, to convert from uint to "address of uint".

    In this case, the newer version of the compiler has been improved. Some compilers has the special case that they are silent only for assign of the integer value 0 (i.e. a NULL pointer, but complains about any other integer-to-pointer assigns).

Children
No data