I have an odd case (bug ?)
But I am unable to reproduce on a simple example.

Debugger output, and assembler both suggests it's in the compilation. fpc from trunk a few weeks ago. using -OpPENTIUMM -O1

one procedure is declared as
     procedure SetFoldState(const AValue: String);
another one calls this as follows
     if FPendingFoldState  '' then
       SetFoldState(FPendingFoldState);

FPendingFoldState is a variable (String) of the object (both methods belong to the same object too)

Now in SetFoldstate is a line:
   FPendingFoldState:='';

and after this AValue becomes corrupt

The assembler of the calling code (from -al)
# [6541] if FPendingFoldState '' then
movl -4(%ebp),%eax
movl 1352(%eax),%eax
testl %eax,%eax
je .Lj12594
.Ll3371:
# [6542] SetFoldState(FPendingFoldState);
movl -4(%ebp),%eax
movl 1352(%eax),%edx
movl -4(%ebp),%eax
call SYNEDIT_TCUSTOMSYNEDIT_$__SETFOLDSTATE$ANSISTRING .Lj12594:

There is no ansistring inc ref (both methods are in the same file, and yes {$H+}

Trying to reproduce in a smaller example did not bring results....

Anyone any idea, if there s any code that could cause such an "optimization" ?

Martin

Ok I reproduced it. (compiled with -gh -gt -O1 => but I am not sure it matters

Question: Is it some wrong doing of me? or shall i report it as bug?

In Foo, "s" is supposed to be a copy of "x" => the string should have a ref count of 2, and the modification of x, should make a copy of the string.
afaik the output should be "a" => but it is "X"

You can also set x:='' => which will be random in output
program Project1;
{$mode objfpc}{$H+}
var
   x: String;
procedure Foo(const s: String);
begin
   x[1]:='X';  //  x:='';
   writeln(s);
end;
procedure Bar;
begin
   SetLength(x,1);
   x[1]:= 'a';
end;
{$R *.res}
begin
   Bar;
   Foo(x);
   readln;
end.

This should not compile. The string is declared const, please fill a bug report.

why it should not? 's' is declared as const but not the 'x'.

Best regards,
Paul Ishenin.

why it should not? 's' is declared as const but not the 'x'.

+1

I'm also confused as to Florian's statement.

Ops, I missed this.

Martin пишет:

Anyone any idea, if there s any code that could cause such an "optimization" ?

This is by design. 'const' modifier on ansistring and other 'managed' type arguments instucts the compiler to omit refcount changes, yielding a faster code. At the same time it prohibits direct modification to the argument, but nothing can be done if you modify another location that aliases the argument.
If you need proper refcounting, you should pass the argument by value (i.e. without 'const' modifier).

Regards,
Sergei

So, no need to report as bug then?

Btw, just an idea.

A possibility (probably quicker than inc-string-ref) would be: In the case that other (none local) strings are used (and modified) inside such a function/procedure then they are compared (just the pointer) to the const argument. If equal, then inc-ref can still be called.

Optimization (later) could spot localization of such checks => if the other string is modified only in a certain spot, (if something) then checks could be executed only if the conditional block was entered.

Martin

Indeed, Sergei is correct. In a language like Pascal, there is no way for the compiler to ensure that the constness of parameters is completely observed. It's more like a hint of the programmer to the code generator ("the values passed to this parameter will not changed, so you can optimize however you like based on that assumption") than a semantic condition for the compiler to guarantee ("make sure that I do not change values passed to this parameter in any way").

Jonas

For what it is worth: Delphi behaves the same as FPC.

Michael.

I saw the error in my thinking, after Jonas (re-) explained the meaning of "const".

and I guess it applies to other types to (as long as they are passed by reference): e.g records are likely to see changes too...

Indeed. I was initially not completely correct, and should have said: the 'const' modifier prevents creation of the local copy of the argument. The exact way of creating local copy depends on the argument type: for reference-counted types, it is done by manipulating the refcount, other types like shortstrings use a plain copy, etc.

Regards,
Sergei