[fpc-pascal] FPC 3: disabling automatic AnsiString codepage conversionx

Jonas Maebe jonas.maebe at elis.ugent.be
Mon Apr 4 15:24:11 CEST 2016

tobiasgiesen wrote on Mon, 04 Apr 2016:

>> > Terminal has LC_CTYPE=UTF-8.
>> What about LC_ALL?
> My Mac OS installations do not have LC_ALL.
> But I just noticed that Carbon GUI programs do not get LC_CTYPE in their
> environment either.

If none of the environment variables related to code pages are set,  
FPC falls back to UTF-8 for (a.o.) OS X.

> So maybe cwstring needs to be fixed for Carbon GUI Mac OS X programs.

If you get ASCII, it means that one of the LC_ALL, LC_CTYPE and/or  
LANG environment variables is set to a setting that corresponds to  
ASCII (such as "C"), or set to a value that is not recognised as or  
translatable into a Windows code page number.

> What I see in the environment is
> __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0
> I think Carbon apps should override DefaultSytemCodePage, because the
> Carbon interfaces always use UTF-8, they do not care about any
> environment strings.

On OS X, unlike on Windows, there is no inherent difference between  
"GUI" (be it Carbon, Cocoa, or --most likely-- a mixture of the two)  
and "non-GUI" applications. You can have command line applications  
linking to a Carbon framework to deal with aliases, and a GUI  
application calling into libutil to open a pseudo tty.

The above environment variable is also unrelated to Carbon, but comes  
from CoreFoundation. 0x1F5 is the hexadecimal value of your user ID.  
At least one of the 0x0's indeed refers to the default/ansi encoding  
of CoreFoundation, but it's definitely not the value you want to use.  
It's the value of the MacRoman text encoding.

That said, FPC 3.1.1 also contains an OS X/iOS-specific widestring  
manager unit that you can use instead of cwstring (iosxwstr), and that  
one will always default to UTF-8 (because the "ansi" code page of  
CoreFoundation only makes sense from a classic Mac backward  
compatibility standpoint, which we don't have to care about because we  
don't have a legacy code base that depends on this default setting --  
if someone would want to port code that depends on this to FPC, they  
would have to set this themselves).



More information about the fpc-pascal mailing list