C:\Users\Bart\LazarusProjecten\bugs\Console\cpstring>cps
S: 1 + 1 = 2
S : [ 1252] $31 $20 $2B $20 $31 $20 $3D $20 $32 [1 + 1 = 2]
U8: [65001] $31 $20 $2B $20 $31 $20 $3D $20 $32 [1 + 1 = 2]
U7: [65000] $31 $20 $2B $2D $20 $31 $20 $2B $41 $44 $30 $2D $20 $32 []
A : [20127] $31 $20 $2B $20 $31 $20 $3D $20 $32 [1 + 1 = 2]
Utf7 -> ShortString: [ 1252] $31 $20 $2B $2D $20 $31 $20 $2B $41 $44 $30 $2D $20 $32 [1 +- 1 +AD0- 2]
Utf7 -> CP_ACP : [ 1252] []
Utf7 -> CP_UTF8 : [ 1252] []
On windows, this function is called when converting from one code page to another (syswin.inc):
The fix in the Win32Ansi2UnicodeMove function should be as follows:
S: 1 + 1 = 2
...
U7: [65000] $31 $20 $2B $2D $20 $31 $20 $2B $41 $44 $30 $2D $20 $32 [1 + 1 = 2]
...
Utf7 -> ShortString: [ 1252] $31 $20 $2B $2D $20 $31 $20 $2B $41 $44 $30 $2D $20 $32 [1 +- 1 +AD0- 2]
Utf7 -> CP_ACP : [ 1252] $31 $20 $2B $20 $31 $20 $3D $20 $32 [1 + 1 = 2]
Utf7 -> CP_UTF8 : [65001] $31 $20 $2B $20 $31 $20 $3D $20 $32 [1 + 1 = 2]
C:\Users\Bart\LazarusProjecten\bugs\Console\cpstring>fpc -FcUTF7 cps.lpr
Error: Unknown codepage "UTF7"
Error: C:\pp\bin\i386-win32\ppc386.exe returned an error exitcode
C:\Users\Bart\LazarusProjecten\bugs\Console\cpstring>fpc -Fc65000 cps.lpr
Error: Unknown codepage "65000"
Error: C:\pp\bin\i386-win32\ppc386.exe returned an error exitcode
C:\Users\Bart\LazarusProjecten\bugs\Console\cpstring>fpc -FcUTF-7 cps.lpr
Error: Unknown codepage "UTF-7"
Error: C:\pp\bin\i386-win32\ppc386.exe returned an error exitcode
C:\Users\Bart\LazarusProjecten\bugs\Console\cpstring>fpc -FcUTF8 cps.lpr
Free Pascal Compiler version 3.3.1 [2019/05/12] for i386
Copyright (c) 1993-2018 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling cps.lpr
cps.lpr(45,9) Error: Unknown codepage "65000"
cps.lpr(45,9) Error: Compilation raised exception internally
Fatal: Compilation aborted
An unhandled exception occurred at $00477B14:
EAccessViolation: Access violation
$00477B14 GETASCII, line 697 of C:/devel/fpc/trunk/rtl/inc/charset.pp
$004C3954 TTYPECONVNODE__SIMPLIFY, line 2926 of ncnv.pas
$004C27F9 TTYPECONVNODE__PASS_TYPECHECK, line 2426 of ncnv.pas
$004CC597 TYPECHECKPASS_INTERNAL, line 81 of pass_1.pas
$004BD2E7 INSERTTYPECONV, line 380 of ncnv.pas
$004CC597 TYPECHECKPASS_INTERNAL, line 81 of pass_1.pas
$00552EFB STATEMENT_BLOCK, line 1367 of pstatmnt.pas
$00538079 BLOCK, line 381 of psub.pas
$00439919 COMPILE, line 395 of parser.pas
$00416674 COMPILE, line 278 of compiler.pas
Why would that be necessary?
Why would that be necessary?
To encode literals in a certain encoding, the compiler needs tables. A few common ones are builtin, weird ones not. I believe the tables can be made using utils/creumap or something.
If that were the case then assigning a CP_ACP string to a CP_UTF7 sting would then also have to fail?
But the example shows that the contents of the CP_UTF7 string are correct after assigning.
If you can't check the asm yourself, maybe that is better. You can also make two examples (acs:=utf7 and vice versa), and I'll check.
If you can't check the asm yourself, maybe that is better. You can also make two examples (acs:=utf7 and vice versa), and I'll check.
Well, it does not compile, so there is no assembler output I would think.
And my assemble knowlegde is zero (at best).
It might not just be literal conversion tables, it also can be that the compiler has an hard limit on allowed mappings somewhere (e.g. the ones that come from the unicode consortium tables).
Better ask on fpc-devel.