Casting Delphi 2009/2010 string literals to PAnsiChar

Question

So the question is whether or not string literals (or const strings) in Delphi 2009/2010 can be directly cast as PAnsiChar's or do they need an additional cast to AnsiString first for this to work?

The background is that I am calling functions in a legacy DLL with a C interface that has some functions that require C-style char pointers. In the past (before Delphi 2009) code like the following worked like a charm (where the param to the C DLL function is a LPCSTR):

either:

LegacyFunction(PChar('Fred'));

or

const
  FRED = 'Fred';
...
LegacyFunction(PChar(FRED));

So in changing to Delphi 2009 (and now in 2010), I changed the call to this:

LegacyFunction(PAnsiChar('Fred'));

or

const
  FRED = 'Fred';
...
LegacyFunction(PAnsiChar(FRED));

This seems to work and I get the correct results from the function call. However there is some definite instability in the app that seems to be occurring mostly the second or third time through the code that calls the legacy functions (that was not present before the move to the 2009 version of the IDE). In investigating this, I realized that the native string literal (and const string) in Delphi 2009/2010 is a Unicode string so my cast was possibly in error. Examples here and elsewhere seem to indicate this call should look more like this:

LegacyFunction(PAnsiChar(AnsiString('Fred')))

What confuses me is that with the code above in the second examples, casting the string literal directly to a PAnsiChar does not generate any compiler warnings. If instead of a string literal, I was casting a string var, I would get a suspicious cast warning (and the string would be mangled). This (and the fact that the string is usable in the DLL) leads me to believe the compiler is doing some magic to correctly interpret the string literal as the intended string type. Is this what is happening or is the double cast (first to AnsiString, then to PAnsiChar) really necessary and the lack of it in my code the reason for the hard to track down instability? And does the same answer hold true for const strings as well?

Answer 1

Constants, including string literals, are untyped by default, and the compiler will fit them into whatever format works in the context you're using them in. As long as there are no non-ANSI characters in your string literal, the compiler won't have any trouble generating the string as ANSI instead of Unicode in this situation.

Answer 2

For type-inferred constants (only initializable from literals) the compiler changes the actual text at compile-time, rather than at runtime. That means it knows whether or not the conversion loses data, so it doesn't need to warn you if it doesn't.

Answer 3

As Mason Wheeler points out all is fine as long as you don't have non-ANSI characters in your string const. If you have things like:

const FRED = 'Frédérick';

I'm pretty sure Delphi 2009/2010 will either issue charset hints (and apply a string conversion automatically - thus the hint) or fail at comparing ('Frédérick' is different in ISO-8859-1 than UTF-16).

If you can have "special" characters in your consts you will need to call string conversion.

Here are some basic examples with TStringList:

TStringList.SaveToFile(DestFilename, TEncoding.GetEncoding(28591)); //ISO-8859-1 (Latin1)
TStringList.SaveToFile(DestFilename, TEncoding.UTF8);

Answer 4

To 'visualize' Barry Kelly and Mason Wheeler words:

const
  FRED = 'Fred';

var
  p: PAnsiChar;
  w: PWideChar;
begin
  w := PWideChar(Fred);
  p := PAnsiChar(Fred);

In ASM:
Unit7.pas.32: w := PWideChar(Fred);
00462146 BFA4214600       mov edi,$004621a4     
// no conversion, just a pointer to constant/"-1 RefCounted" UnicodeString

Unit7.pas.33: p := PAnsiChar(Fred);
0046214B BEB0214600       mov esi,$004621b0
// no conversion, just a pointer to constant/"-1 RefCounted" AnsiString

As you can see in both cases PWideChar/PChar(FRED) and PAnsiChar(FRED), there is no conversion and Delphi compiler make 2 constant strings, one AnsiString and one UnicodeString.