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 _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
