[fpc-pascal] fpc 3.0 ansistring codepage behavior

[Jonas Maebe]

Seth Grover wrote on Fri, 04 Mar 2016:

> I understand that if I'm doing things "right" with ansistrings, everything
> will work correctly and transparently. However, I worry that there may be
> places in our code where we are doing bad things with ansistrings that may
> be the root of my problem.

"Wrongly" handling ansistrings can only result in invalid data ending  
up in the strings, not in memory corruptions. Well, apart from any  
bugs that may have crept in the RTL routines while adding the code  
page support of course, but those cannot be hidden by just changing  
some settings.

> To identify whether or not this is really the case, is there some way I can
> use the  FPC compiler but have the behavior of ansistrings act like it did
> in fpc 2.6.4?

Yes and no. Yes: if you only use plain ansistrings (or strings in  
{$h+} mode) in your code, the compiler won't generate any code page  
conversions anywhere. Of course, the code in the RTL may still trigger  
some based on the  
http://wiki.freepascal.org/FPC_Unicode_support#Code_page_settings  
settings

No: there is no switch to flip the compiler into a 2.6.4 emulation mode.

> or example, can I do:
>
> SetMultiByteConversionCodePage(CP_NONE);

That will just result in lots of invalid string data.

> or is there some kind of compiler flag I can set in my project? Or even if
> I have to rebuild the compiler itself, can I have the old 2.6.4 ansistring
> behavior in FPC 3.0?

While there is a way to compile the RTL with most of the  
codepage-aware string handling disabled (for bootstrapping with  
2.6.4), the 3.x compiler will always call the string helpers with  
extra codepage-related parameters, so you cannot use an RTL that is  
built like this with FPC 3.x.

> Even if I had to change all of my ansistring declarations to rawbytestring
> I could do that, although that would require me to touch more code and I'd
> prefer to find some sort of flip-a-switch way to do it.

If all of your strings are plain ansistrings (or string in {$h+}  
mode), you program won't (shouldn't) contain any more string code page  
conversions that if you would change everything to rawbytestring.


Jonas