Identifier "ip" has been already declared in Trigo

[yo2lio]

146:5 E-14 Identifier "ip" has been already declared in Trigon.ppas string_util.ppas

If user have variables with this name "Ip" must change this in ALL PROGRAMS ........

It's possible to change this name "Ip" in Trigon.ppas ?

[srdjan]

146:5 E-14 Identifier "ip" has been already declared in Trigon.ppas string_util.ppas

If user have variables with this name "Ip" must change this in ALL PROGRAMS ........

It's possible to change this name "Ip" in Trigon.ppas ?

Sorry, I could not reproduce. Please send me a piece of code in a project like form that can be compiled and which demonstrates the issue you are talking about to srdjan@mikroe.com with the reference to this post.

[yo2lio]

Sent ....

[srdjan]

Hi,

Sent ....

the ip is a global variable in Eth_RTL8019AS_lib library. This library is all written in C and .mcl file is included in pascal. That is why the compiler got confused and reported error in trigon library.
You have two solutions. Rename your variable or erase Eth_RTL8019AS_lib from your mcu def file.
The previous version of the compiler did not report this error because Eth_RTL8019AS_lib was not listed in mcu def files.

[yo2lio]

Bad news ...

I don't know where I use this "Ip" variable in my programs posted on FORUM !

It's not about me, I can handle this, it's about users which use my library.

So, that's it ! Sorry !

[srdjan]

Hi,

Bad news ...

I don't know where I use this "Ip" variable in my programs posted on FORUM !

It's not about me, I can handle this, it's about users which use my library.

So, that's it ! Sorry !

You can advise them to comment the Eth_RTL8019AS_lib in def file.
If you have any other solution for this, please, do post your idea.

[jpc]

i think the real issue here is scope and visibility , until now there are only 2 domains , local to unit or completely global. A more elegant way would be limiting the scope to those units actually using the one in which the declarations are made public. I am aware this is not simple , in that light regret that the compiler-generated labels no longer take the unit-name in account , now what is an issue here for variables equally counts for all identifiers. It can happen any moment that some global identifier is introduced by mE that happens to be identical to one we already use for long time , the only way out for us users is to trace the identifier ( if we can !) and change it to something less evident than IP for example but without any guarantee this will not happen again.

[srdjan]

Hi,

i think the real issue here is scope and visibility , until now there are only 2 domains , local to unit or completely global. A more elegant way would be limiting the scope to those units actually using the one in which the declarations are made public. I am aware this is not simple , in that light regret that the compiler-generated labels no longer take the unit-name in account , now what is an issue here for variables equally counts for all identifiers. It can happen any moment that some global identifier is introduced by mE that happens to be identical to one we already use for long time , the only way out for us users is to trace the identifier ( if we can !) and change it to something less evident than IP for example but without any guarantee this will not happen again.

- If you declare a variable under implementation tag, it will have a unit scope. Currently, this does not count for the procedures and functions, but it will be implemented in the future.
- The actual problem here is that above mentioned ethernet library was unfortunately written with the global variable named ip.
I have modified the realtec ethernet library. You'll be able to use IP identifier in you code.

[jpc]

if i declare u variable in the definition section however , it will be visible for ALL , enter a global identifier-pool like indeed now all function-identifiers. My suggestion would be to limit this to those units explicitly using them. Imigine units A,B,C and main : main uses A , A uses B and B uses C In this situation i would like main ONLY to see the public declarations from A and not all as is the case now. If in main i would like to have access to something declared in unit B or C then i would import them there in the uses-clause .
In order to do this the internal identifiers would have to include the unit-name from which they originate. Right now i usually do this at source-level. As an example , a very common name is init , each unit that deals with some peripheral is likely to have one. In the provided mE- library's we can find several already like SPI_Init, Usart_init, PWM_init etc. The only solution for now is to do similar in our naming-convention for all global identifiers including variables and constants, it would be very nice if the compiler would deal with that however.

[srdjan]

if i declare u variable in the definition section however , it will be visible for ALL , enter a global identifier-pool like indeed now all function-identifiers. My suggestion would be to limit this to those units explicitly using them. Imigine units A,B,C and main : main uses A , A uses B and B uses C In this situation i would like main ONLY to see the public declarations from A and not all as is the case now. If in main i would like to have access to something declared in unit B or C then i would import them there in the uses-clause .
In order to do this the internal identifiers would have to include the unit-name from which they originate. Right now i usually do this at source-level. As an example , a very common name is init , each unit that deals with some peripheral is likely to have one. In the provided mE- library's we can find several already like SPI_Init, Usart_init, PWM_init etc. The only solution for now is to do similar in our naming-convention for all global identifiers including variables and constants, it would be very nice if the compiler would deal with that however.

- Don't forget our built in libraries that are loaded along with the mcu change. That would be too complicated for realization. However, we are planing some enhancement, but we'll talk about them when the time comes.