[flac-dev] About libFLAC -> win_utf8_io dependency

lvqcl lvqcl.mail at gmail.com
Sat Jan 9 15:01:54 PST 2016


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.


More information about the flac-dev mailing list