[fpc-devel] One more issue with string function results (hopefully, the last)

2008-01-22 Thread Sergei Gorelkin
Hello, Ran into it while compiling Lazarus. It appears that, while many sophisticated checks are done in tcallnode.maybe_create_funcret_node, the obvious case when function result destination is one of the function's arguments, is not checked. To be honest, I noticed that earlier for the case

Re: [fpc-devel] One more issue with string function results (hopefully, the last)

2008-01-22 Thread Peter Vreman
> Hello, > > Ran into it while compiling Lazarus. It appears that, while many > sophisticated checks are done in tcallnode.maybe_create_funcret_node, > the obvious case when function result destination is one of the > function's arguments, is not checked. To be honest, I noticed that > earlier for

Re: [fpc-devel] One more issue with string function results (hopefully, the last)

2008-01-22 Thread Peter Vreman
>> Hello, >> >> Ran into it while compiling Lazarus. It appears that, while many >> sophisticated checks are done in tcallnode.maybe_create_funcret_node, >> the obvious case when function result destination is one of the >> function's arguments, is not checked. To be honest, I noticed that >> earli

Re: [fpc-devel] One more issue with string function results (hopefully, the last)

2008-01-22 Thread Sergei Gorelkin
Peter Vreman wrote: The example that is provided doesn't fail. Because when calling foo the value of -4(%ebp) is loaded in %eax and that value is used in the function foo. The setlength() will create a new string and store that at -4(%ebp) of the calling function. But doesn't change the origi

Re: [fpc-devel] One more issue with string function results (hopefully, the last)

2008-01-23 Thread Jonas Maebe
On 22 Jan 2008, at 20:28, Peter Vreman wrote: This issue is caused by your own patch to change the ansistring code to use pass the result by reference. Original code (using current 2.2.1) was: # [21] s := foo(s); // This one failes movl-4(%ebp),%eax callP