[flac-dev] flac 1.3.0pre3 pre-release

[Janne Hyvärinen]

On 1.4.2013 16:04, LRN wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01.04.2013 16:55, Janne Hyvärinen wrote:
>> On 1.4.2013 15:29, LRN wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> On 01.04.2013 16:24, Janne Hyvärinen wrote:
>>>> I'm worried about some of the modifications done to the UTF-8
>>>> patch. In commit 2199d086921eb37d249cae0731f334556ec6209d
>>>> #ifdef checks were changed from specific FLAC__STRINGS_IN_UTF8
>>>> to generic _WIN32 and the specific defines were later removed
>>>> in commit 0cd2e9ed6918b782195d0024dd19dcfa39df8f82.
>>>>
>>>> The reason I had them this way is that FLAC API has public
>>>> functions that work with filenames. Default compile options
>>>> for FLAC would be unaffected and existing programs that rely on
>>>> ANSI filenames would continue to work. The new configuration
>>>> option "Release (UTF-8)" was meant to isolate the changes so
>>>> that only official bundled frontends that know about the
>>>> changes would use them.
>>> That's a valid point.
>>>
>>> Alternative approach (something i saw in libxml2 recently) is to
>>> make UTF-8-to-UTF-16 conversion a bit smarter: First try the
>>> conversion, assuming the string to be UTF-8-encoded. If that
>>> fails, assume the string is in native encoding, and run the
>>> conversion function again with appropriate source codepage (when
>>> using W32 conversion functions that would be CP_ACP). If that
>>> fails, fail the function call as usual.
>>>
>> I initially had it that way. I just didn't feel comfortable leaving
>> it as it could in theory access wrong files. Granted, it would
>> require having some rather weird names for files but it's still a
>> possibility.
>>
> Another option is to have a flag in the library, which can be changed
> at runtime (by calling a special library function, say,
> "flac_set_utf_mode()"). If that flag is set, assume strings to be in
> UTF-8. Otherwise assume them to be in local codepage.
>
> You can still have 2 different builds (UTF-8 one and normal one), they
> will just use different default values for that flag.
>
> Official frontends will know to call flac_set_utf_mode(), and will be
> able to work with UTF-8 version regardless of the build.
>
>

These patches change the UTF-8 mode into a runtime choice. The larger 
patch removes the now obsolete "Release (UTF8)" configuration options 
from the project files. The smaller patch makes the utf-8 library use 
ANSI codepage by default. When frontends call the "get_utf8_argv" 
function it changes Unicode conversion codepage from ANSI to UTF-8.
As far as I can see this solves possible issues.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: win_utf8_patches.zip
Type: application/x-zip-compressed
Size: 4740 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20130405/26e2bc0a/attachment-0001.bin