So far I can see three ideal solutions of this issue:
1) Make Unicode support a part of the libFLAC API.
In this case there will be no need in separate -lFLAC -lwin_utf8_io
options, just -lFLAC will be needed.
2) Remove the dependency between libFLAC and win_utf8_io.
In this case win_utf8_io will be linked statically to 1st-party apps,
like other libraries from src/share: getopt, grabbag, ...
3) Leave it as is.
The first solution:
It's not feasible now, because the current Unicode API is too dangerous:
it uses global variable 'win_utf8_io_codepage', so it's not thread-safe.
At least, it's not foolproof thread-safe: it's not possible to use both
UTF8-enabled and UTF8-disabled API from different threads, it's not safe
to switch UTF-8 support in the middle of a program,...
The second solution:
Remember that win_utf8_io is a private thing that is available only to
1st-party programs. They now use libFLAC functions that take const char*
as their argument, but they can use libFLAC functions that take FILE*
or - even better - user-defined callbacks. The diagram becomes:
-------------------- FILE* or callbacks -----------
| main() | <-----------------------> | libFLAC |
-------------------- -----------
^ ^
| | UTF-8
| v
| ---------------
| | win_utf8_io |
| ---------------
| ^
| | UTF-16
v v
--------------------
| Windows |
--------------------
But it requires somebody to rewrite FLAC apps.
The third solution:
It's the simplest and requires the least amount of efforts.
In this sense, it is ideal too.
_______________________________________________
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
