I dont claim to understand all that is said. Infact, learned a thing or two from all this.

Lovely stuff.

How come you complain that “PChar(somestring) + 1″ silently breaks if “somestring” is not really a string but an offset,

It’s a pointer. The 1 is the offset. It seems, from your statement (”is not really a string”), that your experiences with pointers are very limited.

but at the same time you suggest using “someapifunction(@bla[1])” which breaks silently, too?

Yes I do. Oh wait, so you blame me for the fact that CodeGear’s “compiler magic” breaks the the well-famed strict type checking? Hehe, that’s funny. … yeah, shoot the messenger. Still a popular theme.

Are you sure that it is impossible to find an example that would silently break if PChar was changed to PAnsiChar?

Yes. 100% sure for Win32 development (i.e. ignoring Kylix, which I haven’t ever tried). Because there was simply only one meaning for PAnsiChar and PChar and both were equal.

How come you think it would be better to break thousands of lines of code just in order to avoid breaking a corner case problem?

Declaring pointer arithmetics a corner case is a ridiculous statement at best. Apart from that, how big are the projects you’re working on? I had to smirk, when I read over your sentence the first time … now I am left to frown.

Apart from that there is an easy workaround: Do a global search and replace from PChar to PAnsiChar.

Sure … which will break exactly because of the change in Tiburon.

Are you sure that it is impossible to find an example that would silently break if PChar was changed to PAnsiChar?

How come you think it would be better to break thousands of lines of code just in order to avoid breaking a corner case problem? Apart from that there is an easy workaround: Do a global search and replace from PChar to PAnsiChar.

What conclusion do you think am I going to draw from this?

Oh, is this becoming a quiz now? … my guess is, that you aren’t satisfied with the type checking in the “Delphi language” after your test and that you will migrate to a language that provides stricter type checking. Am I right?

The error is the third call to GetProcAddress, because GetProcAddress doesn’t take a wide character string for the function name. The second call gives a warning (and rightly so, because it has the same result as the first call). The first call doesn’t give a warning. Read further to find out why.

So thanks for making my point about the strictness of type checking in Delphi versus C++!

To show you how I look at things most of the time, a little trip into a binary (console) which contains the first two calls as given by you:

mov     eax, ds:S
call    WStrToPWChar    ; System::WStrToPWChar(System::WideString)
push    eax
push    ebx             ; Pass module handle
call    GetProcAddress
mov     eax, ds:S       ; Direct "conversion" to Pointer
push    eax
push    ebx             ; Pass module handle
call    GetProcAddress

1. Delphi hid the fact that the first and the second call are exactly the same from us, because “compiler magic” (of which string handling is a good part) isn’t part of the actual language and therefore the necessary type check doesn’t take place. If you think the typed address compiler switch ({$T+}) would change a thing, think again.
2. The Delphi type checking is inferior to the one of C++. Unless, of course, you are an especially “smart” C-programmer writing all casts in C++ as C-casts. Been there, fixed their code.

My guess is, what you were trying to say is, that @S[1] is worse than PCharType(S). So I take it you’re considering @S[1], which is perfectly valid code, as wrong or so and there should be a different treatment involving intransparent compiler magic? Or maybe your point was to show that you can make the compiler shut up despite formally wrong code (passing wide character string to ANSI-only function)? Please, unless you own your copy of the professional versions of IDA, download IDA Standard Free 4.9 and look a bit under the hood for yourself.

Let me give you an example in return which doesn’t involve pointer arithmetics. Before Tiburon (System.pas), Delphi 2006, to be exact:

  PVarRec = ^TVarRec;
  TVarRec = record { ... }
    case Byte of
      vtInteger:    (VInteger: Integer; VType: Byte);
      vtBoolean:    (VBoolean: Boolean);
      vtChar:       (VChar: Char);
      vtExtended:   (VExtended: PExtended);
      vtString:     (VString: PShortString);
      vtPointer:    (VPointer: Pointer);
      vtPChar:      (VPChar: <span style="color:red";>PChar</span>);
      vtObject:     (VObject: TObject);
      vtClass:      (VClass: TClass);
      vtWideChar:   (VWideChar: WideChar);
      vtPWideChar:  (VPWideChar: PWideChar);
      vtAnsiString: (VAnsiString: Pointer);
      vtCurrency:   (VCurrency: PCurrency);
      vtVariant:    (VVariant: PVariant);
      vtInterface:  (VInterface: Pointer);
      vtWideString: (VWideString: Pointer);
      vtInt64:      (VInt64: PInt64);
  end;

But the really interesting part will be structures with dynamic offsets where, the implementer chose PChar to do his pointer arithmetics, because before Tiburon, only some types allowed the implicit pointer arithmetic (without Inc and Dec), as pointed out in Allen’s post. Try PByte, for example, which would be the logical substitute – doesn’t even work in Delphi 2006, although I was of the impression they had fixed that before. Apparently not.

I am not complaining about the parts where the compiler complains – they can and will be fixed, because they are visible through the compiler warnings. Of course you can always make the compiler shut up, but if you do so deliberately, bear the consequences! What I am complaining about is the fact that CodeGear wasn’t clear about the fact that PChar is (and always was) meant as a “conditional type” and that CodeGear/Borland themselves were using PChar in contexts were it was clearly ANSI-only. This, in combination with advanced use of Delphi is an explosive mix.

