An old design flaw in pascal: string and char literals delimiter

[Basile B.]

(warning this is a bit trivial and futile)

String literal and char literals share the same delimiter. So with the following function:

Code: [Select]

function flaw(): integer;
begin
  result := length(LineEnding);
end;

Under Windows it works but under Linux you get a compiler error because LineEnding is a library litteral. Under Win it's a string because there are two chars (#13#10) in the literal but under nix it's a char (#10), so you cant get the length.

CQFD, it's design flaw.
You think that it can't happen but it does.

Simple fix: allow the length() intrinsic on char (always return 1).

[derek.john.evans]

Mmm, are you sure? There are 56 references to Length(LineEnding) in the Lazarus/FreePascal source code.

I got excited then, because I thought this might have been the reason for someones bug report on Mac.

Can you explain what you mean? Maybe it is an issue with some code? The bug Im talking about was the multi lined Hint/Caption's on Mac being removed by TStringMultilinePropertyEditor.

In PropEdits, TStringMultilinePropertyEditor.Edit, there is:

Code: [Select]

      if Copy(AString, length(AString) - length(LineEnding) + 1, length(LineEnding)) = LineEnding then
        Delete(AString, length(AString) - length(LineEnding) + 1, length(LineEnding));   


[zeljko]

He says that he's got compiler errror,,but laz does not have compiler errors in that case

[Basile B.]

There is clearly no problem with that.
Just forget this thread.
Too long to explain.