[Lazarus] FPC 2.7.1 and console output

[Hans-Peter Diettrich]

Mattias Gaertner schrieb:
> On Thu, 04 Dec 2014 07:00:59 +0100
> Hans-Peter Diettrich <DrDiettrich1 at aol.com> wrote:

> UTF8Console is needed, when your source is UTF-8, but the compiler
> thinks it is Windows CP. UTF8Console is defined in LazUTF8.
> An alternative is UTF8Decode.

Thanks :-)

>> Just tested on WinXP:
>>
>> program test;
>> var a: AnsiString;
>> begin
>>    a := 'äöü';
>>    WriteLn(a,'äöü');
>> end;
>>
>> works differently with file encoding Ansi, UTF-8 and UTF-8bom. The 
>> latter correctly shows 'äöüäöü', else a mix of several encodings shows 
>> up in the console.
> 
> I see.

Only after testing the string encodings I found out that $codepage does 
not affect CP_ACP, this was unclear to me before. A new Lazarus version 
instead may try to set DefaultSystemCodePage to UTF-8, in order to 
preserve compatibility with the current assumption about UTF-8 encoding 
with AnsiStrings.

> Indeed I never tried passing a constant in writeln.

You never wrote text or separtors?

> Does Delphi also pass constants unconverted to writeln?

Delphi does not convert anything in console output, the user must 
convert everything to CP_OEM :-(


>> {$codepage UTF8} requires UTF-8 file encoding as well, doesn't 
>> compile when stored as Ansi.
> 
> What do you mean with "doesn't compile"? What compiler error?

Hmm, until yesterday the error message was "illegal character..." - or 
was it "file I/O error"? - with non-ASCII characters in string literals. 
Just tested, the error has disappeared, instead garbage is displayed at 
runtime. Now string literals seem to be stored as UTF-8 (file encoding), 
with 0 (CP_ACP) for the encoding. That means that the UTF-8 bytes are 
treated at runtime as being DefaultSystemCodePage characters. You 
certainly can imagine what happens in a conversion of these bytes into a 
different encoding :-(

DoDi