search for: strlen_utf8

...amily-h> winapifamily.h is only available since MSVS 2012, so build will fail in older versions of Visual Studio (and in some older versions of MinGW). > #include "share/win_utf8_io.h" > #include "share/windows_unicode_filenames.h" > @@ -164,11 +165,13 @@ size_t strlen_utf8(const char *str) > int win_get_console_width(void) > { > int width = 80; > +#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP) Apparently these preprocessor defines are from winapifamily.h so it won't work in older MSVS and MinGW. > CONSOLE_SCREEN_BUFFER_INFO csbi; &gt...

lvqcl wrote: > all I can suggest > is to apply this patch, then fix issues if they'll happen after > this. But seriously, as a matter of fact win_utf8_io is a part of libFLAC. Functions from libFLAC call functions from win_utf8_io... For example: FLAC__stream_decoder_init_file() calls init_file_internal_() that calls flac_fopen() that is defined as fopen_utf8(). Currently

...39;t see reasons not to move win_utf8_io.c into libFLAC. > > Ok, lets do it. I just thought that it's more complicated. All *file* functions should really be moved to libFLAC. But other functions should not, because libFLAC doesn't use them. Two of them - win_get_console_width() and strlen_utf8() - are used only in src/flac/utils.c. So it makes sense to move these functions into that file. But what to do with print functions (printf_utf8, fprintf_utf8, and vfprintf_utf8) ? 1) keep separate share/win_utf8_io library, with only these three functions in it 2) move them to share/grabbag/snp...

Hi, This patchet allows a few targets to be disabled when unrequired. The rational is coming from VLC's contrib buildsystem, so far we use make -C to select only some subparts of the available targets. It would be easier and cleaner to use autoconf to do so IMHO. There's an additional patch which fixes the build when building for WinRT/UWP platform, upstreamed from VLC. We have a couple