Unicode support on Linux

[aafemt]

No description provided.

[irodushka]

Hi @aafemt

I see this's really a huge job.
But...

I don't like so many changes in so many source files. Looks like over-complicated and resembles a patchwork quilt. Sorry.
And this is just an initial work...)

I prefer not to increase the FB ODBC driver code entropy, since it's already very very high.
And the lack of testing tools, as well as near-to-zero test coverage, make such a changes vastly dangerous.
And all this only to support a case that has never been seen since the FB ODBC driver foundation)) i.e. "for ages")

What options can I suggest:

1. You make a fork of the ODBC driver (concerning all this unicode stuff) and maintain it by your own, occasionally merging a master branch from here to your fork. And I can mention your fork somewhere here.
2. OR Try to make your changes more systemic. For example, you can create some wrapper/helper class(es) that encapsulate all the charset conversion logic. As the first step, you implement these helpers into the existing codebase (i.e. pure refactoring, without any new functionality). We merge it and test it and it's okay. We can then override these helper layer to implement some new functionality, that will resolve a ticket Unicode support on Linux #247. If we do this carefully, we can switch between legacy and new unicode conversion logic simply with a #define or some feature-flag.
3. OR Cover all the code you touch with unit tests, for all possible scenarios & platforms, and consider merging your patches as is. Suppose that's a kind of non-science fiction)

Frankly speaking, I prefer option (2).

Regards
Yuri

[aafemt]

I will do (3) when have enough time. So far you can consider this branch as (1) to attract testers.

[fdcastel]

For the record: this work is already covered in #275.