Here’s an example:

program UTest;

{$APPTYPE CONSOLE}

uses
  SysUtils,
  Windows;

{$DEFINE MIMICTIBURON}

{$IFDEF MIMICTIBURON}
type XString = System.WideString;
type XPChar = System.PWideChar;
{$ELSE}
type XString = System.AnsiString;
type XPChar = System.PAnsiChar;
{$ENDIF}

type
  PMyRecord = ^TMyRecord;
  TMyRecord = record
    SomethingElse : LongWord;
    OffsetToString : LongWord;
  end;

const
  hex_offsets : array[0..$F] of Byte =
    (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 8, 8, 8, 8, 8, 8);

var
  x : array[0..$1000-1] of Byte;
  ppmr : PMyRecord;
  pac : XPChar;
  i : Integer;
begin
{$IFDEF MIMICTIBURON}
  Writeln('Mimicry of Tiburon with old code');
{$ELSE}
  Writeln('Old code on old Delphi');
{$ENDIF}
  ppmr := PMyRecord(@x);
  // Fill buffer ...
  for i := Low(x) to High(x)-1 do
  begin
    x[i] := Ord('0') + (i mod 16) + hex_offsets[(i mod 16)];
  end;
  // Zero terminate the "string"
  x[477] := 0;
  // Prepare offset
  ppmr^.OffsetToString := 411;
  Writeln('Record address   : ', Format('%p', [ppmr]));
  Writeln('Offset to string : ', ppmr^.OffsetToString);
  pac := XPChar(ppmr) + ppmr^.OffsetToString;
  Writeln('Address of string: ', Format('%p', [Pointer(pac)]));
end.

And here’s the output with and without MIMICTIBURON defined:

Old code on old Delphi
Record address   : 0040E220
Offset to string : 411
Address of string: 0040E3BB

Mimicry of Tiburon with old code
Record address   : 0040E220
Offset to string : 411
Address of string: 0040E556

Please note, that neither one of the two builds gave a warning!

Fun-fact at the end. Had CodeGear introduced the subscript operator and implicit pointer arithmetic before Tiburon, things wouldn’t be as bad either, because people would not have resorted to PChar for offset calculations, but rather to PWhateverType. Now they introduce both, break the logic, but don’t break the code. This means they break it half-heartedly.

If you have the following code, which call to GetProcAddress will show a compiler warning, which call will show a compiler error?

// Delphi 2006
var
  S: WideString;
begin
  GetProcAddress(FHandle, @S[1]);
  GetProcAddress(FHandle, PAnsiChar(S));
  GetProcAddress(FHandle, PWideChar(S));
end;

What conclusion do you think am I going to draw from this?

var bla: String;
begin
  // do stuff ...
  someapifunction(@bla[1]);
  // do more stuff ...
end;

GetProcAddress(FHandle, PChar(name));

Now, GetProcAddress is a function that has no Unicode equivalent because the exported function names are always ANSI, actually ASCII (i.e. characters up to ordinal value 127), if I recall correctly.

You existing API calls work.

Nope, it won’t. You just proved my point, by giving a practical example as it is used out there

GetProcAddress(FHandle, PChar(name));

Now name is string and ultimately AnsiString. When using Unicode name is also string but WideString. I guess when using Unicode the W version WIN32 API is used so it requires PWideChar instead of PAnsiChar.

There is no conversion from WideString to PAnsiChar but compiler must generate error. This is solved then PChar is PWideChar. You existing API calls work.

Why is it a windows convention? Because it is written in C. Is it really a windows convention then or just a bit of language detail bleeding out the edges of the win api?

Maybe you want to read my post and my replies to the comments again?! There is neither a C nor a C++ (standard) type of the name PCHAR it’s a type declared in the Windows SDK. The Windows SDK, formerly Platform SDK (PSDK) is the reference for the Windows platform, whether you like it or not. And whether you like it or not, it was the template for the Delphi units declaring the Win32 functions. I understand that if you never used anything beyond Delphi, the whole thing becomes a mashup, because you get the “contents of the SDK” (at the time of product release) in the Delphi installation directory. It doesn’t change the fact, that the SDK is the reference, though and that Delphi as a Windows development tool should stick to its conventions as far as possible.

Maybe it is a coincidence with the overlap of the name, maybe not. Who knows? Is it important? Nope. What’s important are the problems arising from it. And I’ve gone into enough detail about those.

BTW: I did not even claim no one has ever used PCHAR outside of the Windows context and so on. That was you putting words in my mouth.

Explain to me again, why you think a pascal lanuage has to adhere to non pascal language standards?

Sorry, don’t like to repeat myself over and over again

Look, I am completely indifferent about the tools I use for development, I use the tool the suits my needs best, although people here seem to think just because I point out a shortcoming of (current and former) Delphi versions and because I am opposed to the way this transition to the Unicode-ability is handled, I am an enemy of Delphi. Whatever, keep thinking it. If it wasn’t for critics, how would those products ever evolve, if everyone says: “Oh, product XYZ is sooo nice, it’s perfect, I love it … unconditionally”.