V3.20: 2 literal strings as parameters give problems.

[Dany]

Hi,

I have a function with the following signature:

Code: Select all

function mmc_Fat32_Rename(var OldName: TLongFileName; var NewName: TLongFileName): boolean;

for which holds:

Code: Select all

const LongFnLength  = 255; // size of a long filename
type TLongFileName  = string[LongFnLength];

What I see is, that when I call the function as follows

Code: Select all

success :=  mmc_Fat32_Rename('abc.txt', 'xyz.txt');

both parameters "OldName" and "NewName" have the same value inside the function (in this case 'xyz.txt').

As far as I can see in the listing below, both texts are placed in the same global ram memory location (_main_Local_Text), of which the address is passed as value to both parameters (var parameters). Of course both parameters point to the same memory location, showing the same (last passed) string...

Code: Select all

;TestLFNBib.mpas,367 :: 		success :=  mmc_Fat32_Rename('abc.txt', 'xyz.txt');
0x55C4	0x0E1F      	MOVLW       _main_Local_Text
0x55C6	0x6EE1      	MOVWF       FSR1L 
0x55C8	0x0E04      	MOVLW       hi_addr(_main_Local_Text)
0x55CA	0x6EE2      	MOVWF       FSR1H 
0x55CC	0x0E61      	MOVLW       97
0x55CE	0x6EE6      	MOVWF       POSTINC1 
0x55D0	0x0E62      	MOVLW       98
0x55D2	0x6EE6      	MOVWF       POSTINC1 
0x55D4	0x0E63      	MOVLW       99
0x55D6	0x6EE6      	MOVWF       POSTINC1 
0x55D8	0x0E2E      	MOVLW       46
0x55DA	0x6EE6      	MOVWF       POSTINC1 
0x55DC	0x0E74      	MOVLW       116
0x55DE	0x6EE6      	MOVWF       POSTINC1 
0x55E0	0x0E78      	MOVLW       120
0x55E2	0x6EE6      	MOVWF       POSTINC1 
0x55E4	0x0E74      	MOVLW       116
0x55E6	0x6EE6      	MOVWF       POSTINC1 
0x55E8	0x6AE6      	CLRF        POSTINC1 
0x55EA	0x0E1F      	MOVLW       _main_Local_Text
0x55EC	0x0104      	MOVLB       4
0x55EE	0x6F36      	MOVWF       FARG_mmc_Fat32_Rename_OldName, 1
0x55F0	0x0E04      	MOVLW       hi_addr(_main_Local_Text)
0x55F2	0x6F37      	MOVWF       FARG_mmc_Fat32_Rename_OldName+1, 1
0x55F4	0x0E1F      	MOVLW       _main_Local_Text
0x55F6	0x6EE1      	MOVWF       FSR1L 
0x55F8	0x0E04      	MOVLW       hi_addr(_main_Local_Text)
0x55FA	0x6EE2      	MOVWF       FSR1H 
0x55FC	0x0E78      	MOVLW       120
0x55FE	0x6EE6      	MOVWF       POSTINC1 
0x5600	0x0E79      	MOVLW       121
0x5602	0x6EE6      	MOVWF       POSTINC1 
0x5604	0x0E7A      	MOVLW       122
0x5606	0x6EE6      	MOVWF       POSTINC1 
0x5608	0x0E2E      	MOVLW       46
0x560A	0x6EE6      	MOVWF       POSTINC1 
0x560C	0x0E74      	MOVLW       116
0x560E	0x6EE6      	MOVWF       POSTINC1 
0x5610	0x0E78      	MOVLW       120
0x5612	0x6EE6      	MOVWF       POSTINC1 
0x5614	0x0E74      	MOVLW       116
0x5616	0x6EE6      	MOVWF       POSTINC1 
0x5618	0x6AE6      	CLRF        POSTINC1 
0x561A	0x0E1F      	MOVLW       _main_Local_Text
0x561C	0x6F38      	MOVWF       FARG_mmc_Fat32_Rename_NewName, 1
0x561E	0x0E04      	MOVLW       hi_addr(_main_Local_Text)
0x5620	0x6F39      	MOVWF       FARG_mmc_Fat32_Rename_NewName+1, 1
0x5622	0xF024EC3E  	CALL        _mmc_Fat32_Rename, 0

[anikolic]

Hi,
Dany the mmc_Fat32_Rename function you have sent me recently in attachment of the support ticket has different code, and prototype:

Code: Select all

function mmc_Fat32_Rename(var NewFileName: TLongFileName): boolean;

and therefore I cannot recreate your error condition and present it to our developers. It would be very convenient if you could paste the entire function here, or again open the support ticket and provide me with the original code of this function. Only then I can give you full explanation to this issue and the solution to the problem.

Thank you!

Best regards,
Aleksandar

[janni]

