[fpc-pascal] String literals and code page of .pas source file

[Michael Van Canneyt]

On Mon, 14 Sep 2020, Tomas Hajny via fpc-pascal wrote:

>> opened:
>> {$ifdef FPC_HAS_FEATURE_ANSISTRINGS}
>>   { if no codepage is yet assigned then assign default ansi codepage }
>>   TextRec(t).CodePage:=TranslatePlaceholderCP(TextRec(t).CodePage);
>> {$else FPC_HAS_FEATURE_ANSISTRINGS}
>> 
>> I see no need to change this ?
>
> Please, have a look at OpenStdIO (implemented at the end of text.inc). 
> That one changes the default codepage for Input, Output and StdErr, but 
> it doesn't care about possible redirection and/or piping to some other 
> application (not necessarily written in FPC). That approach has both 
> advantages and disadvantages. The advantage is that "type 
> <redirected_file>" will give correct results on the console. The 
> disadvantage is that opening the redirected file with any Win32 GUI 
> application (let's say notepad.exe) will result in garbage.  I don't say 
> that it is necessarily bad, but it should be documented at least if we 
> want to keep it that way.

I would definitely keep it that way.

As I see it: 
Redirection or not should not matter, the system should assume console output.
Things like 'tee' make this concept dubious in any case:

If you pipe output to a program, you don't expect the codepage to change
because of the redirection.


>> I think it will differ since Crt is not codepage aware. If you want it 
>> to
>> work the same you'll have to make Crt codepage (and hence unicode) 
>> aware.
>
> As mentioned by me, Crt is currently more codepage aware than the System 
> unit output as far as output to console is concerned, because Crt 
> provides correct output even for shortstrings (unlike the System unit).

I would need to check the details, but that sounds more like accidental 
behaviour as opposed to intended behaviour to me :-)

Michael.