search for: printf_utf8

lvqcl wrote: > Oops. It seems that vsnprintf_s isn't always available on MinGW platform: > MinGW declares this function only if MINGW_HAS_SECURE_API macro is defined. > That's because WinXP version of msvcrt.dll doesn't contain secure functions > like vsnprintf_s. > > Maybe it's better to revert vsnprintf_s to vsprintf or to use vnsprintf? Ok, we need to drop

...-8 uses up to 4 bytes for a character, so the maximum length of a temporary buffer for a call like flac_fprintf(stderr, "%s: ERROR: couldn't get block from chain\n", filename); should in theory exceed 4*32768 = 131072 bytes (plus some space for the rest of the message). Currently *printf_utf8() functions allocate 32768 bytes buffer.

...ons of other people... Especially because I'm not very familiar with MinGW. Anyone? P.S. There are 3 places where flac uses vsnprintf: 1) flac_snprintf inside src/share/grabbag/snprintf.c 2) local_snprintf inside src/libFLAC/metadata_iterators.c -- but it's a full copy of flac_snprintf 3) printf_utf8/fprintf_utf8/vfprintf_utf8 inside src/share/win_utf8_io/win_utf8_io.c

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

...ions 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/snprintf.c 3) create new share/grabbag/win_utf8_printf.c file and move them there 4) move them to share/utf8 library 5) something else?

lvqcl wrote: > Why? We can use vsnprintf_s for MSVS, and vsnprintf for MinGW. > > MSVS version of vsnprintf_s is located inside (statically linked) msvcp???.lib > or (dynamically linked) msvcp???.dll. They are part of MSVS runtime, and compatible > with WinXP. So it is safe to use it in FLAC. Oh, ok. I missed this bit. I know so very little about Windows. However, if you compile

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