I've been looking at some old code which still seems to work in fpc 3.0.0 - but is it safe? The code looks like:

{$mode delphi}
var Buf: PChar;
       s: string;
begin
   Buf := LoadString; {returns a pointer to an arbitrarily long null
terminated string}
   s := string(Buf); {seems to work - but should it?}
end;

The above has been around since Delphi days and has never caused trouble, but I am certainly wondering if this coercion is safe anymore given the introduction of AnsiString code pages.

Any ideas?

Tony Whyman wrote on Wed, 18 May 2016:

Why shouldn't it?

The above has been around since Delphi days and has never caused trouble, but I am certainly wondering if this coercion is safe anymore given the introduction of AnsiString code pages.

Why would that make any difference?

In particular, see
http://wiki.freepascal.org/FPC_Unicode_support#PAnsiChar.2FAnsiChar and the definition of "plain ansistring" in
http://wiki.freepascal.org/FPC_Unicode_support#Declared_code_page

To repeat what I said in about every message in the previous disinformation thread on this topic: everything will work exactly the same in FPC 2.6.4 and FPC 3.0 if you use the same types (with the same effective modes/modeswitch) in both FPC versions, except for utf8string (which is an alias for ansistring in FPC 2.6.4, and an ansistring(CP_UTF8) in FPC 3.0).

Jonas

Jonas Maebe wrote

> s := string(Buf); {seems to work - but should it?} > end; Why shouldn't it?

Because I couldn't find any documentation saying this should work and I wasn't sure if this worked by luck or design.

Yes. I know you've said that, but the problem with such a statement is that it only applies to what is supposed to work and undocumented features that worked in the past may no longer be valid once the implementation has been updated.

While the online documentation says a lot about tyepcasting PChars to AnsiStrings, there seems to be nothing on the reverse.

Tony Whyman

Tony Whyman wrote

While the online documentation says a lot about tyepcasting PChars to AnsiStrings, there seems to be nothing on the reverse.

You obviously meant the opposite. In any case, ansistring(pchar) results in the same code as ansistring:=pchar, and results in a type conversion that creates a new ansistring from scratch based on the pchar data.

Re-interpreting a pchar pointer as an ansistring would probably crash in any FPC version, but that will not happen here because pchar and ansistring are assignment compatible. I.o.w., the typecast is superfluous. Everything that works without a typecast is supported by definition (barring bugs).

The documentation indeed appears to contain no information about which string types and related types are assignment compatible (and, a fortiori, can also be typecasted into each other). Char, shortstring, (non-dynamic) array of char etc can all also be assigned to ansistrings.

Jonas