search for: fprintf_utf8

...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

...eally 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