It's exactly the same issue as reported here http://www.mikroe.com/forum/viewtopic.php?t=22044. Only one string literal may be passed as parameter for the moment.

[anikolic]

Hi,
Yes, exactly! Janni is right, it is a known issue, already reported as the compiler bug. Please use the workaround suggested at the topic janni have posted.

Janni, thank you very much for your valuable support!

Best regards,
Aleksandar

[Dany]

Hi,
Dany the mmc_Fat32_Rename function you have sent me recently in attachment of the support ticket has different code, and prototype:

Code: Select all

function mmc_Fat32_Rename(var NewFileName: TLongFileName): boolean;

and therefore I cannot recreate your error condition and present it to our developers. It would be very convenient if you could paste the entire function here, or again open the support ticket and provide me with the original code of this function. Only then I can give you full explanation to this issue and the solution to the problem.

Done. I provided an adapted zip file in the support ticket. Sorry again. Something went apparently wrong in the "refreshing" of the zipfile.

[Dany]

Hi,
Yes, exactly! Janni is right, it is a known issue, already reported as the compiler bug. Please use the workaround suggested at the topic janni have posted.

Janni, thank you very much for your valuable support!

Best regards,
Aleksandar

Thanks!

[Dany]

Hi People of mE,

Could you please provide a list of "Open Compiler Bugs" and their workaround and status (e.g. fixing date and version)? I would take much less time than to re-discover a bug over and over again (see above). It costed me several hours, and it was already discovered.

For the moment I maintain a list for myself (and I am sure other people do this too), but this is not a goog way of working, you should publish it.

In the current "MikroPascal for PIC buglist" only a very small number of fixed bugs are there, and this published list is rather useless, it is very much more usefull to know the current bugs.

So, Please! Please! Please! Please! Please! Please!

[anikolic]

Dany,
You are right! I'm personally taking care of this, and from now on I will take the responsibility for updating this list as much as we can.

Sorry for the inconvenience and thank you for being patient and supportive!

Best regards,
Aleksandar

[Dany]

Thanks Aleksandar!

[Donald Shimoda]

Dany,
You are right! I'm personally taking care of this, and from now on I will take the responsibility for updating this list as much as we can.

Sorry for the inconvenience and thank you for being patient and supportive!

Best regards,
Aleksandar

But, are the bugs list published after all?

[anikolic]

Hi,
As soon as the time allows us, I will analyze the known unresolved and resolved bugs with our developers, and we will slowly begin updating the list. We cannot focus just on this right now, because lot of other very important issues wait to be handled, and our developers are overwhelmed with other priorities. But I can promise you that the things will move from this static point.

Best regards,
Aleksandar

[Donald Shimoda]

Hi,
As soon as the time allows us, I will analyze the known unresolved and resolved bugs with our developers, and we will slowly begin updating the list. We cannot focus just on this right now, because lot of other very important issues wait to be handled, and our developers are overwhelmed with other priorities. But I can promise you that the things will move from this static point.

Best regards,
Aleksandar

Just use mantis and expose the bugs. Is the expected behaviour in that time. You dont will need to do any adittional taks, and developers can add bugs directly into your bugs db. We do will all our product, bring us more good relationship with customers than troubles...

hope that help.

[janni]

Hi Aleksandar,

We do appreciate your determination, but the truth is, we don't need the bug list in the form it's now. I fully understand that the developers, instead of preparing a formal bug description, prefer to eliminate it , but delay in bug description destroys it's purpose.

What we need is a place where all the problems existing at the moment are simply listed, like

- Only one string literal may be passed as parameter for the moment, see http://www.mikroe.com/forum/viewtopic.php?t=22044.

- Assignments to variable other than real and containing operations on variables of type real, like byte_var:=x*x give wrong results (operands are literally 'cut to size' instead of typcast).

- Asm blocks cannot be added to code with Include directive.

- Code Explorer stops on declarations of a pointer to structure (like, var ptrs: ^array[3] of byte;) and if arithmetics is used in variable declaration at absolute address (like, var bb: byte; absolute $80+9;).

- Once the debugger is started, Ins key may stop functioning as a switch between overwrite/insert modes in Editor.

- Selecting variable from the list in Watch window may sometimes cause Application Error.

It'll be enough to have one post named "mP PRO v n.nn issues" with updated list of known problems. Otherwise, not only the users, but you as well will waste time identifying the same problem again and again.

[Donald Shimoda]

It'll be enough to have one post named "mP PRO v n.nn issues" with updated list of known problems. Otherwise, not only the users, but you as well will waste time identifying the same problem again and again.

Again, i STRONGLY recommend you use a open database for bugs. Which are the risk? You already exposed beta to all the public, amazing move, very plausible! No get one step more , will help you developers to get a orden in bugs precedence and will help us mikroe users to know why we hit the wall, if theres somebody fixing that...

just my 0.2 cents.

TIA