I am debugging an issue (x86_64 Linux platform) which I have in FPC 3.0 which I didn't have in 2.6.4. It is a complex project with a lot of threading, custom memory management, etc., so it's not something I can easily boil down at the moment. Generally it manifests itself in memory corruption.
As I'm eliminating possibilities, I see often my crashes happen when various ansistring conversions/setlengths/etc. are happening. As I read http://wiki.freepascal.org/FPC_Unicode_support I can see that there were a lot of changes that went into unicode support in 3.0, particularly with making ansistrings codepage-aware. 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. 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? For example, can I do: SetMultiByteConversionCodePage(CP_NONE); 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? 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. Thanks for your input, -SG -- Seth Grover Be kind to all of your neighbors Because they're just like you. And you're nothing special Unless they are too.
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
