@ Florian.

You closed the typecast from array of char to string issue. Maybe you are right,
I just can prove that every d2-xe7 adds a #0, so a cast (partially, agreed) works in delphi and not in fpc.
I suggest you reconsider this. The raw pointer cast should work, which means an array of char should have a hidden terminator as well as a hidden pre.

With all respect,

Thaddy

My bad, hidden post #0

@ Florian. You closed the typecast from array of char to string issue.

http://bugs.freepascal.org/view.php?id=27530

Maybe you are right, I just can prove that every d2-xe7 adds a #0, so a cast (partially, agreed) works in delphi and not in fpc.

It's unrelated to the terminating #0. It's about the hidden length and other metadata that is stored before the dynamic array and the string. This data is not compatible in either FPC or in Delphi. Delphi happens to store the length data in the same way, but other data for strings is not present with dynamic arrays (as your own test in comment 0081403 shows).

If you were to pass such typecasted arrays to arbitrary Delphi routines that expect ansistrings, you'll also get garbage results there in certain cases (because of missing code page information, so arbitrary data before the dynamic array will be interpreted as code page -- in fact, in principle this can even cause crashes, in case the memory coming before the dynamic array has not been mapped).

You'll probably also get memory corruption if you assign the result of the typecast to an ansistring, then set the dynamic array reference to nil (so the ansistring contains the last reference) and then set the ansistring to an empty string (because Delphi will then probably try to free a pointer that starts 16 or 32 bytes before the "string" data, while in case of a dynamic array it starts fewer bytes before the array data -- at least in FPC, but probably in Delphi too).

I suggest you reconsider this. The raw pointer cast should work, which means an array of char should have a hidden terminator as well as a hidden pre.

A dynamic array and an ansistring are two completely unrelated types. There is no reason why an explicit typecasts between them should work.

Jonas

No, it's about the K&R compatibility.
That's all, nothing more, nothing less.
It has always been there for an array of char (old c style, now ansichar) ) in Delphi.

No, it's about the K&R compatibility. That's all, nothing more, nothing less. It has always been there for an array of char (old c style, now ansichar) ) in Delphi.

A regular array of char can also be converted into a string in FPC. That's not a "raw pointer typecast" though, but an actual conversion whereby a new string "instance" is created based on the contents of the array.

Maybe we have to do that too for dynamic arrays. Can you print the value of the array pointer and the typecasted string pointer? If they are different, then that's something else and we indeed probably also have to insert a type conversion.

Jonas

Maybe in D7 this works and in Delphi XE7 you also can get away with it when passing it directly to Writeln but this will throw a nice AV and the end:

program Project1;
const
   Str = 'TEST';
var
   Data: array of Char;
   s: string;
begin
   SetLength(Data, Length(Str));
   Move(Str[1], Data[0], Length(Str)*SizeOf(Char));
   s := string(Data);
end.

I debugged into the code (it's calling UStrAsg) and what it does cannot be correct because it
interprets the array of Char directly as string messing around with its refcount.

Regards
Stefan

Am 25.02.2015 um 17:02 schrieb

This is also what I suspected but in this case the meta data would be available?

Yes, but just very maybe the "0" code page was from CP_ACP. Although afaik Delphi always substitutes the actual value of DefaultSystemCodePage in instantiated strings, so that's probably not the case.

Jonas

That's why I asked to print the result of StringElementSize :)